Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base
draft-ietf-ccamp-gmpls-te-mib-16

ANother MIB doctor review has been posted to the WG list.
Seems a new revision is warranted based on these comments.

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

State Change Notice email list have been change to kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com; dromasca@avaya.com from kireeti@juniper.net, adrian@olddog.co.uk; jcucchiara@mindspring.com; bwijnen@lucent.com

Additional review from a MIB Tunneling expert (also MIB doctor).
Bert Wijnen explicitly requested this review.

Posted to ccamp WG list as per below

-----Original Message-----
From: Wijnen, Bert (Bert)
Sent: Saturday, September 17, 2005 00:11
To: Dave Thaler; Tom Nadeau (E-mail); Adrian Farrel (E-mail)
Cc: Kireeti Kompella (E-mail)
Subject: RE: review tunneling aspects of:
Draft-ietf-ccamp-gmpls-te-mib-09.txt


Thanks for your review Dave. I think some of the issues
you raise have already been raised by other mIB Doctor review.
But I am sure that the authors (and WG) will merge all
reported questions/concerns/issues and try to address them
in the next revision.

I have copied the WG list, so they can see the review comments
and think about them or react.

Bert

> -----Original Message-----
> From: Dave Thaler [mailto:dthaler@windows.microsoft.com]
> Sent: Friday, September 16, 2005 23:40
> To: Wijnen, Bert (Bert)
> Cc: Adrian Farrel (E-mail); Kireeti Kompella (E-mail); Alex Zinin
> (E-mail)
> Subject: RE: review tunneling aspects of:
> Draft-ietf-ccamp-gmpls-te-mib-09.txt
>
>
> Ok here it is...
>
> Relationship to Tunnel MIB, Interfaces MIB, etc looks good.
>
> Issues found:
>
> 1) The MIB imports IpAddress and uses it for gmplsTunnelUpNotRecip
>    and gmplsTunnelDownNotRecip to instrument the recipient of
>    Notify messages.  It references RFC 3473.  However I can't
>    find anything in 3473 which restricts this to IPv4.  Instead
>    all the discussion around Notify messages (specifically
>    section 4.2.1) supports both IPv4 and IPv6.  Hence I believe
>    these objects should use InetAddress instead, and the MIB
>    should not import IpAddress.
>
> 2) gmplsTunnelErrorHelpString uses the DisplayString TC.
>    This TC cannot contain international strings.  Since the
>    string is defined as containing descriptions of recovery
>    actions and support advice, this should probably use
>    SnmpAdminString instead.
>
> 3) Regarding gmplsTunnelDown, the DESCRIPTION field says:
>          Note that an implementation SHOULD only issue one of
>          mplsTunnelDown and gmplsTunnelDown for a single event on a
>          single tunnel."
>
>    However, section 4.1 says:
>    - The GMPLS Tunnel Down Notification (gmplsTunnelDown) is
> intended to
>      be used in place of the mplsTunnelDown Notification defined in
>      [RFC3812].
>
>    The difference in wording is that the description field
>    is weaker and would allow either one, whereas 4.1 is
>    stronger saying it should always be gmpls.  The wording
>    should be consistent in the two places.
>
> 4) Error in description of gmplsTunnelIsNotIntfcGroup in compliance:
> gmplsTunnelIsIf must at least be read-only returning no(0)."
>      ^                                                    ^^^^^
>    There is no "gmplsTunnelIsIf", it should be mplsTunnelIsIf,
>    and the value should be false(2) not no(0).
>
> 5) The gmplsTunnelIsNotIntfcGroup contains gmplsTunnelUnnumIf
>    as a mandatory object.  This seems really odd to me, since
>    its DESCRIPTION says:
> This object is only used if mplsTunnelIsIf is set to 'true'.
>    and the compliance statement section for gmplsTunnelIsNotIntfcGroup
>    says (as noted in #4 above) that only TunnelIsIf = false
>    needs to be supported.  Hence, it seems that this object
>    should not be in this group.
>
> 6) The Counter64 objects are currently mandatory, in the same
>    conformance group as the Counter32 equivalents.  This means
>    that an SNMPv1-only agent cannot support this MIB.
>    Is this the intent?  If not, then the HC objects should be
>    in a separate group.
>
> -Dave
>
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> > Sent: Thursday, September 08, 2005 4:31 PM
> > To: Dave Thaler
> > Cc: Adrian Farrel (E-mail); Kireeti Kompella (E-mail); Alex Zinin
> > Subject: review tunneling aspects of: Draft-ietf-ccamp-gmpls-te-mib-09.txt
> >
> > Dave, can you take a look at this document
> > for any tunneling aspects?
> >
> > Thanks,
> > Bert

