Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt

From: <[email-masked]>
Date: Wed, 19 Apr 2006 20:32:35 -0400

Tom and Adrian,

Thanks for the great update.  A few minor comments.

Thanks, 
  Joan

*Compiles cleanly with smicngPRO and smilint.

1)  The expiration Date which appears as a page
header is incorrect:

Nadeau and Farrel             Expires April 2006             [Page 2]

2) gmplsInterfaceSignalingCaps OBJECT-TYPE

     REFERENCE
       "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472.
        2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473."
     DEFVAL { { rsvpGmpls } }

The above references have updates (e.g. see ccamp Charter page)
and so think these updating RFCs should also be included
here and in the Normative Reference section:

RFC 3472 is updated by RFC 4201
RFC 3473 is  updated by RFC 4003,RFC 4201, and RFC 4420

Please be sure to update these RFCs in other REFERENCE
clauses also.

3) The DESCRIPTION clause of gmplsInterfaceEntry
says"...A conceptual row in this table may also be created via SNMP
        SET commands or automatically by the LSR to supplement a
        conceptual row in the mplsInterfaceTable where the interface
        is not capable of GMPLS but where the other objects carried
        in this row provide useful additional information for an
        MPLS interface."

As I mentioned previously, I think you need to call out
these MPLS objects (i.e. the objects which do not require
GMPLS but are in the GMPLS-LSR-STD-MIB module)
in a separate conformance group, but as I look at this
MIB, it appears that all the objects seem to apply to 
MPLS, if this is accurate, then please update the
DESCRIPTION clauses of the ALL conformance groups to
indicate that these objects also apply to MPLS.

As an example:

   gmplsInterfaceGroup OBJECT-GROUP
     OBJECTS {
       gmplsInterfaceSignalingCaps,
       gmplsInterfaceRsvpHelloPeriod
     }
     STATUS  current
     DESCRIPTION
       "Collection of objects needed for GMPLS interface configuration
        and performance information."
   ::= { gmplsLsrGroups 1 }

Should be changed to:

"Collection of objects which provide additional information for
an MPLS interface and are needed for GMPLS interface configuration
and performance information."

4) Typo:

   gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE
     STATUS current
     DESCRIPTION
       "Compliance requirement for implementations that only provide
        read-only support for GMPLS-LSR-STD-MIB. Such devices can then
        be monitored but cannot be configured using this MIB modules."

Last part of the last sentence:

"...configured using this MIB module."

5) GMPLS-LABEL-STD-MIB

DESCRIPTION:
       "...
        This MIB module contains managed object definitions for labels
        within GMPLS systems as defined in:
        Generalized Multi-Protocol Label Switching (GMPLS) Signaling
        Functional Description, Berger, L. (Editor), RFC 3471,
        January 2003."

RFC 3471 is updated by RFC 4201,RFC 4328

Please add these other RFCs and be sure to add them
to the Normative Reference Section. 

6) Typo:

gmplsLabelTable
DESCRIPTION:

"... Labels in the tables in other MIB modules may be referred
     to using row pointer into this table."

Should be "using a row pointer"

7) Typo:

gmplsLabelTable
DESCRIPTION:

  "...a set of resources in the data plane. Practial examples are"

s/Practial/Practical

8) ReadOnly Compliance:

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus { active(1) }
     MIN-ACCESS   read-only
     DESCRIPTION
       "Support for notInService, createAndWait and notReady is not
        required."

Would change the DESCRIPTION to:
       "Write access is not required, and active is the only status that
       needs to be supported."

9) Full Compliance:

     OBJECT       gmplsLabelRowStatus
     SYNTAX       RowStatus { active(1), notInService(2) }
     WRITE-SYNTAX RowStatus { active(1), notInService(2),
                              createAndGo(4), destroy(6) }
     DESCRIPTION
       "Support for createAndWait and notReady is not required."

Would remove this.  Based on the 
gmplsLabelRowStatus object's DESCRIPTION
believe you should allow createAndWait and also
Agent could/should be able to report notReady.

