Subject: RE: MIB Dr. Review of draft-ietf-ccamp-gmpls-lsr-mib-11.txt

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 17 Mar 2006 15:32:23 +0100

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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2006 06:31
> To: [email-masked]
> 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 --
> 
>