Last Call Review of draft-ietf-mpls-p2mp-te-mib-
review-ietf-mpls-p2mp-te-mib-secdir-lc-nystrom-2009-05-24-00

Request Review of draft-ietf-mpls-p2mp-te-mib
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-05
Requested 2009-04-03
Authors Adrian Farrel, Seisho Yasukawa, Thomas Nadeau
Draft last updated 2009-05-24
Completed reviews Secdir Last Call review of -?? by Magnus Nystrom
Assignment Reviewer Magnus Nystrom
State Completed
Review review-ietf-mpls-p2mp-te-mib-secdir-lc-nystrom-2009-05-24
Review completed: 2009-05-24

Review
review-ietf-mpls-p2mp-te-mib-secdir-lc-nystrom-2009-05-24

I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security area 


directors.  Document editors and WG chairs should treat these comments 


just like any other last call comments.




Background
----------


This document describes managed objects for point-to-multipoint 


MultiProtocol Label Switching based traffic engineering.




Comments
--------


This draft reads well to me and the examples of use of the managed objects 


are very helpful.






In Section 4.2, several MPLS-TE-STD-MIB objects with changed semantics in 


the context of MPLS-TE-P2MP-STD-MIB are described, for example 


mplsTunnelXCPointer. The text states that in the case of P2MP MPLS, the 


value for several of these objects SHOULD be set to 0 (or 0.0). Should not 


this be a "SHALL/MUST" rather than a "SHOULD" for P2MP TE systems? This 


since if a P2MP TE system does not set them to zero but to some other 


value, it seems as if a legacy P2P MPLS systems reading the same objects 


could become confused (I realize that not setting these objects' values to 


zero will not hurt other P2MP TE systems as they ignore these objects



anyway).



In Section 8, Even though the acronyms VACM and USM are spelled out in 


-09, it would be helpful for the reader with a reference to the documents



specifying these modules (RFC 3415 and RFC 3414, I believe)

-- Magnus