Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

From: Benoit Claise <[email-masked]>
Date: Sun, 02 Feb 2014 14:58:09 +0100

Mib doctors,

It's time to improve the following statement, to propose it to the OPS 
area, and if all goes well o make an IESG statement out of it.

    "The OPS Area henceforth strongly discourages the pursuit of
    writable SNMP MIBs for configuration purposes by working groups
    except in cases of clear utility and overwhelming consensus to do
    so. In all other cases, we recommend the use of NETCONF/YANG IETF
    standards for configuration, specifically in new charters."

I re-read the email thread, and want to make the following changes:
- Add IETF. It was mentioned that some other SDOs might still be using 
SNMP for configuration: IEEE, DOCSIS
- Add "for complete features or services" configuration. I want to 
address Chirs' point that SNMPSet for starting an action might be OK 
(router reload, start config download)

    "The OPS Area henceforth strongly discourages the pursuit of
    writable SNMP MIBs for complete features/services configuration
    purposes by IETF working groups, except in cases of clear utility
    and overwhelming consensus to do so. In all other cases, we
    recommend the use of NETCONF/YANG IETF standards for configuration,
    specifically in new charters."

Is this going in the right direction?
Is this good enough to discuss on the OPS area mailer?

Regards, Benoit
> Adrian, All,
>
> As expected and desired, this generated some good discussions (also in 
> a different email thread between the MIB doctors)
>
> So we went
> - from "SNMPSet is dead", as a comment to make people react
> - to "SNMPSet is dead?"
> - to "we do not require writable MIB modules"
> - A statement such as "The OPS Area henceforth strongly discourages 
> the pursuit of writable SNMP MIBs by working groups except in cases of 
> clear utility and overwhelming consensus to do so. In all other cases, 
> we recommend the use of tools such as Netconf/Netmod for configuration."
> - to "do not use writeable objects _for configuration_ in MIB modules"
>
> We could go with an IESG statement, but I propose to make it easy to 
> start with, with a statement on the MIB doctors page 
> (http://www.ietf.org/iesg/directorate/mib-doctors.html)
>
>     "The OPS Area henceforth strongly discourages the pursuit of
>     writable SNMP MIBs for configuration purposes by working groups
>     except in cases of clear utility and overwhelming consensus to do
>     so. In all other cases, we recommend the use of NETCONF/YANG IETF
>     standards for configuration, specifically in new charters."
>
> - I added "for configuration". SNMPSet could potentially be used for 
> action.
> - I removed "such as" in "tools such as Netconf/Netmod for 
> configuration." Not sure what you're referring to here Tom
> - I added "specifically in new charters." Right now, there are 
> read-write MIB modules in EMAN. It would not be a sound idea to say 
> now, specifically when documents went through LC: stop what you're 
> doing, recharter to do YANG modules. What's key in EMAN is that an 
> Information Model has been specified part of the framework.
>
> Feedback?
>
> Regards, Benoit
>
>> (speaking as not a MIB Doctor)
>>
>> I like that very much, thanks for the words Tom.
>>
>> Benoit, do you think this is a big enough issue that we should make it an IESG
>> statement?
>> Or do you just want to run it through the OPSAWG in some way?
>>
>> A
>>
>>> -----Original Message-----
>>> From: Bert Wijnen (IETF) [mailto:[email-masked]]
>>> Sent: 21 January 2014 15:30
>>> To: Thomas Nadeau; Romascanu, Dan (Dan)
>>> Cc: MIB Doctors (E-mail); Farrel Adrian
>>> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
>>>
>>> sounds good to me
>>>
>>> Bert
>>>
>>> On 21/01/14 16:14, Thomas Nadeau wrote:
>>>> 	Agreed. Something like, "The OPS Area henceforth strongly discourages
>>> the pursuit of writable SNMP MIBs by working groups except in cases of clear
>>> utility and overwhelming consensus to do so. In all other cases, we recommend
>>> the use of tools such as Netconf/Netmod for configuration."
>>>> 	--Tom
>>>>
>>>>
>>>>> Hi Tom,
>>>>>
>>>>> This is exactly my point. I think that we should not only say 'do not do
>> Sets
>>> using SNMP'. We should also say what to do instead.
>>>>> Regards,
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Thomas Nadeau [mailto:[email-masked]]
>>>>> ....
>>>>>
>>>>>> 	I do agree that guidance needs to be issues to developers and
>>>>>> especially IETF WGs on this matter.
>>>>>>
>>>>>> 	--Tom
>>>>>>
>>>>
>>>> _______________________________________________
>>>> MIB-DOCTORS mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/mib-doctors
>>>>
>> _______________________________________________
>> MIB-DOCTORS mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mib-doctors
>> .
>>
>
>
>
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Benoit Claise <[email-masked]>
Date: Sun, 02 Feb 2014 15:16:04 +0100

MIB doctors,

I forgot to include Dan's feedback.
See inline.
>     recommend the use of NETCONF/YANG IETF standards for
>     configuration, specifically in new charters."
>
    "The OPS Area henceforth strongly discourages the pursuit of
    writable SNMP MIB modules for complete features/services
    configuration purposes by IETF working groups, except in cases of
    clear utility and consensus to do so. Using SNMPSet to simple
    configuration, such as enable/disable notifications or initiating an
    action,  might be appropriate though.  In all other cases, we
    recommend the use of NETCONF/YANG IETF standards for configuration,
    specifically in new charters."

Regards, Benoit
>> As expected and desired, this generated some good discussions (also 
>> in a different email thread between the MIB doctors)
>>
>> So we went
>> the pursuit of writable SNMP MIBs by working groups except in cases 
>> of clear utility and overwhelming consensus to do so. In all other 
>> cases, we recommend the use of tools such as Netconf/Netmod for 
>> configuration."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 2 Feb 2014 15:44:59 +0100

On Sun, Feb 02, 2014 at 02:58:09PM +0100, Benoit Claise wrote:
> Mib doctors,
> 
> It's time to improve the following statement, to propose it to the
> OPS area, and if all goes well o make an IESG statement out of it.
> 
> - Add IETF. It was mentioned that some other SDOs might still be
> using SNMP for configuration: IEEE, DOCSIS

Since what Chirs is talking about s not configuration, I think the
original text was already OK. I am not sure people will easily
understand what 'complete features/services configuration' means.  I
also do not know what the difference between 'discourage' and
'strictly discourage' is.

/js

PS: Strictly speaking from an SMIv2 standpoint, I am not sure how to
    use the MAX-ACCESS clause anymore. ;-}

     The MAX-ACCESS clause, which must be present, defines whether it
     makes "protocol sense" to read, write and/or create an instance of
     the object, or to include its value in a notification.  This is the
     maximal level of access for the object.  (This maximal level of
     access is independent of any administrative authorization policy.)

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 3 Feb 2014 10:31:14 -0800

