[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt
Thanks Joan for anotehr great review.
From what I read here, it seems we need yet another revision.
So I am recording these MIB doctor comments in the ID tracker
and I sugegst to ALEX to mark the document as revised ID needed.
Bert
> -----Original Message-----
> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Wednesday, March 15, 2006 06:31
> To: ccamp@ops.ietf.org
> Cc: Wijnen, Bert (Bert); Dan Romascanu (E-mail); Adrian
> Farrel (E-mail);
> Bill Fenner (E-mail); Alex Zinin (E-mail); Tom Nadeau (E-mail)
> Subject: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt
>
>
> Hi Tom and Adrian,
>
> Thank you for all the great updates
> to this draft. Compile issues listed
> first, followed by review comments.
>
> Thanks,
> Joan
>
> Compile Issues
> ================
>
> GMPLS-LSR-STD-MIB
> ====================
> 1) smicngPRO
> W: f(GMPLS-LSR-STD-MIB), (391,18) For
> "gmplsOutSegmentTTLDecrement", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (397,18) For
> "gmplsInSegmentExtraParamsPtr", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (404,18) For
> "gmplsOutSegmentExtraParamsPtr", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (447,14) For
> "gmplsInterfaceSignalingCaps", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (460,18) For
> "gmplsInterfaceRsvpHelloPeriod", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (474,18) For
> "gmplsInSegmentExtraParamsPtr", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (488,18) For
> "gmplsOutSegmentTTLDecrement", syntax is identical
> W: f(GMPLS-LSR-STD-MIB), (494,18) For "
> gmplsOutSegmentExtraParamsPtr", syntax is identical
>
>
> RFC4181 "Guidelines for MIB Documents",
> Section 4.8. Compliance Statements,
> recommends using SYNTAX clauses to denote
> a subset of values for an object.
> If you don't intend to have a subset for these
> then please remove the SYNTAX. Please review all of these
> Compliance Statements with SYNTAX, only a couple are listed
> here:
>
> OBJECT gmplsInterfaceRsvpHelloPeriod
> SYNTAX Unsigned32
> MIN-ACCESS read-only
> DESCRIPTION
> "Write access is not required."
>
> OBJECT gmplsInSegmentDirection
> SYNTAX GmplsSegmentDirectionTC
> MIN-ACCESS read-only
> DESCRIPTION
> "Write access is not required. Only forward(1) needs to be
> supported by implementations that only support unidirectional
> LSPs."
>
> OBJECT gmplsInSegmentExtraParamsPtr
> SYNTAX RowPointer
> MIN-ACCESS read-only
> DESCRIPTION
> "Write access is not required."
>
>
>
>
>
>
> GMPLS-LABEL-STD-MIB
> ===================
>
> 1) smicngPRO and smiLint flagged line 622
>
> E: f(GMPLS-LABEL-STD-MIB), (622,6) syntax error
> E: f(GMPLS-LABEL-STD-MIB), (622,6) Syntax for OBJECT clause is
> "OBJECT" <objName> <optSyntax> <optWriteSyn> <optAccess> <desc>
> E: f(GMPLS-LABEL-STD-MIB), (518,12) Group "gmplsLabelTableGroup" is
> both a MANDATORY and conditional group for module
> "GMPLS-LABEL-STD-MIB"
>
> OBJECT gmplsLabelRowStatus
> MIN-ACCESS read-only
> --> SYNTAX RowStatus { active(1) }
> DESCRIPTION
> "Support for notInService, createAndWait and notReady is not
> required."
>
> Need to put SYNTAX clause before MIN-ACCESS clause.
>
> 2) E: f(GMPLS-LABEL-STD-MIB), (518,12)
> Group "gmplsLabelTableGroup" is both a MANDATORY and
> conditional group for module "GMPLS-LABEL-STD-MIB"
>
> The above is flagged as an error but is actually more
> pervasive than just this one error: both the
> FullCompliance and the Read-only Compliance statements have
> Groups listed as Mandatory but then appear as Optional.
> This needs to be clarified per RFC4181 "Guidelines for MIB Documents",
> Section 4.8. Compliance Statements.
>
> Related to this, the following groups are currently listed as
> Mandatory under Full compliance, but would think
> that these only apply if the device has certain
> interfaces (e.g. gmplsLabelSonetSdhGroup if Sonet
> interfaces are on the device), is this
> an Optional Group? What about these other groups?
>
> gmplsLabelPacketGroup,
> gmplsLabelPortWavelengthGroup,
> gmplsLabelFreeformGroup,
> gmplsLabelSonetSdhGroup,
> gmplsLabelWavebandGroup
>
>
> 3) Same comment as with the GMPLS-TE-STD-MIB wrt having
> an MPLS GROUP in the compliances statements. Would be
> most helpful to know what objects apply to MPLS.
>
>
>
> Comments in order of document.
> ==============================
> 1) Table of Contents
>
> 3. The SNMP Management Framework .................... 4
> Please rename to:
>
> The Internet-Standard Management Framework
>
> 2) 1.1. Migration Strategy, 5th paragraph:
>
> the various label pointer objects in the MPLS-STD-LSR-MIB module
> ^^^^
> Please fix: MPLS-STD-LSR-MIB to MPLS-LSR-STD-MIB
>
> 3) Please remove "and OBJECT-IDENTIFIERS" in the last paragraph
>
> Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811]
> and [GMPLSTCMIB] ...
>
>
> 4) gmplsLsrModuleFullCompliance MODULE-COMPLIANCE
>
> 2 issues:
> a) The following 2 objects could have an MIN-ACCESS of
> read-only since the DEFVAL is forward.
>
> b) the DESCRIPTION is a little awkward, could this be reworded:
> "The only valid value for unidirectional LSPs is forward(1)."
>
> This would need to be updated in the read-only section also.
> (Similar comments for gmplsOutSegmentDirection).
>
> OBJECT gmplsInSegmentDirection
> SYNTAX GmplsSegmentDirectionTC
> MIN-ACCESS read-write
> DESCRIPTION
> "Only forward(1) needs to be supported by implementations that
> only support unidirectional LSPs."
>
> OBJECT gmplsOutSegmentDirection
> SYNTAX GmplsSegmentDirectionTC
> MIN-ACCESS read-write
> DESCRIPTION
> "Only forward(1) needs to be supported by implementations that
> only support unidirectional LSPs."
>
> GMPLS-LABEL-STD-MIB
> ========================
> 5) gmplsLabelInterface and gmplsLabelIndex
>
> I had a question regarding these 2 indices: if there is a
> per-platform
> label, MUST both of these values be zero? Is there any other
> circumstance
> in which both would or could be zero?
>
> I was a little confused on the use of "could" and "may result" and was
> wondering if this should be made a little more forceful.
>
>
> 6) As previously mentioned could MPLS objects be denoted
> in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other
> objects).
>
> 7) Please put the comment in the DESCRIPTION clause of
> the gmplsLabelModuleFullCompliance.
> -- The mandatory groups have to be implemented by GMPLS LSRs
> -- claiming support for this MIB module. This MIB module is,
> -- however, not mandatory for a working implementation of a GMPLS
> -- LSR with full MIB support if the GMPLS labels in use can be
> -- represented within a 32 bit quantity.
>
>
> --end of comments --
>
>