10) NIT: 

Would remove the (for example, wavelength labels) because
I was expecting to see the example carried though and list
the groups for wavelength labels.

Also, need to add gmplsLabelWavebandGroup to the
list of groups.

Updates appear below:

     DESCRIPTION
       "Necessary, but not sufficient, set of objects to implement label
        table support. In addition, depending on the type of labels
        supported, the following other
        groups defined below are mandatory:
          gmplsLabelPacketGroup and/or
          gmplsLabelPortWavelengthGroup and/or
          gmplsLabelFreeformGroup and/or
          gmplsLabelSonetSdhGroup and/or
          gmplsLabelWavebandGroup."

11) Just a reminder to update Normative References
as discussed above:
RFC 3471 is updated by RFC 4201,RFC 4328
RFC 3472 is updated by RFC 4201
RFC 3473 is  updated by RFC 4003,RFC 4201, and RFC 4420

end.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 20 Apr 2006 17:15:31 -0400

Thanks again. Really just 2 quick questions below
for clarification and we can ship this one.

	--Tom

> *Compiles cleanly with smicngPRO and smilint.

	Yes!

> Nadeau and Farrel             Expires April 2006             [Page 2]

	Fixed.

> Please be sure to update these RFCs in other REFERENCE

	Fixed remainder in this module and in the gmpls-te mib
too.  There were no references in the tc mib.

> and performance information."

	Yes, they are all required. So do you think this statement
that calls out all objects is sufficient?  A similar change then
can be made for the in/out-segment tables:

    gmplsInSegmentGroup  OBJECT-GROUP
      OBJECTS {
        gmplsInSegmentDirection,
        gmplsInSegmentExtraParamsPtr
      }
      STATUS  current
      DESCRIPTION
        "Collection of objects which provide additional
         information for an MPLS in-segment and are needed
         for GMPLS in-segment configuration and performance
         information."
    ::= { gmplsLsrGroups 2 }

    gmplsOutSegmentGroup  OBJECT-GROUP
      OBJECTS {
        gmplsOutSegmentDirection,
        gmplsOutSegmentTTLDecrement,
        gmplsOutSegmentExtraParamsPtr
      }
      STATUS  current
      DESCRIPTION
        "Collection of objects which provide additional
         information for an MPLS out-segment and are needed
         for GMPLS out-segment configuration and performance
         information."
    ::= { gmplsLsrGroups 3 }

> "...configured using this MIB module."

	Got it.

> to the Normative Reference Section.

	Done.

>   "...a set of resources in the data plane. Practial examples are"

	Done.

>        "Write access is not required, and active is the only status  

	One minor change:

        "Write access is not required, and active(1) is
         the only status that needs to be supported."

> Would remove this.

	The description or the entire object?

> Based on the

	OK.

> RFC 3473 is  updated by RFC 4003,RFC 4201, and RFC 4420

	Done.

	--Tom

---

From: <[email-masked]>
Date: Thu, 20 Apr 2006 14:19:34 -0400

Replies inline.

----- Original Message -----
From: Thomas D. Nadeau <[email-masked]>
To: Cucchiara Joan <[email-masked]>
Cc: Adrian Farrel <[email-masked]>; <[email-masked]>; Wijnen Bert
<[email-masked]>; Dan Romascanu (E-mail) <[email-masked]>; Kireeti
Kompella <[email-masked]>
Sent: Thursday, April 20, 2006 5:15 PM
Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt

> can be made for the in/out-segment tables:

Yes,  adding these statements is sufficient, because it now
clarifies that all these objects apply to MPLS.

As we discussed early in the review process, believe that
email needs to be sent to the MPLS working group to
notify them of these objects since they apply to MPLS also.
I realize email was sent to MPLS wg on earlier versions but
would be good notify the MPLS wg again so they can see
the final version of these MIB docs.

> The description or the entire object?

The entire object.  If you allow createAndWait and notReady
then there is no need to special case this object in the conformance
statements.

Thanks,
  -Joan