[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIB-DOCTORS] Check for draft-ietf-mpls-p2mp-te-mib-09.txt to Proposed Standard



Thanks, Joan. 

Dan
 

> -----Original Message-----
> From: Joan Cucchiara [mailto:jcucchiara at mindspring.com] 
> Sent: Monday, May 04, 2009 10:40 AM
> To: Romascanu, Dan (Dan); Adrian Farrel; 
> s.yasukawa at hco.ntt.co.jp; tom.nadeau at bt.com
> Cc: mib-doctors at ietf.org
> Subject: Check for draft-ietf-mpls-p2mp-te-mib-09.txt to 
> Proposed Standard 
> 
> 
> Hi Adrian, Seisho and Tom,
> 
> I was asked to do a check on this document for the IESG telechat.
> 
> First the compiler output, followed by 3 comments on the document.
> 
> 
> smicngPRO gives the following output:
> 
> E: f(MPLS-TE-P2MP-STD-MIB.my), (532,35) Subtype size/range is 
> not compatible with base size/range
> E: f(MPLS-TE-P2MP-STD-MIB.my), (449,16) Index item 
> "mplsTeP2mpTunnelDestSrcSubGroupID" must be defined with 
> syntax that includes a range
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1261,10) Item 
> "mplsTeP2mpTunnelDestSrcSubGroupOriginType" in object-group 
> "mplsTeP2mpGeneralGroup" has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1262,10) Item 
> "mplsTeP2mpTunnelDestSrcSubGroupOrigin" in object-group 
> "mplsTeP2mpGeneralGroup" has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1263,10) Item 
> "mplsTeP2mpTunnelDestSrcSubGroupID" in object-group 
> "mplsTeP2mpGeneralGroup" 
> has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1264,10) Item 
> "mplsTeP2mpTunnelDestSubGroupOriginType" in object-group 
> "mplsTeP2mpGeneralGroup" has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1265,10) Item 
> "mplsTeP2mpTunnelDestSubGroupOrigin" in object-group 
> "mplsTeP2mpGeneralGroup" has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1266,10) Item 
> "mplsTeP2mpTunnelDestSubGroupID" in object-group 
> "mplsTeP2mpGeneralGroup" 
> has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1267,10) Item 
> "mplsTeP2mpTunnelDestDestinationType" in object-group 
> "mplsTeP2mpGeneralGroup" has access of "not-accessible"
> E: f(MPLS-TE-P2MP-STD-MIB.my), (1268,10) Item 
> "mplsTeP2mpTunnelDestDestination" in object-group 
> "mplsTeP2mpGeneralGroup" 
> has access of "not-accessible"
> W: f(MPLS-TE-P2MP-STD-MIB.my), (1205,19) MIN-ACCESS value 
> identical to access specified for "mplsTeP2mpTunnelP2mpXcIndex"
> 
> 
> smiLint gives:
> 
> Severity level requested: 6
> 
> Line  Severity  Problem
> 1250 3 node `mplsTeP2mpTunnelDestSrcSubGroupOriginType' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestSrcSubGroupOrigin' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestSrcSubGroupID' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestSubGroupOriginType' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestSubGroupOrigin' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestSubGroupID' is an invalid 
> member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestDestinationType' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
>         3 node `mplsTeP2mpTunnelDestDestination' is an 
> invalid member of group `mplsTeP2mpGeneralGroup'
> 
> 
> IDNITS passes with no errors and no warnings.
> 
> 
> 
> 
> 1) need to root MIB at mib-2
> Please see rfc4181.txt (Guidelines for Authors and Reviewers 
> of MIB Documents), Section 3.5.2.
> 
> You will need to IMPORT mib-2  from SNMPv2-SMI (and remove mplsStdMIB)
> 
> 
> 2) top-level OID structure is not as recommended by 
> rfc4181.txt (Guidelines for Authors and Reviewers of MIB 
> Documents), Appendix D: Suggested OID Layout
> 
>          xxxMIB
>          |
>          +-- xxxNotifications(0)
>          +-- xxxObjects(1)
>          +-- xxxConformance(2)
>              |
>              +-- xxxCompliances(1)
>              +-- xxxGroups(2)
> 
> 
> The MPLS-TE-P2MP-STD-MIB has:
> 
>    mplsTeP2mpStdMIB
>    |
>    +-- mplsTeP2mpNotifications OBJECT IDENTIFIER ::= { 
> mplsTeP2mpStdMIB 0 }
>    +-- mplsTeP2mpScalers       OBJECT IDENTIFIER ::= { 
> mplsTeP2mpStdMIB 1 }
>    +-- mplsTeP2mpObjects       OBJECT IDENTIFIER ::= { 
> mplsTeP2mpStdMIB 2 }
>    +-- mplsTeP2mpConformance   OBJECT IDENTIFIER ::= { 
> mplsTeP2mpStdMIB 3 }
>        |
>        +-- mplsTeP2mpGroups OBJECT IDENTIFIER ::= { 
> mplsTeP2mpConformance
> 1 }
>        +-- mplsTeP2mpCompliances OBJECT IDENTIFIER ::= { 
> mplsTeP2mpConformance 2 }
> 
> 
> Note also, Groups and Compliances are reversed.
> 
> 
> 
> 3) One concern that we did discuss at length during the early 
> review is Section 4.2 (and its subsection 4.2.1 and  
> particularly 4.2.2 regarding settable objects).
> 
> The protocol specification for the point-2-multipoint (P2MP) 
> reuses some of the same fields in the point-2-point (P2P) 
> protocol specification.
> So in other words, a Session object which was designed for 
> point-2-point
> (P2P) now
> has some of the same fields reused for point-2-multipoint (P2MP).
> These fields take on different meanings when the protocol is P2MP.
> 
> My concern is that this "reuse" in the protocol specification 
> is not practical for MIB objects.  I was concerned and still 
> am concerned that the "reuse" for MIB objects, changes the 
> semantics of the original objects in the MPLS-TE-STD-MIB (rfc3812).
> 
> While the authors are very thorough in explanationing what is 
> actually happening with these MIB objects, the MIB objects 
> are in the MPLS-TE-STD-MIB (rfc3812) and the new DESCRIPTIONS 
> appear in this draft (MPLS-TE-P2MP-STD-MIB).
> 
> The MIB Doctors were consulted via the mib dr email list and 
> a couple of MIB Doctors suggested that new MIB objects be 
> added, as opposed to reusing existing MIB objects.
> This suggestion was communicated to the authors, but does not 
> appear in this draft.
> Note: some of the reused objects are indexes which are used 
> in tables in
> rfc3812 (MPLS-TE-STD-MIB).
> 
> As a MIB Doctor,I want to raise the concern that this MIB 
> draft (MPLS-TE-P2MP-STD-MIB) seems to change the semantics of 
> some objects in the MPLS-TE-STD-MIB (RFC3812).
> 
> 
> The remainder of my suggestions for the early review were addressed.
> 
>    Thanks,
>      -Joan
> 
>