Subject: Re: [MIB-DOCTORS] AD review of draft-ietf-mpls-tp-te-mib

From: Venkatesan Mahalingam <[email-masked]>
Date: Sun, 19 Jan 2014 12:40:31 -0800

++Adrian and MIB doctors.

On Sunday, January 19, 2014, Venkatesan Mahalingam <
[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
>
>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 20 Jan 2014 11:10:38 +0800

All,

I don't know how to say this politely.

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.

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 also notice that
the authors agreed to to a grammar review.

/Loa

On 2014-01-20 04:40, Venkatesan Mahalingam wrote:
> 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.
>
>     *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.
>
>     From: *Adrian Farrel* <[email-masked] <javascript:_e({},
>     'cvml', [email-masked]');>>
>     To: Venkatesan Mahalingam <[email-masked]
>     <javascript:_e({}, 'cvml', [email-masked]');>>
>     [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
>     Does "OK" mean that you agree with me that it would be nice, but
>     that nothing
>     will happen?
>
>      > I see a contradiction in
>      >
>      > In
>     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
>     You added a few words per the Abstract, but you didn't really change
>     the text.

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 08:24:21 +0100

Loa,

> 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-history
Am I wrong?
> 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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 20 Jan 2014 17:31:18 +0800

Benoit, Joan (and all of the MIB Doctors),

I apologize - rereading my mail I understand why you read it the way
you do. I think I have a pretty good understanding of what the MIB
Doctors do and can do. And I think the support for this particular
document has been outstanding.

There is something else (if we agree that there are no MIB related
feedback on this document). I'm afraid that with the type of AD review
we got here we will scare people away even though they produce
technically sound documents.

If this is a clarity, grammar and Queens English question, I would say
that it would been much more efficient to simply state: "I can see that
this document is almost done from a technical perspective, but it lacks
quite a bit from language and grammar. Can you please to a language
review before we proceed?"

It was also my point that I don't see if Adrian's comments are MIB
module related or "just" a language thing. And that is part of why I
copied the people on Venkat's mail.

/Loa

--

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 20 Jan 2014 09:45:54 -0000

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

Adrian

> >> <[email-masked]
> <mailto:[email-masked]>>
> >> wrote:
> >>
> >>     Hi All,
> >>

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 20 Jan 2014 11:25:57 -0500

> answer to that question except "Why do we keep writing write-access MIB

	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.

	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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 20 Jan 2014 17:51:27 +0100

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

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 22 Jan 2014 05:20:33 -0800

Benoit,

Catching up on email as I returned from vacation just now.

See my comments inline.

-sam

> Let me it clear. IMO, SNMPSet is dead.
%sam - Understand that not many are interested in SNMP Set. Dead is stronger term as it is still being used (I know it is all SDN these days :D)
> 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.
%sam - Well if that is the case, why is Cisco still pushing SNMP write option in the MIB? Refer http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=1

In regards to this TP mib, we are having ‘write’ option only to few scalar objects, which are OAM ID’s like ICC ID, Node ID etc. Rest of the MIB and extensions are just read only.

-sam

---

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

Sam,
> On Jan 20, 2014, at 8:51 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>> On Jan 20, 2014:4:45 AM, at 4:45 AM, Adrian Farrel 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> 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.
> %sam - Understand that not many are interested in SNMP Set. Dead is 
> stronger term as it is still being used
I know, it's a bold statement.
The MIB doctors are currently preparing the politically-correct statement.
Stay tune.
> (I know it is all SDN these days :D)
>> 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.
> %sam - Well if that is the case, why is Cisco still pushing SNMP write 
> option in the MIB? Refer 
> http://datatracker.ietf.org/doc/draft-ietf-trill-oam-mib/?include_text=1
I'm not the Cisco CTO in charge of management. From time to time, I wish 
I was, but let's not go there :-)

Regards ,Benoit
>
> In regards to this TP mib, we are having ‘write’ option only to few 
> scalar objects, which are OAM ID’s like ICC ID, Node ID etc. Rest of 
> the MIB and extensions are just read only.
>
> -sam
>>
>> 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
>>>>
>>>>>>>    changes in batches as you go along, or wait for all the 
>>>>>>> changes in
>>>>>>>    one go.
>>>>>>>
>>>>>>>    Cheers,
>>>>>>>    Adrian
>>>>>>>
>>>>>>>         [RFC3812] and companion document [RFC3813] for MPLS 
>>>>>>> Transport
>>>>>>>    Profile

---

From: Sam Aldrin <[email-masked]>
Date: Wed, 22 Jan 2014 05:36:55 -0800

Hi Benoit,

Thanks for the reply,.
It would be great to have a cleat guideline or statement in regards to SNMP as a whole :D

Didn;t want to pick on you in regards to ‘Cisco’. Just pointing that there indeed work happening in SNMP world with SET’s and SDN hasn’t taken over yet :D

-sam
On Jan 22, 2014, at 5:31 AM, Benoit Claise <[email-masked]> wrote:

>> %sam - Understand that not many are interested in SNMP Set. Dead is stronger term as it is still being used
> I'm not the Cisco CTO in charge of management. From time to time, I wish I was, but let's not go there :-)
> 
> Regards ,Benoit
>>