Re: [MIB-DOCTORS] Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt

[Thomas Nadeau <[e-mail]>]

yes we will update.

thanks again Joan for reviewing!

Tom 



On Jun 2, 2012, at 10:16 PM, "Loa Andersson" <[e-mail]> wrote:

> Authors,
> 
> The review by Joan was part of the MPLS RT review prior to polling the
> document to become a working group.
> 
> Though updating the draft prior to the poll is strictly not necessary
> to start the poll. However I would strongly prefer to poll an updated
> document.
> 
> Could you please update and republish.
> 
> /Loa
> (as wg chair)
> 
> On 2012-05-23 23:16, Thomas Nadeau wrote:
>> 
>>    Hi Joan!
>> 
>>    Thanks for the review. Comments inline start with TOM:
>> 
>> On 5/23/12 11:30 AM, "Joan Cucchiara"<[e-mail]>  wrote:
>> 
>>> 
>>> Hello Authors,
>>> 
>>> Thank you for proposing this solution.
>>> Please see my notes below.
>>> 
>>> Thank you,
>>>  -Joan
>>> 
>>> 1) Coherency of document:
>>> A) Is document useful and likely to be used/useful in operational
>>> networks?
>>> 
>>> This document contains a MIB Module with 2 tables.  The tables allow
>>> creation of
>>> TP IDs of MPLS LSPs and Pseudowires.   Also a pointer to rows in
>>> other MIBs Modules., i.e. to an MPLS Tunnel in the MPLS-TE-STD-MIB
>>> (RFC3012)
>>> or
>>> pseudowire in the PWE-STD-MIB (RFC5601).   Since many vendors and
>>> operators
>>> support the MPLS-TE-STD-MIB and PW-STD-MIB, then one could agree with the
>>> authors that the architecture of this MIB is a viable approach.
>>> 
>>> In other words, the authors are leveraging off of existing MIB
>>> implementations.
>>> They are doing this in a way which adheres to the rules of SMIv2 and I do
>>> think that the MIB is likely to be used/useful in operational networks.
>>> 
>>> 
>>> B) Is document technically sound?
>>> 
>>> From a MIB perspective, no:
>>> 
>>> I) Many objects are of type "DisplayString" which is used
>>> in SMIv1 but not in SMIv2.
>>> 
>>> As the MIB Common TC doc specifies:
>>> 
>>> https://svn.tools.ietf.org/area/ops/trac/wiki/mib-common-tcs
>>> 
>>> 
>>>   "Note 2.  DisplayString does not support internationalized text.
>>>            It MUST NOT be used for objects that are required to
>>>            hold internationalized text (which is always the case
>>>            if the object is intended for use by humans [RFC2277]).
>>>            Designers SHOULD consider using SnmpAdminString,
>>>            Utf8String, or LongUtf8String for such objects."
>>> 
>>> II) The term "Trap" is used in both the document and the MIB.
>>> This needs to be replaced by the term "Notification".  Traps a mechanism
>>> in SNMPv1.   Please see RFC3584.
>> 
>> TOM: Ooops! We will fix this.
>> 
>>> 2) Is document ready for WG adoption?
>>> 
>>> I would ask that changes to remove DisplayString and use a TC which
>>> supports internationalization be done, and the term Trap removed
>>> prior to WG adoption for reasons stated above.
>>> 
>>> This request should only take a few minutes of editing, but will bring
>>> the
>>> document upto SMIv2.
>> 
>> TOM: Agree. There is no big issue fixing this. We will need to re-spin the
>> draft in a WG-approved format anyways, so we can fix this during those
>> edits.
>> 
>>> 
>>> Additionally, a few comments (mostly as fyi):
>>> 
>>> I) this MIB contains configuration (read-create) objects.
>>> 
>>> II) the document proposes to root the MIB under mplsStdMIB which was
>>> the convention for the set of MPLS MIBs in 2004 but guidelines have
>>> changed since then.
>>> 
>>> III) The use of the accessible-for-notify and imports of
>>> IFMIB tables do not seem necessary in the MIB's current state.
>>> As the MIB is updated, this should be removed or clarified.
>> 
>> TOM: Cool.
>> 
>>    --Tom
>> 
>>> 
>>> 
>> 
> 
> -- 
> 
> 
> Loa Andersson                         email: [e-mail]
> Sr Strategy and Standards Manager            [e-mail]
> Ericsson Inc                          phone: [phone]
>                                              [phone]