Juergen,

	I like the use of the adverb; it shows we mean business. *)

	--Tom

---

From: Benoit Claise <[email-masked]>
Date: Wed, 05 Feb 2014 06:13:15 -0800

> 'strictly discourage' is.
Then how should be call "such as enable/disable notifications" if this 
is not configuration.

Regards, Benoit

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 5 Feb 2014 14:22:48 +0000

Following the discussions we are having – we should probably add to enable/disable notifications also creation and deletion of dynamic rows using the RowStatus TC.

Regards,

Dan

From: Benoit Claise [mailto:[email-masked]]
Sent: יום ד 05 פברואר 2014 16:13
To: [email-masked]; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; Romascanu, Dan (Dan); 'MIB Doctors (E-mail)'
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

Mib doctors,

'strictly discourage' is.
Then how should be call "such as enable/disable notifications" if this is not configuration.
"The OPS Area henceforth strongly discourages the pursuit of writable SNMP MIB modules for complete features/services configuration purposes by IETF working groups, except in cases of clear utility and consensus to do so. Using SNMPSet to simple configuration, such as enable/disable notifications or initiating an action,  might be appropriate though.  In all other cases, we recommend the use of NETCONF/YANG IETF standards for configuration, specifically in new charters."
Regards, Benoit

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Feb 2014 15:33:20 +0100