Additional review comments from another MIB Doctor,
David Harrington.

-----Original Message-----
From: David B Harrington [mailto:dbharrington@comcast.net]
Sent: Thursday, September 08, 2005 01:49
To: 'Thomas D. Nadeau'; 'Adrian Farrel'; kireeti@juniper.net
Cc: 'Wijnen, Bert (Bert)'; 'Alex Zinin (E-mail)'
Subject: Draft-ietf-ccamp-gmpls-te-mib-09.txt


Hi,

I am a MIB Doctor, and did a quick review even though I am not the MIB
Doctor for this document. I have some comments on the TE MIB:

1) The migration strategy section discusses other documents, such as
the GMPLSLSRMIB and RFC3813. Are these mentions necesssary in the TE
document? What happens if the other documents are not approved for
advancement?

2) Under terminology for ERLSP discusses in-segments and out-segments
and egress/ingress LSRs. I don't have a good knowledge of (G)MPLS, so
maybe this is a newbie mistake, but the ordering seems odd (in/out vs
out/in).

3) In section 4, "those tables may not be appropriate for measuring
peerformance on some types of GMPLS links." Doesn't this lead to
interoperability issues?

4) The first paragraph in section 4.1 could use some wordsmithing. In
addition, Notification is misspelled, and capitalized unnecessarily.
Does this notification obsolete the other notification? I am concerned
that there are two notification defined for the same purpose, and it
is not definitive which should be used when.

5) In section 5.1, for multipoint connections, are all points
represented in the table? If not, could someone inadvertently delete a
segment that is depended on for multipoint?

6) In section 5.1, the Textual Conventions are not defined by IANA.
IAMA only maintains the list of names and assignments.

7) In the mplsTunnelTable example in section 7, is 123.123.125.1 an IP
address? If so, is 123.123 one of the approved "example" addresses?

8) As with the other MIB modules in the series, the use of mplsStdMIB
as a root is NOT RECOMMENDED. I believe mib-2 is preferred. See mib
review guidelines.

9) Why are gmplTeScalars separated from gmplsTeObjects? They're all
objects. I think there is a preference for 0=notification, 1=objects,
and 2=conformance in the mib guidelines.

10) From the MIB review guidelines "The IpAddress type described in
RFC 2578 Section 7.1.5 SHOULD NOT be used in new MIB modules.  The
InetAddress/InetAddressType textual
  conventions [RFC3291bis] SHOULD be used instead." GmplsTunnelEntry
uses IPAddress.

11) In the gmplsTunnelLinkProtection object, what prevents unprotected
from being used in combination with other bits that indicate a
protection scheme?

12) gmplsTunnelPathComp says that it deprecates
mplsTunnelHopEntryPathComp. I believe the mplsTunnelHopEntryPathComp
needs to actually be present here with a status of deprecated. What
happens if a system only supports mpls and not gmpls? Is the object
mplsTunnelHopEntryPathComp still deprecated? It might be better to
support BOTH objects, so management applications that only support
MPLS MIBs would still work, but those that support GMPLS gets any
extra functionality of the gmpls object.

13) gmplsTunnelUpNotRecip defines an IPv4-only address for upstream
notifications. What happens in a network with only IPv6?

