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

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 18:42:20 +0100

Dear all,

In light of the recent MIB doctor discussion, it might be a valid 
question to ask, during a MIB doctors review: why is this MIB module 
read-write?
Obviously, the goal is not influence the WG if there is consensus to do 
a read-write MIB module, but to make sure a WG doesn't produce a 
read-write (as opposed to read-only) MIB module _just _because it 
thought was necessary.

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Jan 2014 10:47:26 +0100

On Mon, Jan 20, 2014 at 06:42:20PM +0100, Benoit Claise wrote:
> Obviously, the goal is not influence the WG if there is consensus to
> do a read-write MIB module, but to make sure a WG doesn't produce a

A couple of years ago, I wrote this:

  http://tools.ietf.org/html/draft-schoenw-opsawg-copspr-historic-00

The reaction to this was _very_ interesting and I gave up (and mind
you that I think COPS-PR and SPPI never saw anything close in terms of
the deployment to that of SNMP). Good luck with finding concensus that
SNMP set is dead. ;-)

/js

PS: Is it time for draft-schoenw-opsawg-copspr-historic-01, now that 4
    more years have passed? ;-)

-- 
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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Jan 2014 09:54:19 +0000

Hi,

Maybe the lesson to learn (at least at this stage) is that rather than proposing formal actions on the status of the documents we should be issuing guidance to developers of applications and to operators? 

Regards,

Dan

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Juergen Schoenwaelder
> Sent: יום ג 21 ינואר 2014 11:47
> To: Benoit Claise
> Cc: MIB Doctors (E-mail); Adrian Farrel
> Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
> 
> The reaction to this was _very_ interesting and I gave up (and mind you that I
> think COPS-PR and SPPI never saw anything close in terms of the
> deployment to that of SNMP). Good luck with finding concensus that SNMP
> set is dead. ;-)
> 
> /js
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Jan 2014 11:15:47 +0100

> the deployment to that of SNMP). Good luck with finding concensus that
Finding consensus takes time and is always difficult.
However, a bold statement from the OPS AD to make the non OPS people 
think is cheap.
Note that "is SNMPSet dead?" is an article title authored by Andy 
Bierman, maybe 10 years ago. I can't find it back.

Regards, Benoit

---

From: Benoit Claise <[email-masked]>
Date: Tue, 21 Jan 2014 11:16:59 +0100

Dan,
> Maybe the lesson to learn (at least at this stage) is that rather than proposing formal actions on the status of the documents we should be issuing guidance to developers of applications and to ope…
Exactly. That's still high on my priority list, and I addressed that 
topic again at the last OPSAREA meeting.

Regards, Benoit
> .

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Jan 2014 08:57:01 -0500

Operators have already spoken, and I doubt they need guidance from the IETF on this. If you do a poll of actual operations you will find that very, very few have enabled SNMP writes in their networks. 

	I do agree that guidance needs to be issues to developers and especially IETF WGs on this matter. 

	--Tom

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Jan 2014 15:08:05 +0000

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

> From: Thomas Nadeau [mailto:[email-masked]]

....

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 21 Jan 2014 10:14:23 -0500

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

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 21 Jan 2014 16:30:21 +0100

sounds good to me

Bert

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 21 Jan 2014 17:32:13 -0000

(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

> 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
> > 	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
> >>
> >>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 11:27:14 +0100

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Jan 2014 10:52:59 +0000

Hi,

As we seem to have agreed with the principle let me throw a few comments about the proposed text:

"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."

-          We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be consistent with ourselves :) s/SNMP MIBs/SNMP MIB objects/

-          An example of clear utility would be useful. I am thinking for example the case of MIB objects that enable/disable notifications. If these are the only writeable objects in a MIB module, I do not think we should recommend supporting NETCONF/YANG just for enabling/disabling notifications

-          I am reluctant to define a new class of consensus here and I do not know what ‘overwhelming consensus’ means. Let us drop this.

As we say ‘The OPS Area …’ I believe that this statement needs to go through some consensus call on the OPS Area or opsawg mail list.

I have no problem with posting this first on the MIB doctors wiki, but running it later as an IESG statement would send a stronger and more visible signal to all WGs in the IETF.

Regards,

Dan

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

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

statement?

A

-----Original Message-----

sounds good to me

Bert

    --Tom

Hi Tom,

Sets

Regards,

Dan

-----Original Message-----

....

       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]<mailto:[email-masked]>

MIB-DOCTORS mailing list

[email-masked]<mailto:[email-masked]>

.

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 22 Jan 2014 09:17:43 -0500

> - 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…

	I think the statement is spot on.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 22 Jan 2014 09:18:50 -0500

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

> -          We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be consistent with ourselves J s/SNMP MIBs/SNMP MIB objects/

	I agree. The two-step approach likely gets the most impact.   Start with Ops Area/MIB Doctors and then IESG?

	--Tom

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 22 Jan 2014 16:42:39 -0000

Speaking as not-a-mib-doctor I am able to be a little cynical :-)
 
Getting OPS Area consensus and getting MIB doctor consensus is essential.
 
Posting on the MIB guidance wiki will have no impact on the IETF except in as
much as MIB Doctors will read it and apply it in their reviews/guidance. The
rest of the IETF (even the authors of MIB documents) will not read this page let
alone be influenced by it.
 
An IESG statement or an RFC is the most powerful tool we have to make any
difference.
 