> this is not configuration.

OK, this can be configuration or not, depending on whether the change
is persistent and not.
 
>    specifically in new charters."

I would rather write a positive statement instead of a negative one.
Something like this:

  The OPS area recommends the use of NETCONF/YANG standards for
  configuration. IETF working groups are therefore encouraged to use
  the NETCONF/YANG standards for configuration, specifically in new
  charters. SNMP MIB modules modifying persistent configuration state
  should only be produced by working groups in cases of clear utility
  and overwhelming consensus to use SNMP write operations for
  configuration.

Note that this statement limits the discussion to configuration data.
Note also that there is no standard way to modify operational state
via NETCONF at this point in time (so it would be strange to discourage
SNMP if there is no standardized alternative).

/js

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 5 Feb 2014 06:38:19 -0800

good point. the idea is to discourage any "configuration" operations.

Tom 

> On Feb 5, 2014, at 6:22 AM, "Romascanu, Dan (Dan)" <[email-masked]> wrote:
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 5 Feb 2014 06:48:40 -0800

we could be picky and discuss running versus persistent configuration but that's missing the issue: most providers disable snmp write regardless of ultimate configuration state.

Tom 

> On Feb 5, 2014, at 6:33 AM, Juergen Schoenwaelder <[email-masked]> wrote:
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 5 Feb 2014 16:05:46 +0100

On Wed, Feb 05, 2014 at 06:48:40AM -0800, Thomas D. Nadeau wrote:

> we could be picky and discuss running versus persistent
> configuration but that's missing the issue: most providers disable
> snmp write regardless of ultimate configuration state.

Having worked on replacement technology for SNMP for a couple of years
now, I think I do understand the issues and concerns. But then I also
know that there are networks that are not 'provider' networks. I still
believe in positive encouragement to use alternatives (where they
exist) and informed decisions by WGs.

/js

---

From: Michael MacFaden <[email-masked]>
Date: Wed, 5 Feb 2014 07:34:21 -0800

> I would rather write a positive statement instead of a negative one.
...

I agree Juergen's comments.

Mike MacFaden

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Wed, 05 Feb 2014 16:40:03 +0100

I fully agree with Juergen here:

Bert

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 5 Feb 2014 10:40:07 -0800

Yes, lets keep it positive for sure. 8)

	--Tom

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 6 Feb 2014 10:17:10 +0000

Yes, positive is good!

Regards,

Dan

> Sent: יום ד 05 פברואר 2014 20:40
> To: Juergen Schoenwaelder
> Cc: Benoit Claise; Farrel Adrian; Bert Wijnen (IETF); Romascanu, Dan (Dan);
> MIB Doctors (E-mail)
> >> we could be picky and discuss running versus persistent configuration
> >> but that's missing the issue: most providers disable snmp write
> >> regardless of ultimate configuration state.
> >

---

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Feb 2014 18:27:11 -0800

Juergen's proposal (copied here for completeness) works for me

    The OPS area recommends the use of NETCONF/YANG standards for
    configuration. IETF working groups are therefore encouraged to use
    the NETCONF/YANG standards for configuration, specifically in new
    charters. SNMP MIB modules modifying persistent configuration state should only be produced by working groups in cases of clear utility and overwhelming consensus to use SNMP write operations for configuration.

Next logical step is to post on the OPS area mailer (in a day or two, to 
wait for the last reactions)

Regards, Benoit

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 10 Feb 2014 21:55:39 -0800

Hi -

> From: "Benoit Claise" <[email-masked]>
...
> clear utility and overwhelming consensus
...

