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

["Joan Cucchiara" <jcucchiara at mindspring.com>]

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