But running all of these in sequence (with the intention of completing them all)
would be great.
 
A
 
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: 22 January 2014 14:19
To: Romascanu, Dan (Dan)
Cc: Benoit Claise; Farrel Adrian; Bert Wijnen (IETF); MIB Doctors (E-mail)
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?

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

Hi,
 
As we seem to have agreed with the principle let me throw a few comments about
the proposed text:
 
"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."
 
-          We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be
consistent with ourselves J s/SNMP MIBs/SNMP MIB objects/
-          An example of clear utility would be useful. I am thinking for
example the case of MIB objects that enable/disable notifications. If these are
the only writeable objects in a MIB module, I do not think we should recommend
supporting NETCONF/YANG just for enabling/disabling notifications
-          I am reluctant to define a new class of consensus here and I do not
know what ‘overwhelming consensus’ means. Let us drop this.
 
As we say ‘The OPS Area …’ I believe that this statement needs to go through
some consensus call on the OPS Area or opsawg mail list.
 
I have no problem with posting this first on the MIB doctors wiki, but running
it later as an IESG statement would send a stronger and more visible signal to
all WGs in the IETF.
 
          I agree. The two-step approach likely gets the most impact.   Start
with Ops Area/MIB Doctors and then IESG?
 
          --Tom

 Regards,
 
Dan

From: Benoit Claise [ <mailto:[email-masked]> mailto:[email-masked]] 
Sent: יום ד 22 ינואר 2014 12:27
To:  <mailto:[email-masked]> [email-masked]; 'Bert Wijnen (IETF)';
'Thomas Nadeau'; Romascanu, Dan (Dan)
Cc: 'MIB Doctors (E-mail)'
Subject: Re: [MIB-DOCTORS] Why is this MIB module read-write?
 
Adrian, All,

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>
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

 
A
 
-----Original Message-----
From: Bert Wijnen (IETF) [ <mailto:[email-masked]>
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

 
    --Tom

Hi Tom,

Regards,
 
Dan

-----Original Message-----
From: Thomas Nadeau [ <mailto:[email-masked]>
mailto:[email-masked]]
 
....

       --Tom

 
_______________________________________________
MIB-DOCTORS mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mib-doctors>
https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
MIB-DOCTORS mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/mib-doctors>
https://www.ietf.org/mailman/listinfo/mib-doctors
.

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 18:25:51 +0100

> Posting on the MIB guidance wiki will have no impact on the IETF 
> except in as much as MIB Doctors will read it and apply it in their 
> reviews/guidance. The rest of the IETF (even the authors of MIB 
> documents) will not read this page let alone be influenced by it.
>
> An IESG statement or an RFC is the most powerful tool we have to make 
> any difference.
>
Yes, I slowly arrive to the conclusion that an IESG statement is 
actually the right thing to do.

B.
>
> But running all of these in sequence (with the intention of completing 
> them all) would be great.
>
> A
>
> *From:*Thomas Nadeau [mailto:[email-masked]]
> *Sent:* 22 January 2014 14:19
> *To:* Romascanu, Dan (Dan)
> *Cc:* Benoit Claise; Farrel Adrian; Bert Wijnen (IETF); MIB Doctors 
> (E-mail)
> *Subject:* Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
> On Jan 22, 2014:5:52 AM, at 5:52 AM, Romascanu, Dan (Dan) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> Hi,
>
> "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."
>
> -We are preaching to the word to avoid using ‘SNMP MIBs’ so let us be 
> consistent with ourselvesJs/SNMP MIBs/SNMP MIB objects/
>
> -An example of clear utility would be useful. I am thinking for 
> example the case of MIB objects that enable/disable notifications. If 
> these are the only writeable objects in a MIB module, I do not think 
> we should recommend supporting NETCONF/YANG just for 
> enabling/disabling notifications
>
> -I am reluctant to define a new class of consensus here and I do not 
> As we say ‘The OPS Area …’ I believe that this statement needs to go 
> through some consensus call on the OPS Area or opsawg mail list.
>
> I have no problem with posting this first on the MIB doctors wiki, but 
> running it later as an IESG statement would send a stronger and more 
> visible signal to all WGs in the IETF.
>
> *From:*Benoit Claise [mailto:[email-masked]]
> *Sent:*יוםד22ינואר2014 12:27
> *To:[email-masked] <mailto:[email-masked]>; 'Bert Wijnen 
> (IETF)'; 'Thomas Nadeau'; Romascanu, Dan (Dan)
> *Cc:*'MIB Doctors (E-mail)'
> *Subject:*Re: [MIB-DOCTORS] Why is this MIB module read-write?
>
> Adrian, All,
>
> As expected and desired, this generated some good discussions (also in 
> a different email thread between the MIB doctors)
>
> So we went
> - 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"
>
> "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."
>
> 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
>
>             [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>

---

From: Benoit Claise <[email-masked]>
Date: Wed, 22 Jan 2014 19:50:53 +0100

Hi Dan,

All your comments make sense.
Let's work on the proposed text.

Regards, Benoit
> consistent with ourselves Js/SNMP MIBs/SNMP MIB objects/
>
> *Sent:* יוםד22 ינואר2014 12:27
> *To:* [email-masked]; 'Bert Wijnen (IETF)'; 'Thomas Nadeau'; 
> Romascanu, Dan (Dan)
> *Cc:* 'MIB Doctors (E-mail)'