14) With SNMPv3, the address alone is insufficient to address a
notification; the security parameters are also required. See RFC 3413
for a description of the information required to configure
notification targets.

15) gmplsTunnelDownNotRecip has the problems as gmplsTunnelUpNotRecip.

16) gmplsTunnelARHopEntry needs wordsmithing.

17) gmplsTunnelReversePerfPackets and HCPackets, and PerfBytes and
HCPerfBytes are ambiguous. Are implementations required to support
both the Counter32 and the Counter64 versions, even though they count
the same thing? SNMPv1 is NOT RECOMMENDED. Why do we need a Counter32
object? Are there discointinuity situations? See mib guidelines
section 4.6.1.2.

18) gmplsTunnelErrorLastErrorType needs wordsmithing.

19) What happens to gmplsTunnelErrorLastTime if sysUptime resets?

20) This MIB module has many objects that are ignored of other objects
has "noError" or whatever. Do these objects EXIST if no error, and if
so what value should they default to? E.g., does the SNMP agent report
"noSuchObject" or an object value of zero? In SNMP, it is generally
preferred to have an object not exist, than to provide a default value
which might be misleading. If a managemret application cannot
distinguish which is the case, then the application is likely to
ignore the object and its value because it not be useful, and thus it
doesn't belong in a standard mib module.

21) gmplsTunnelErrorreporter - How does a management application know
whether the address represents the reporting node or the associated
resource? There should probably be a ReporterType to make this
distinction.

22) How does a manager know which implementation's set of error codes
are in use? In SNMP, we usually provide a mechanism to identify the
enterprise that defines the additional values, otherwise this can lead
to interoperability problems.

23) what is the maximum length of the gmplsTunnelErrorTLVs OCTET
STRING?

24) gmplsTunnelErrorHelpString uses DisplayString, and thus does not
support internationalized text. It should support UTF8. See mib review
guidelines Appendix B, Note 2.

25) gmplsTunnelDown - only one of mplsTunnelDown or gmplsTunnelDown
SHOULD be sent. Can it be standardized WHICH is sent in preference to
the other?

26) gmplsTunnelDown - should there be additional rate limiting when a
device with lots of tunnels goes down? See entConfigChange in RFC 4133
for an example.

27) The purpose of compliance groups is to standardize expectations
about what will be present in a compiant system. This MIB module has a
huge number of compliance groups, including many optional groups,
permitting many implementations with widely varying levels of support
to claim compliance. This strikes me as bad for interoperability.

The gmplsTunnelGroup has a rather complex approach. The purpose of
compliance statements is to encourage implenentors to provide
consistent levels of support, not to define compliance levels to match
existing proprietary combinations of levels of support.

Definign a group (gmplsTeNotificationGroup) in which "None is
mandatory" indicates to me that they shouldn't be in the standard
then.

28) "There are a number of management objects defined in these MIB
modules ..." This security Considerations should be about the objects
in the MIB module in THIS document, not the objects in some other
documents.

29) There is a boilerplate for MIB Security Considerations. The text
in the boilerplate has been changed here, such that it does not
represent the appropriate recommendations concerning VACM and USM. If
you feel the text must be changed, then ask for help crafting a
correctly wordsmithed alternative. In particular, "VACM and USM MUST
be used" is incorrect for a number of reasons. First, VACM and USM may
be replaced at some point, and the official SNMPv3 recommendation does
not require these specific pieces of SNMPv3 be used, they are only
currently mandatory-to-implement. Second, MUST has specific semantics
defined in RFC 2119, and this statement seems to use MUST incorrectly.
Please use the text from the boilerplate, which was carefully crafted
to represent the official IETF position.

30) There are quoted passages in the security considerations that are
not present in the security boilerplate. Please use the text from the
boilerplate, which was carefully crafted to represent the official
IETF position.

31) I think the description in the MODULE-IDENTITY clause for
IANA-GMPLS-MIB needs to include the copyright statement.

