[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





Tom and Adrian,

Let me apologize for my tardiness in posting the
review comments.

	Let me apologize for my tardiness in
replying to you. *)


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
   }

	Done.

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

	done.

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

	I found about 6 more, and fixed them.



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.

	I don't understand. There are 5 groups, two of which
are specified as Mandatory, and the other three are explained
to be optional and why below that.

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

	Perhaps, but we were just following
what was approved in section 6 of RFC3813:

6.  Use of 32-bit and 64-bit Counters

   64-bit counters are provided in this MIB module for high speed
interfaces where the use of 32-bit counters might be impractical. The
   requirements on the use of 32-bit and 64-bit counters (copied
   verbatim from [RFC2863]) are as follows.

   For interfaces that operate at 20,000,000 (20 million) bits per
   second or less, 32-bit byte and packet counters MUST be supported.
   For interfaces that operate faster than 20,000,000 bits/second, and
   slower than 650,000,000 bits/second, 32-bit packet counters MUST be
   supported and 64-bit octet counters MUST be supported.  For
   interfaces that operate at 650,000,000 bits/second or faster, 64-bit
   packet counters AND 64-bit octet counters MUST be supported.


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.

	Can you explain what "an MPLS group" would be
specifically?



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.

        "The sequence of interface identifier TLVs reported with the
        error by the protocol code. The interpretation of the TLVs and
        the encoding within the protocol are described in the
references. A value of zero in the first octet indicates that no
        TLVs are present."




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