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

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--