32) Can anybody request a new value for IANAGmplsLSPEncoding? What
rules should IANA follow in assigning new values? Are AnsiEtsiPdh and
SdhSonet and Fiber deprecated or obsolete?

33) Can anybody request a new value for IANAGmplsGPid or
IANAGmplsAdminStatusFlags? What rules should IANA follow in assigning
new values?

34) The references should be checked; at least one reference has no
citation.

David Harrington
dbharrington@comcast.net
IETF MIB Doctor

Copied from another email from MIB Doctor Joan.
These are comments that apply to 3 GMPLS MIB documents,
so also to this one.

---------

General comments for all 3 drafts:
================================================
1*) Suggestion only:
  When submitting these 3 GMPLS MIBs
  you may want to ask RFC-editor
  to give the GMPLS-TC-STD-MIB document the first
  RFC number, and that all 3 GMPLS MIB docs appear
  contiguously numbered.

  If you would like to incorporate this suggestion
  then you'd need to add a paragraph to the
  IANA Considerations section and put the usual
  RFC-editor disclaimers around your request, such
  as:

 
  (Note to RFC-Editor:)
  We request that you assign the first RFC number
  to the draft-ietf-ccamp-gmpls-tc-mib, and also
  assign contiguous numbers to all three GMPLS MIB
  docs, i.e. draft-ietf-ccamp-gmpls-tc-mib,
  draft-ietf-ccamp-gmpls-lsr-mib, and
  draft-ietf-ccamp-gmpls-te-mib.
  (Please remove this note prior to publication.)



2*) Table of Contents is incorrect, please
  regenerate it, (e.g. The SNMP Management Framework
  should be The Internet-Standard Management Framework).


3*) Question if these documents should have a
  contributors section.  It violates the guidelines
  of "RFC Editorial Guidelines and Procedures"
  http://www.rfc-editor.org/policy.html#policy.auth2

  There are many people listed under
  Authors but not listed on the front page,
  so how about adding a Contributors Section?

4*) Tom's Contact info needs to be updated to
  Boxborough.


5*) would be clearer to be consistent about
referring to MIB modules and always use the entire MIB name
and site the reference:
e.g. MPLS LSR MIB module or LSR MIB module,
    should be MPLS-LSR-STD-MIB module [RFC3813]

e.g. GMPLS LSR MIB module, should be
    GMPLS-LSR-STD-MIB module [RFCXXX] (NOTE to RFC-Editor:
    please fill in XXX with the RFC name for
    draft-ietf-ccamp-gmpls-lsr-mib and remove this note.)


6*) The term "extends" is used and since this term is applied
to GMPLS interfaces, the more appropriate phrase is
'sparse augments'.    Please change this in the text.



7*) ORGANIZATION, please add IETF
  as in "IETF Common Control and ...."


8*) DESCRIPTION
  Please change the first paragraph to:

            Copyright (C) The Internet Society (2005).  This version of
            this MIB module is part of RFC XXX; see the RFC itself for
            full legal notices.

The exception to this is the IANA-GMPLS-MIB module, which should
include:

      "Copyright (C) The Internet Society (2005). The initial version
        of this MIB module was published in RFC XXXX. For full legal
        notices see the RFC itself.  Supplementary information
        may be available on:
        http://www.ietf.org/copyrights/ianamib.html




9*) Please make sure to ask RFC-Editor to remove comments
    prior to publication, e.g.

    -- RFC Editor's Note (to be removed prior to publication):

    "Initial version published as part of RFC XXXX."
      -- replace XXX with actual RFC number & remove this note.


10*) Acknowledgements Section
  Please start off this section with:

This document is a product of the CCAMP Working Group. 

  and remove:

This draft is the work of the five authors listed in the next
  section.


11*) Please change "Informational References"
to "Informative References"

