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

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

Hello MIB Drs.,

I was asked to take a look at this document for an initial review prior to 
WG adoption as
part of the MPLS review team effort.

To quote from Loa's email regarding the MPLS review team:
"The reviewers will be asked to comment on whether the document is coherent,
if is it useful (ie, is it likely to be actually useful in operational
networks), and is the document technically sound?

Reviews should be sent to the document authors, WG co-chairs and
secretary, and be CC'd to the MPLS WG email list. If necessary,
comments may be sent privately to only the WG chairs."

I value the MIB doctors' input  and  consistency in MIB reviews, even with 
initial reviews,
so wanted to cc this group also.  Please feel free to comment on this (or 
other future reviews), but please keep in mind
that these MPLS review team reviews have the above objectives.

Thanks,
  -Joan

----- Original Message ----- 
From: "Joan Cucchiara" <[e-mail]>
To: <[e-mail]>; "Thomas Nadeau" <[e-mail]>; 
<[e-mail]>; "Kannan KV Sampath" 
<[e-mail]>; "Sami Boutros" <[e-mail]>; 
<[e-mail]>
Cc: "Joan Cucchiara" <[e-mail]>; <[e-mail]>; "Loa 
Andersson" <[e-mail]>; "Swallow George" <[e-mail]>; "Ross Callon" 
<[e-mail]>; "Martin Vigoureux" 
<[e-mail]>; "MIB Doctors (E-mail)" 
<[e-mail]>
Sent: Wednesday, May 23, 2012 11:30 AM
Subject: Review for WG Adoption of draft-vkst-mpls-tp-oam-id-mib-02.txt


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