Subject: [MIB-DOCTORS] SNMPSet is dead? (was: RE: AD review of draft-ietf-mpls-tp-te-mib)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 21 Jan 2014 09:34:42 +0000

Hi,

I trimmed the distribution list to MIB Doctors.

Benoit - you wrote: 

> Let me it clear. IMO, SNMPSet is dead.
> During one of our last Ciscolive show (a big event with thousands of
> participants), I went to most of my NMS partners, asking about SNMPset.
> None are using SNMPSet. The only exception is a proprietary OPS feature
> called IP SLA.
> Now, if one WG wants to have read-write, that's also fine with me.
> 
> Regards, Benoit

'SNMPSet is dead' is a very crisp statement. I believe that it deserves a separate discussion with a separate subject line. Maybe to start here (MIB Doctors) and be continued in OPSAREA. Maybe we need some guidance for people writing management data models (MIB modules, YANG modules) and for operators. I do not have such a crisp opinion (yet?). I do know that in other SDOs like the IEEE 802 they develop MIB modules with read-write capabilities. Maybe they need also some guidance, or maybe their environments are different (more enterprise networks thus 'controlled environments'?). In any case I would avoid drawing conclusions from one vendor environment, be it as big and as respectable as it is. SNMP is used today if different operational environments , not only in SP routers networks. If we reach consensus that 'SNMPSet' is dead - do we have a viable alternative? Is NETCONF mature enough ,understood well enough, with enough tools and YANG modules to be an alternative? Or maybe we do not need an alternative and we give up interoperability for configuration operations? 

I do not know the answers to these questions. 

Regards,

