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

[Loa Andersson <[e-mail]>]

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]