[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-13.txt



Thanks for this great review Joan.

Seemsthat a new revision is warranted, and so I will record
these MIB doctor review comments in the ID tracker and
I suggest to Alex to mark the document as revised ID needed.

Bert

> -----Original Message-----
> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Tuesday, March 14, 2006 16:52
> 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-te-mib-13.txt
> 
> 
> Tom and Adrian,
> 
> Let me apologize for my tardiness in posting the
> review comments.
> 
> A great deal of work went into this latest draft.  Thank you.
> Compile issues are listed first, and are followed by
> review comments in order of the document.
> 
> Will have the other reviews out by tomorrow.
> 
> Thanks, Joan
> 
> 
> 
> Compile Issues:
> ===============
> 
> 
> 1)  smilint and smicngPRO complained
> due to REFERENCE clause for gmplsTunnelARHopTable
> needing an end quote:
> 
>    gmplsTunnelARHopTable  OBJECT-TYPE
> ...
>      REFERENCE
>     "1. Extensions to RSVP for LSP Tunnels, RFC 3209.
>      2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473.
>      3. Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
>         Management Information Base (MIB), RFC 3812.
> 
> ^ need end quote
> 
>    ::= { gmplsTeObjects 3 }
> 
> 
> 2) smicngPRO
> E: f(GMPLS-TE-STD-MIB), (1482,6) Item "gmplsTunnelUnnumIf"
> is not defined as an OBJECT-GROUP or NOTIFICATION-GROUP in
> module "GMPLS-TE-STD-MIB"
> 
> 
>    MANDATORY-GROUPS {
>      gmplsTunnelGroup,
>      gmplsTunnelScalarGroup,
>      gmplsTunnelIsIntfcGroup  <-- please add this
>      gmplsTunnelUnnumIf  <--- please remove this
>    }
> 
> 
> Also, please update the read-only conformance for gmplsTunnelUnnumIf.
> 
>    OBJECT gmplsTunnelUnnumIf
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Write access is not required."
> 
> 3) This is listed under compile issues because it might be
> an issue depending on what is really intended.
> 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 clause.  Please review all of these
> Compliance Statements with SYNTAX, only a couple are listed
> here:
> 
>    OBJECT gmplsTunnelLSPEncoding
>      SYNTAX IANAGmplsLSPEncodingType
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Write access is not required."
> 
>    OBJECT gmplsTunnelSwitchingType
>      SYNTAX IANAGmplsSwitchingType
>      MIN-ACCESS  read-only
>      DESCRIPTION
>        "Write access is not required."
> 
> 
> 
> SYNTAX clauses such as InetAddressType and InetAddress don't
> specify a subset, so need to ask if you intend
> to have a subset for these such as:
> 
>    SYNTAX       InetAddressType { unknown(0), ipv4(1), ipv6(2) }
> 
>    SYNTAX       InetAddress (SIZE(0|4|16))
> 
> 
> 4) Again, wrt Section 4.8 from RFC4181, it is recommended
> that if MIB authors intend to have Optional Groups that these
> be noted.  This was done for the Read-only compliance but not
> the Full-compliance, so would ask that all Optional Groups be
> specified as recommended by Section 4.8.  Reviewing these
> Compliances statements is difficult without this information.
> 
> 
> 
> Comments:
> -----------
> 
> 1) Table of Contents:
> 
>    3. The SNMP Management Framework .......................... 4
> 
> Should be:
>    3. The Internet-Standard Management Framework
> In other words, please change the title for section 3.
> 
> 
> 2) 5.7 Use of 32-bit and 64-bit Counters
> 
> Shouldn't the quote from RFC2863 be in quotes""?
> 
> 3) 6. Cross-referencing to the gmplsLabelTable
> 
> 2nd paragraph which begins:
>    The hop tables in this document (gmplsHopTable, gmplsCHopTable and
>    gmplsARHopTable) and the segment tables in the [RFC3813]
> 
> There is no gmplsHopTable, is this supposed to be: 
> gmplsTunnelHopTable?
> Similar comment with gmplsCHopTable and gmplsARHopTable.
> 
> 
> 4) gmplsTunnelPathComp
> 
> If the value of gmplsTunnelLSPEncoding is 'tunnelLspNotGmpls'
> does this object have meaning?
> 
> 5) gmplsTunnelErrorTable, would expect to see these objects
> contained in an MPLS group in Compliance/Conformance Statements.
> 
> 
> 6) gmplsTunnelErrorTLVs OBJECT-TYPE
> 
> When the string size is 0 this could indicate that
> no TLVs are present, right?
> That would be slightly more efficient than
> having to look at the first octet.
> If you agree, please modify the
> DESCRIPTION to reflect this.
> 
> 
> Conformace/Compliance:
> ---------------------
> 7) Please move some of the following comment to the
>    gmplsTeModuleReadOnlyCompliance DESCRIPTION
>    -- The mandatory group has to be implemented by all LSRs that
>    -- originate, terminate or act as transit for TE-LSPs/tunnels.
>    -- In addition, depending on the type of tunnels supported, other
>    -- groups become mandatory as explained below.
> 
> 
> 8) Already mentioned this but was expecting to see MPLS objects
> called out in a separate GROUP (e.g. objects which are valid when
> gmplsTunnelLSPEncoding
> has a value of 'tunnelLspNotGmpls', and other objects also).
> For folks that want to support these MPLS related objects
> prior to supporting GMPLS, this would be
> important to understand, so the more clearly noted by the MIB the
> better.
> 
> 
> 
> 9)  NIT: In the read-only conformance there is a comment:
> 
>    -- All scalars have max access read-only
> 
> which appears in front of a bunch of objects that are
> part of a table.  Please remove this comment since it
> doesn't apply.
> 
> 10) NIT:
> 
> --glmpsTunnelCHopTable
> 
>       ^^ typo
> 
> 
> 11) Security Section
> 
> NIT:     the network via SNMP. These are the tables and 
> objects and their
>    sensitivity/vulnerability:
> 
>    o  the gmplsTunnelTable, gmplsTunnelHopTable, 
> gmplsTunnelARHopTable,
>       gmplsTunnelCHopTable, gmplsTunnelReversePerfTable,
>       gmplsTunnelErrorTable collectively show the tunnel network
> 
> 
> Should have an "and"
> 
>    o  the gmplsTunnelTable, gmplsTunnelHopTable, 
> gmplsTunnelARHopTable,
>       gmplsTunnelCHopTable, gmplsTunnelReversePerfTable, and
> 
> ^^^
> 
>       gmplsTunnelErrorTable collectively show the tunnel network
> 
> 
> 
> 12) Normative References:
>    [RFC4328]    Papadimitriou, D., Ed., "Generalized MPLS Signalling
>                 Extensions for G.709 Optical Transport Networks
>                 Control", draft-ietf-ccamp-gmpls-g709, work 
> in progress.
>                           
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Please update.
> 
> --end of comments--
>