12*) There are a number of references (as discovered by
Bert) that aren't in the RFC expected format.
Please review all the references in this document and
the other GMPLS MIB docs.
Please see comments in the review of the
draft-ietf-ccamp-gmpls-lsr-mib-08.txt for
examples of references in the RFC format.

MIB doctor review by Joan Cucchiara.

-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Friday, September 09, 2005 04:00
To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Cc: bwijnen@lucent.com; jcucchiara@mindspring.com
Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-te-mib-09.txt



Hi Tom and Adrian,

Here are some comments on draft-ietf-ccamp-gmpls-te-mib-09.txt.
All 3 docs show a good deal of work.

  -Joan

draft-ietf-ccamp-gmpls-te-mib-09.txt
======================================

Section 1.1 Migration Strategy
------------------------------

1) Please remove "and OBJECT-IDENTIFIERS"

  Textual conventions and OBJECT-IDENTIFIERS are defined in [RFC3811]
  and [GMPLSTCMIB].


Section 5.4 gmplsTunnelCHoptable
---------------------------------

2) Please capitalize Table in the Section's title.


Section 8. GMPLS Traffic Engineering MIB Module
-----------------------------------------------

smicngPRO gives the following:

W: f(GMPLS-TE-STD-MIB), (1181,14) Item "gmplsTunnelErrorTLVs" should have
SIZE specified
W: f(GMPLS-TE-STD-MIB), (1362,13) For "gmplsTunnelDirection", syntax is
identical
W: f(GMPLS-TE-STD-MIB), (1371,13) For "gmplsTunnelPathComp", syntax is
identical
W: f(GMPLS-TE-STD-MIB), (1382,14) For "gmplsTunnelUpNotRecip", syntax is
identical
W: f(GMPLS-TE-STD-MIB), (1389,14) For "gmplsTunnelDownNotRecip", syntax is
identical
W: f(GMPLS-TE-STD-MIB), (1401,14) For "gmplsTunnelExtraParamsPtr", syntax
is identical



Disconnect of numbering in the Conformance Section
  \-3 gmplsTeConformance
    \-v-1 gmplsTeGroups
      | \-v-1 gmplsTunnelGroup

2 is missing
      |  |-3 gmplsTunnelSignaledGroup
      |  |-4 gmplsTunnelScalarGroup
      |  |-5 gmplsTunnelIsIntfcGroup
      |  |-6 gmplsTunnelIsNotIntfcGroup
      |  |-7 gmplsTunnelOptionalGroup
      |  \-8 gmplsTeNotificationGroup


3)  gmplsTunnelsConfigured OBJECT-TYPE
    SYNTAX  Unsigned32

SYNTAX should be Gauge32


4)  gmplsTunnelsActive OBJECT-TYPE
    SYNTAX  Unsigned32

SYNTAX should be Gauge32

5) gmplsTunnelTable

DESCRIPTION

      "The row status of an entry in this table is controlled by
        mplsTunnelRowStatus in the corresponding entry in
        mplsTunnelTable. That is, it is not permitted to create a row in
        this table, nor to modify an existing row, when the
        corresponding mplsTunnelRowStatus has value active(1)....

The sentence beginning with "That is,"  is awkward.  Could you say
something like:  A row in this table is created when a row is created
in the mplsTunnelTable.  Entries in this table cannot be modified
when the corresponding mplsTunnelRowStatus has a value of active(1).
The exception....

Please also update this other places in this MIB (e.g gmplsTunnelHopTable).


6) gmplsTunnelEntry
  DESCRIPTION:
      "...
        An entry can be created by a network administrator or by an SNMP
        agent as instructed by a signaling protocol."

Please change the above to:

"An entry can be created by a network administrator via SNMP SET commands, or
by the network management entity as instructed by a signaling
protocol."


7) gmplsTunnelUnnumIf

What IF-MIB object are referring to in the DESCRIPTION?
Could you state which object in the description?


8) gmplsTunnelAttributes
Could you specify what happens when the bit is set (i.e. 1)
vs. 0?


9) gmplsTunnelLSPEncoding

The DESCRIPTION states:
        ...A value of 'tunnelLspNotGmpls' indicates that GMPLS signaling is
        not in use. Some objects in this MIB module may be of use for
        MPLS signaling extensions that do not use GMPLS signaling. By
        setting this object to 'tunnelLspNotGmpls', an application may
        indicate that only those objects meaningful in MPLS should be
        examined....

I believe that such objects should be put in to an MPLS MIB module
and not included in this GMPLS MIB module.  This is also true with
the gmplsTunnelErrorTable.


10) gmplsTunnelLinkProtection
Same comment as with gmplsTunnelAttributes.


11) gmplsTunnelPathComp

DESCRIPTION states:
        This object deprecates mplsTunnelHopEntryPathComp."

The term "deprecates" is loaded.  Perhaps something like,
this object takes precedence over mplsTunnelHopEntryPathComp.
In other words, for GMPLS tunnels, the value of
mplsTunnelHopEntryPathComp is meaningless.

12) gmplsTunnelUpNotRecip

Need to use InetAddressType and InetAddress.  IpAddress
is not used in MIBs anymore.  Please be sure to support
both v4 and v6 IP address Types.  If you can't support
v6 for some reason, that should be stated clearly.

Please change the name of this object to:
gmplsTunnelUpstreamRecipientForNotify

13) gmplsTunnelDownNotRecip
Same comment as above wrt to IpAddress.

Please change the name to gmplsTunnelDownstreamRecipientForNotify


14) gmplsTunnelAdminStatusFlags (please see comments
regarding the name of this TC and make adjustments
to the name and DESCRIPTION of this object as appropriate).


15)    gmplsTunnelExtraParamsPtr  OBJECT-TYPE

This object does not seem appropriate for this MIB.
It would seem an enterprise MIB could do something
like this (and possibly not use a RowPointer) so
please explain what the intention is.


16)  gmplsTunnelHopTable  OBJECT-TYPE
        The storage type for an entry in this table is inherited from
        mplsTunnelHopStorageType in the corresponding entry in
        mplsTunnelHopTable.

Please change to:

The storage type for this entry is given by the value
of mplsTunnelHopStorageType in the corresponding entry in the
mplsTunnelHopTable.

17)  gmplsTunnelHopExpLabel OBJECT-TYPE

    DESCRIPTION
      "If gmplsTunnelHopLabelStatuses object indicates that a forward
        label is present and gmplsTunnelHopExpLabelPtr contains the
        value zeroDotZero, then the label to use on this hop is found in
        object encoded within a 32-bit integer."

Think the last part of this sentence is awkward:

...to use on this hop is represented by the value of this object.


18) gmplsTunnelHopExpLabel and gmplsTunnelHopExpLabelPtr

Need to add the word "Forward" in here as in
gmplsTunnelHopExpForwardLabel and gmplsTunnelHopExpForwardLabelPtr

That way it will be consistent with the Reverse counterparts.

19) gmplsTunnelHopExpRvrsLabel and gmplsTunnelHopExpRvrsLabelPtr

Please change Rvrs to Reverse.

20) gmplsTunnelHopLabelStatuses and gmplsTunnelARHopLabelStatuses

Please change Statuses to State.


21) gmplsTunnelARHopExpLable and gmplsTunnelARHopExpLabelPtr

Need to add the word "Forward" in here as in
gmplsTunnelARHopExpForwardLabel and gmplsTunnelARHopExpForwardLabelPtr

22) gmplsTunnelARHopExpRvrsLabel and gmplsTunnelARHopExpRvrsLabelPtr

Please change Rvrs to Reverse


23)    gmplsTunnelARHopProtection  OBJECT-TYPE

Please add what the BIT set (i.e. 1) vs. 0 means in the
DESCRIPTION.


24) gmplsTunnelCHopLabelTable objects

Similar comments regarding the objects in this table
to those above with regard to naming
conventions (Forward and Reverse) and DESCRIPTIONs.  Will not repeat the
details, please refer to above comments on the
prior 2 tables.


25) gmplsTunnelReversePerfTable
Please add to the DESCRIPTION how a user knows if
this is a bidirectional tunnel (i.e. what object
or objects in the gmplsTunnelTable need to have
what values?).


26) gmplsTunnelReversePerfPackets

Does this object represent the 32-bit
value of the least significant part of the
64-bit value (which is contained in gmplsTunnelReversePerfHCPackets)?

27) gmplsTunnelReversePerfBytes

Does this object represent the 32-bit
value of the least significant part of the
64-bit value (which is contained in gmplsTunnelReversePerfHCBytes)?

28) gmplsTunnelErrorTable  OBJECT-TYPE

Since this table applies to MPLS, it should be
put in a separate MIB module which is MPLS specific.  The
prefix of gmpls could be confusing.

29)    gmplsTunnelErrorTLVs OBJECT-TYPE

Need to add a variable size to this string.  When the string
size is 0 that would indicate that no TLVs are present, so
the DESCRIPTION should be modified to reflect this.

30)  gmplsTunnelErrorHelpString OBJECT-TYPE
    SYNTAX  DisplayString

DisplayString is not used in newer MIBs because it does not
meet internationalization standards, better to use
SnmpAdminString or something which meets internationalization
standards.

31) Compliance

Please move some of the following comment in the
DESCRIPTION of gmplsTeModuleFullCompliance

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

32) gmplsTunnelUnnumIf does not appear in the ReadOnly compliance
and it probably should.





Section 11.2.1. IANA-GMPLS-MIB Definition
-----------------------------------------
33) Please change the name of this MIB to
IANA-GMPLS-TC-MIB

and instead of:  ianaGmpls MODULE-IDENTITY
please use:      ianaGmplsTcMIB MODULE-IDENTITY



34)  Please add the following to the DESCRIPTION:
      "Copyright (C) The Internet Society (2005). The initial version
        of this MIB module was published in RFC XXXX. For full legal
        notices see the RFC itself.  Supplementary information
        may be available on:
        http://www.ietf.org/copyrights/ianamib.html



35) Please change GMPLS-TE-MIB's  to GMPLS-TE-STD-MIB's [RFCXXX] (RFC-Editor
please fill in the XXX based on the RFC number for
draft-ietf-ccamp-gmpls-te-mib
and remove this note)  in the
DESCRIPTION clauses of ALL TCs.


36) Please change the name IANAGmplsLSPEncoding to
  IANAGmplsLSPEncodingType.  (more closely matches what's on
IANA's website now)

37) Please change the name IANAGmplsGPid to
  IANAGmplsGeneralizedPid 


38) I believe that the TC

  IANAGmplsAdminStatusFlags ::= TEXTUAL-CONVENTION

should be put in the GMPLS-TC-STD-MIB or should just
remain in the GMPLS-TE-STD-MIB.  The reason is that this
is not an assigned numbers list maintained by IANA, so
should not be in the IANA GMPLS MIB.  If I am incorrect
about this please let me know, but I didn't see an IANA
maintained Administrative Status Information enum.

Additionally, this should be renamed to
GmplsAdminStatusInformation which more closely matches rfc3471.

39) Several comments on the SYNTAX clause:

40a) smicngPRO gives the error

E: f(IANA-GMPLS-MIB.my), (252,22) Named bits for BITS
must be in contiguous positions

      SYNTAX  BITS {
                    delInProgress (0),
                    adminDown (1),
                    testing (2),
                    reflect (31) 
                  }


RFC2578 specifies that BITS should be contiguous
(although there are exceptions to this, but this
object does not seem to be an exception).



Could delInProgress, be renamed to deleteInProgress ?
Could adminDown be renamed to administrativelyDown?
These names more closely match 3471.


40b)  Please put in the specific section number on this
reference (section 8?).




-- the end --