[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
On Mar 14, 2006, at 11:30 PM, <jcucchiara@mindspring.com>
<jcucchiara@mindspring.com> wrote:
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."
Fixed these.
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
Fixed all of the above.
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.
Can we talk about this one in more detail?
I am confused about what you are asking for specifically
here.
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?
OK, I updated the text a bit. please look at it.
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.
Yes, I think we should change this to SHOULD.
6) As previously mentioned could MPLS objects be denoted
in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other
objects).
Can you please explain why we would do this
instead of or in addition to what we are doing now?
I am confused since we are already requiring the objects
from the MPLS RFCs in the mandatory MODULE statements.
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.
OK.
--Tom
--end of comments --