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

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 4 May 2009 03:40:28 -0400

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 4 May 2009 11:11:39 +0200

Thanks, Joan. 

Dan

> -----Original Message-----
> From: Joan Cucchiara [mailto:[email-masked]] 
> Sent: Monday, May 04, 2009 10:40 AM
> To: Romascanu, Dan (Dan); Adrian Farrel; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Check for draft-ietf-mpls-p2mp-te-mib-09.txt to 
> Proposed Standard 
> 
> 
> 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.
> 
> 
> E: f(MPLS-TE-P2MP-STD-MIB.my), (532,35) Subtype size/range is 
> not compatible with base size/range
> "mplsTeP2mpTunnelDestSrcSubGroupID" must be defined with 
> syntax that includes a range
> W: f(MPLS-TE-P2MP-STD-MIB.my), (1205,19) MIN-ACCESS value 
> identical to access specified for "mplsTeP2mpTunnelP2mpXcIndex"
> 
> 
> smiLint gives:
> 
> 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'
> 
> 
> 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)
> 
> 
> 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).
> 
> reuses some of the same fields in the point-2-point (P2P) 
> protocol specification.
> 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).
> 
> actually happening with these MIB objects, the MIB objects 
> are in the MPLS-TE-STD-MIB (rfc3812) and the new DESCRIPTIONS 
> 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.
> 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