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

[Venkatesan Mahalingam <[e-mail]>]

Loa,

> Could you please update and republish.
Sure. We will address Joan's comments and republish the draft soon.

Thanks,
Venkat.

On Sat, Jun 2, 2012 at 7: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]