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

["Joan Cucchiara" <[e-mail]>]

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.



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.

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.