What is the difference between "rough consensus"
and "overwhelming consensus"?

Randy

---

From: Benoit Claise <[email-masked]>
Date: Mon, 10 Feb 2014 22:03:10 -0800

> and "overwhelming consensus"?
We discussed this point while working on the first proposal. The 
agreement was to remove "overwhelming"
"overwhelming" should also be removed from this proposal.
Good catch!

Regards, Benoit

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 11 Feb 2014 11:18:09 +0000

Yes, please. Let us avoid defining a new class of consensus and let the chairs and the AD decide from case to case. Otherwise I support this statement and I hope that it will be followed by an IESG action in the same direction.

Regards,

Dan

> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: יום ג 11 פברואר 2014 08:03
> To: Randy Presuhn; MIB Doctors (E-mail)
> We discussed this point while working on the first proposal. The agreement
> was to remove "overwhelming"

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 11 Feb 2014 09:40:20 -0500

The reason we originally had "overwhelming" in the statement was simple: consensus rules are a bit loose for this. For example, WGs typically have about %.05 of the people there that care about doing MIBs to begin with, so it is hard to determine consensus to even work on new MIBs to start with. Once adopted, decisions on HOW those MIBs are constructed then largely falls onto the shoulders of those same few people. When questions of "read vs write" come up, I've witnessed in numerous WGs that only those few MIB authors have any opinions and the remaining %99.05 of the WG doesn't raise their hands for either option (read or read-write), and will often raise for "I don't care".  Then the matter falls onto basically a vote between the 2 or 3 co-authors as to making it read-write or not. The point here is that here is where the WGs could really use the extra time/resources of both the WG, MIB DRs and the IESG reviews to produce many more read-only MIBs to target WG charter items instead of spending the exponentially greater amount of time making 1 or 2 people in the WG happy with writable MIBs.   That approach to me anyways, seems to address the larger WG's needs.

	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Tue, 11 Feb 2014 07:47:25 -0800

Hi,

Have to agree with you.
I've been that 1 "MIB guy" in the room working with
a domain-specific WG that developed a MIB module nobody
cared about.

Back then I thought it would get us closer to getting SNMP Set adopted.
I was wrong.  It had no positive impact on SNMP adoption at all.
It has been far too easy to get a MIB through a WG that has barely
been read, let alone has supporters and implementations planned.

It is up to the IESG approving charters whether or not the policy is fixed.
Adding the word "overwhelming" is not going to change that. If the WG
says "let's have a MIB" the AD should ask for a hum or a show of hands who
is planning to implement read-write MIB objects.

Andy

On Tue, Feb 11, 2014 at 6:40 AM, Thomas Nadeau <[email-masked]>wrote:

>
>         The reason we originally had "overwhelming" in the statement was
> simple: consensus rules are a bit loose for this. For example, WGs
> typically have about %.05 of the people there that care about doing MIBs to
> begin with, so it is hard to determine consensus to even work on new MIBs
> to start with. Once adopted, decisions on HOW those MIBs are constructed
> then largely falls onto the shoulders of those same few people. When
> questions of "read vs write" come up, I've witnessed in numerous WGs that
> only those few MIB authors have any opinions and the remaining %99.05 of
> the WG doesn't raise their hands for either option (read or read-write),
> and will often raise for "I don't care".  Then the matter falls onto
> basically a vote between the 2 or 3 co-authors as to making it read-write
> or not. The point here is that here is where the WGs could really use the
> extra time/resources of both the WG, MIB DRs and the IESG reviews to
> produce many more read-only MIBs to target WG charter items instead of
> spending the exponentially greater amount of time making 1 or 2 people in
> the WG happy with writable MIBs.   That approach to me anyways, seems to
> address the larger WG's needs.
>
>         --Tom
>
>
> > Yes, please. Let us avoid defining a new class of consensus and let the
> chairs and the AD decide from case to case. Otherwise I support this
> statement and I hope that it will be followed by an IESG action in the same
> direction.
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >