[mpls] MPLS-RT review of draft-smiler-mpls-tp-linear-protection-mib-02

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

Loa,

My review of draft-smiler-mpls-tp-linear-protection-mib-02 for the MPLS 
Review Team is detailed inline below.

Thanks,
  -Joan

>>>Reviews should comment on whether the document is coherent, is it
>>> useful (ie, is it likely to be actually useful in operational
>>> networks), and is the document technically sound?

Yes, the document is coherent.  Ideally the MIB Module could be organized 
slightly differently and have more consistent naming as outlined in the MIB 
guidelines (rfc4181) and some comments have been included at the end of this 
email wrt to that.

It is likely to be useful in operational networks since it allows for 
configuration and monitoring of MPLS TP Linear Protection Switching using 
SNMPv3.

The document is technically sound from a MIB perspective.

>>> We are interested
>>> in knowing whether the document is ready to be considered for WG
>>> adoption (ie, it doesn't have to be perfect at this point, but should be
>>> a good start).
>>>

Yes, I think this draft should be considered for WG adoption and is a good 
start.

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

During the reading of this document, there were a few comments which I've 
included here:

* Section 6.1
Should discuss that mplsLpsMeConfigTable is "sparsely augmented" by
mplsOamIdMeTable, when the LER supports MPLS TP Linear protection.

* Needs REFERENCES throughout the MIB Module.

* Naming of MIB and Tables is inconsistent.

MIB name: MPLS-TP-LPS-MIB

vs. Table prefix (mplsLps...) -- The MIB guidelines (rfc4181)
suggest that these be consistent, so either use
MPLS-LPS-MIB and "mplsLsp..." prefix OR
MPLS-TP-LPS-MIB and use "mplsTpLps..." as a prefix.


* Term: traps appears in a MIB Module comment, please use Notifications.
Traps is an SNMPv1 construct.


* mplsLspConfigGroupIndex (indexes should start at 1,
unless there is a good reason not to start at 1)

* MIB ordering is not ideal
------------------------------
1) Typically, a Config Table is followed by its Status Table,
and I think that was intended based on the discussion prior
to the actual MIB, and also comments within the MIB Module,
but that was not done.

This will effect the overall MIB OIDs, so changing it sooner rather than 
later,
would be better.

2) Additionally, it is convention that RowStatus and StorageType objects
appear together at the end of a table, and this is not done.

3) Ordering of Compliance and Group is NOT as suggested by RFC4181.

xxxMIB
         |
         +-- xxxNotifications(0)
         +-- xxxObjects(1)
         +-- xxxConformance(2)
             |
             +-- xxxCompliances(1)
             +-- xxxGroups(2)

mplsLpsConformance
   OBJECT IDENTIFIER ::= { mplsLpsMIB 2 }

mplsLpsGroups
   OBJECT IDENTIFIER ::= { mplsLpsConformance 1 }

mplsLpsCompliances
   OBJECT IDENTIFIER ::= { mplsLpsConformance 2 }

----