[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt
Replies inline.
----- Original Message -----
From: Thomas D. Nadeau <tnadeau@cisco.com>
To: Cucchiara Joan <jcucchiara@mindspring.com>
Cc: Adrian Farrel <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>; Wijnen Bert
<bwijnen@lucent.com>; Dan Romascanu (E-mail) <dromasca@avaya.com>; Kireeti
Kompella <kireeti@juniper.net>
Sent: Thursday, April 20, 2006 5:15 PM
Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt
>
> Thanks again. Really just 2 quick questions below
> for clarification and we can ship this one.
>
> --Tom
>
> >
> > Tom and Adrian,
> >
> > Thanks for the great update. A few minor comments.
> >
> > Thanks,
> > Joan
> >
> >
> > *Compiles cleanly with smicngPRO and smilint.
>
> Yes!
>
> > 1) The expiration Date which appears as a page
> > header is incorrect:
> >
> > Nadeau and Farrel Expires April 2006 [Page 2]
>
> Fixed.
>
> > 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.
>
> Fixed remainder in this module and in the gmpls-te mib
> too. There were no references in the tc mib.
>
> > 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."
>
> 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:
>
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.
> 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 }
>
>
> > 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."
>
> Got it.
>
> > 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.
>
> Done.
>
> > 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
>
>
> Done.
>
> > 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."
>
> One minor change:
>
> "Write access is not required, and active(1) 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.
>
> 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
>
> > 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."
> >
>
> OK.
>
> > 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.
>
> Done.
>
> --Tom
>