Dan

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: יום ב 20 ינואר 2014 18:51
> To: Thomas Nadeau; Farrel Adrian
> Cc: Sam Aldrin; Kannan Sampath; MIB Doctors (E-mail); Venkatesan
> Mahalingam; [email-masked]; draft-ietf-mpls-tp-te-
> [email-masked]; Loa Andersson
> Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib
> 
> On 20/01/2014 17:25, Thomas Nadeau wrote:
> > On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel <[email-masked]>
> wrote:
> >
> >> What I think Loa is saying is "help!"
> >>
> >> The MIB Doctor review was great and found a large number of issues
> >> with the document.
> >> Yet, when the document reached the AD for review there were still a
> >> significant number of issues with the MIB modules.
> >>
> >> I don't think that the MIB Doctor can be expected to review and
> >> re-review every document until it is perfect (they are welcome to,
> >> and we are delighted when they do, but they are human and they have
> >> day jobs), and I believe that sometimes it is simply not possible to
> >> find all issues in the first review because one set of problems obscure
> another set.
> >>
> >> Loa has forwarded a mail taken from part way through the email
> >> thread. A number of issues with the ANS.1 have been fixed by now, and
> >> this particular email was edited down to remove the technical issues and
> just leave the "political" ones.
> >>
> >> FWIW I have no issue with the level of review given to this document
> >> by the MIB Doctor. I do have an issue with the level of quality of
> >> this document as it came from the WG to first the MIB Doctor and then to
> me.
> >>
> >> It needs to be understood, IMHO, that people writing MIB modules are
> >> supposed to understand roughly what they are doing and to use the MIB
> >> doctors to verify the quality and catch a few missed issues. It is
> >> not the MIB Doctor's job to provide the ASN.1 for the authors!
> >>
> >> Loa is (rightly) wondering how he can get this sort of document up to
> >> quality when the WG is not very interested, the level of MIB clue in
> >> the WG is low, and the MIB Doctors are not super-heroes with days or
> >> weeks of spare time. I have no answer to that question except "Why do
> >> we keep writing write-access MIB modules?"
> > 	I have made my opinion very clear on this in the past, and in the case
> of this MIB the same holds true: I think the read-write stuff is a giant waste
> of time. I objected to adding write capability to this draft when the issue
> came up. At the time I predicted that based on past experience, that we
> would waste hours upon hours on getting the write capabilities correct for
> what is in effect a very simple MIB module that should have taken a couple
> of months to complete in read-only format. Look where we are? Why don't
> we save ourselves a lot of time and effort going and make this read-only?  Its
> very clear that nearly no one in operations land uses writable MIBs. Why
> does the IETF continue to waste its time with this?  The world has moved
> forward, so we should too.
> Let me it clear. IMO, SNMPSet is dead.
> During one of our last Ciscolive show (a big event with thousands of
> participants), I went to most of my NMS partners, asking about SNMPset.
> None are using SNMPSet. The only exception is a proprietary OPS feature
> called IP SLA.
> Now, if one WG wants to have read-write, that's also fine with me.
> 
> Regards, Benoit
> >
> > 	I will also point out something apropos to Loa's comment of a lack of
> interest in reviewing the document that out of the 4 or 5 people that have
> actually worked on it, I believe that only 1 wanted write capability. I am not
> an MPLS WG chair, so I didn't call consensus, but to me, that is not consensus
> to embark on making something writable thus signing the
> WG/editors/reviewers/etc... up to take on a huge amount of additional
> effort for what amounts to very, very little return.
> >
> > 	--Tom
> >
> >
> >
> >
> >> Adrian
> >>
> >>>> The working group, the authors and the mib-doctors have put in a
> >>>> substantial amount of time and effort to get the document in shape.
> >>>>
> >>>> Not being a MIB-expert the shepherd have relied heavily on the
> >>>> MIB-doctors. A process that worked well in the past.
> >>>>
> >>>> Three different versions were iterated between the MIB-doctors and
> >>>> the authors and updated according the comments from the MIB-
> doctor.
> >>>> This process ends by the MIB-doctor saying that it is OK to request
> >>>> publication.
> >>>>
> >>>> I'm a bit lost - but will try to work with authors and MIB-doctors
> >>>> to get the document in shape.
> >>> I'm not sure I understand your email, or to be more precise, what
> >>> you expect from the MIB doctor?
> >>> I concluded that MIB doctors review was done on this document.
> >>> http://trac.tools.ietf.org/area/ops/trac/wiki/mib-doctors-review-his
> >>> tory
> >>> Am I wrong?
> >>>> Question to Adrian: Scanning through your comments I have the
> >>>> impression that the actual MIB-modules are more or less ok, but
> >>>> that the informative text is what needs to be updated, right?
> >>> I don't see any MIB related feedback in this email.
> >>>
> >>> Regards, Benoit
> >>>> I also notice that
> >>>> the authors agreed to to a grammar review.
> >>>>
> >>>> /Loa
> >>>>
> >>>> On 2014-01-20 04:40, Venkatesan Mahalingam wrote:
> >>>>> ++Adrian and MIB doctors.
> >>>>>
> >>>>> On Sunday, January 19, 2014, Venkatesan Mahalingam
> >>>>> <[email-masked]
> >>> <mailto:[email-masked]>>
> >>>>> wrote:
> >>>>>
> >>>>>     Hi All,
> >>>>>
> >>>>>     As we have quite a few review comments from AD, we are
> addressing
> >>>>>     them in the private mail thread below.
> >>>>>
> >>>>>>> I think you should discuss with your document shepherd whether
> >>>>>>> to
> >>>>>     release the
> >>>>>>> changes in batches as you go along, or wait for all the changes
> >>>>>     in one go.
> >>>>>
> >>>>>     *Loa:* How would you like to proceed? Shall we release the
> changes
> >>>>>     in batches or all changes in one go?
> >>>>>
> >>>>>     As some of the authors are in vacation now, could not spend much
> >>>>>     time for discussing the comments. Hopefully, we will make this
> >>>>>     document into good shape by end of this month.
> >>>>>
> >>>>>     *Adrian: *Thanks for your response. We(Authors) shall discuss
> >>>>>     further on your below comments and update you as early as
> possible.
> >>>>>
> >>>>>>> Is there a reason to have this discussion in private and missing
> >>>>>     one of your
> >>>>>>> co-authors?
> >>>>>     Nope. Tom's Juniper email was bouncing and later I forgot to add
> him
> >>>>>     in the mail thread. It's my bad..;-)
> >>>>>
> >>>>>     -Venkat.
> >>>>>
> >>>>>     ---------- Forwarded message ----------
> >>>>>     From: *Adrian Farrel* <[email-masked] <javascript:_e({},
> >>>>>     'cvml', [email-masked]');>>
> >>>>>     Date: Sun, Jan 19, 2014 at 10:24 AM
> >>>>>     Subject: RE: AD review of draft-ietf-mpls-tp-te-mib
> >>>>>     To: Venkatesan Mahalingam <[email-masked]
> >>>>>     <javascript:_e({}, 'cvml', [email-masked]');>>
> >>>>>     Cc: Sam Aldrin <[email-masked] <javascript:_e({}, 'cvml',
> >>>>>     [email-masked]');>>, Kannan Sampath
> <[email-masked]
> >>>>>     <javascript:_e({}, 'cvml', [email-masked]');>>
> >>>>>
> >>>>>
> >>>>>     Hello,
> >>>>>     Sorry for the delay.
> >>>>>
> >>>>>     Is there a reason to have this discussion in private and missing one
> >>>>>     of your
> >>>>>     co-authors?
> >>>>>     Don't forget that you'll need to explain o the working group and
> >>>>>     your document
> >>>>>     shepherd what you have changed and why.
> >>>>>
> >>>>>     I have edited out the points where we have full agreement.
> >>>>>
> >>>>>     Thanks for the work so far. I think we have some more to do.
> >>>>>
> >>>>>     I think you should discuss with your document shepherd whether to
> >>>>>     release the
> >>>>>     changes in batches as you go along, or wait for all the changes in
> >>>>>     one go.
> >>>>>
> >>>>>     Cheers,
> >>>>>     Adrian
> >>>>>
> >>>>>> It would be nice if someone could do a pass on this document for
> >>>>>> English and format. It is not essential because the RFC Editor
> >>>>> will
> >>>>>> resolve these issues, but it is wise because the fewer changes
> >>>>>     the RFC
> >>>>>> Editor makes, the less chance there is of an accidental error.
> >>>>>> VM>> OK.
> >>>>>     Does "OK" mean that you agree with me that it would be nice, but
> >>>>>     that nothing
> >>>>>     will happen?
> >>>>>
> >>>>>> I see a contradiction in
> >>>>>>
> >>>>>> In
> >>>>>> particular, it describes managed objects of Tunnels, Identifiers,
> >>>>>     Label
> >>>>>> Switching Router and Textual conventions for Multiprotocol Label
> >>>>>> Switching (MPLS) based Transport Profile (TP). These MIB modules
> >>>>>     extend
> >>>>>> the existing MPLS MIB objects for both MPLS-TP and Non-MPLS-TP
> >>>>>> operations, so the MPLS-TP name is not included in the MIB module
> >>>>>     name.
> >>>>>> Either the extensions are for MPLS-TP or they are not. Your
> >>>>> second
> >>>>>> sentence says they are for more general applicability, and I
> >>>>>     agree with
> >>>>>> that. So why does the first sentence and the document title talk
> >>>>>     about
> >>>>>> MPLS-TP?
> >>>>>>
> >>>>>> VM>> Per Loa suggestion, we kept the mpls-tp in the title
> >>>>> because we
> >>>>>> develop this MIB module as part of IETF MPLS-TP project.
> >>>>>> First sentence will be changed.
> >>>>>     I see the change and am now faced with "untraditional networks"
> >>>>>     which I like
> >>>>>     even less.
> >>>>>
> >>>>>     I wish you could decide what this MIB module is for and describe
> >>>>>     that. Note that
> >>>>>     this problem runs through the document where you talk about
> objects
> >>>>>     and tables
> >>>>>     being for MPLS-TP tunnels, etc.
> >>>>>
> >>>>>> I think the Introduction would be made more useful and
> >>>>> relevant if it
> >>>>>> described the purpose and content of this document. Currently
> >>>>> it says
> >>>>>> what the existing documents don't do (although even that is
> >>>>> pretty
> >>>>>> vague).
> >>>>>     You added a few words per the Abstract, but you didn't really
> change
> >>>>>     the text.
> >>>>>     Can you say what function you are adding support for. That would
> >>>>>     probably
> >>>>>     address my concern.
> >>>>>
> >>>>>     And you left in place...
> >>>>>
> >>>>>> The existing Multiprotocol Label Switching (MPLS) Traffic
> >>>>> Engineering
> >>>>>> (TE) Management Information Base (MIB) [RFC3812] and
> Generalized
> >>>>>> Multiprotocol Label Switching (GMPLS) Traffic Engineering
> >>>>> Management
> >>>>>> Information Base [RFC4802] do not support the transport network
> >>>>>> requirements of NON-IP based management and static bidirectional
> >>>>>> tunnels.
> >>>>>     ...which says what other documents don;t allow you to do, but not
> >>>>>     what this
> >>>>>     document does.
> >>>>>
> >>>>>     Furthermore, I previously said...
> >>>>>
> >>>>>> There is also an implication here that this MIB module supports
> >>>>>     non-IP
> >>>>>> based management. I looked but didn't see any description of how
> >>>>>     to run
> >>>>>> SNMP in the absence of IP.
> >>>>>     And I don't see any change for this.
> >>>>>     How does an SNMP MIB module support non-IP based
> management?
> >>>>>
> >>>>>> It goes on...
> >>>>>>
> >>>>>> These MIB modules should be used in conjunction with [RFC3812]
> >>>>>> and companion document [RFC3813] for MPLS-TP tunnel
> >>>>> configuration and
> >>>>>> management.
> >>>>>>
> >>>>>> What is an "MPLS-TP tunnel"?
> >>>>>>
> >>>>>> VM>> This document mainly focuses on static bi-directional
> >>>>> tunnel.
> >>>>>> We'll update the introduction section to provide more details.
> >>>>>     I think you mean tunnels that are not set up by signaling?
> >>>>>     What does "mainly" mean?
> >>>>>
> >>>>>     You now have...
> >>>>>
> >>>>>          This document mainly focuses on static
> >>>>>          bidirectional MIB modules that should be used in
> >>>>> conjunction with
> >>>>>          [RFC3812] and companion document [RFC3813] for MPLS
> Transport
> >>>>>     Profile
> >>>>>          (MPLS-TP) path configuration and management.
> >>>>>
> >>>>>     What is a "static bidirectional MIB module".
> >>>>>     What is an "MPLS-TP path"? How does it differ from an MPLS path?
> >>>>>
> >>>>>> Section 4 might have been an opportunity to provide the
> >>>>> information I
> >>>>>> think is missing from the Introduction. But unfortunately it
> >>>>> repeats
> >>>>>> some of the text form the Introduction and then gives a very
> >>>>> scanty
> >>>>>> description of the purpose of the work.
> >>>>>>
> >>>>>> Here, however, I find the text
> >>>>>>
> >>>>>> As the existing MPLS-
> >>>>>> TE-STD-MIB is not sufficient to capture all the ch
> >>
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors

---

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

I applaud Benoit for his very pragmatic statement. There are very few operators that use SNMP set any longer. The cost-benefit for the IETF to work on writable MIBs in has long past, yet we continue to wrestle with making MIBs writable. Why?  Isn't this why NetConf/Mod were invented?  We knew long ago that configuration was a mess at best with SNMP, so we went off and built a better approach.  Based on that, I'd say there should be a pretty high bar to justify spending WG resources that are already very minimal to begin with in the area of developing SNMP MIBs, to work on making those MIBs writable for a scant few that might use them in that manner. 

	--Tom

---

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

Iirc, towards the end of my tenure as OPS AD I had already stopped
asking for writable MIB modules. We never went as far as to tell a WG they
could/should not do it, but iirc, from somewhere around end 2005 early 2006,
we no longer required writable MIB modules.

Bert

---

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

Saying 'we do not require writable MIB modules' is different from saying 'do not use writeable objects in MIB modules'. 

Assuming that a working group reaches the conclusion that they need interoperable configuration - what is the guidance provided by the OPS Area? 

Regards,

Dan

> From: Bert Wijnen (IETF) [mailto:[email-masked]]
> Sent: יום ג 21 ינואר 2014 16:49
> To: Thomas Nadeau; Romascanu, Dan (Dan)
> Cc: MIB Doctors (E-mail)
> Subject: Re: [MIB-DOCTORS] SNMPSet is dead?
> 
> Iris, towards the end of my tenure as OPS AD I had already stopped asking
> for writable MIB modules. We never went as far as to tell a WG they
> > 	I applaud Benoit for his very pragmatic statement. There are very
> few operators that use SNMP set any longer. The cost-benefit for the IETF to
> work on writable MIBs in has long past, yet we continue to wrestle with
> making MIBs writable. Why?  Isn't this why NetConf/Mod were invented?
> We knew long ago that configuration was a mess at best with SNMP, so we
> went off and built a better approach.  Based on that, I'd say there should be a
> pretty high bar to justify spending WG resources that are already very
> minimal to begin with in the area of developing SNMP MIBs, to work on
> making those MIBs writable for a scant few that might use them in that
> manner.
> >
> > 	--Tom

---

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

I think the issue is of what you say Bert - its time to take things a step further for the WGs to not only not require it, but to perhaps actively discourage it.

	--Tom

---

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

Yes I agree and am fine with that.
I was just adding some infor for the record.
We know for a long time already that SNMP set is not used much.

Bert