Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base
draft-ietf-ccamp-gmpls-lsr-mib-15

[Ballot comment]
COMMENT:

draft-ietf-ccamp-gmpls-lsr-mib-14.txt

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note


The intention is I believe:

    ::= { mplsStdMIB YYY }

Also:

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

should rather be:

    ::= { mplsStdMIB ZZZ }

in draft-ietf-ccamp-gmpls-tc-mib-10.txt

      -- This MIB module is contained in the OID sub-tree
      -- rooted at mplsStdMIB.
      "Initial version published as part of RFC XXX."
  ::= { mplsStdMIB XXX }

-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

should be:

  ::= { mplsStdMIB YYY }

[Ballot comment]
COMMENT:

draft-ietf-ccamp-gmpls-lsr-mib-14.txt

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note


The intention is I believe:

    ::= { mplsStdMIB YYY }

Also:

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

should rather be:

    ::= { mplsStdMIB ZZZ }

in draft-ietf-ccamp-gmpls-tc-mib-10.txt

      -- This MIB module is contained in the OID sub-tree
      -- rooted at mplsStdMIB.
      "Initial version published as part of RFC XXX."
  ::= { mplsStdMIB XXX }

-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

should be:

  ::= { mplsStdMIB YYY }

[Ballot comment]
COMMENT:

draft-ietf-ccamp-gmpls-lsr-mib-14.txt

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note


The intention is I believe:

    ::= { mplsStdMIB YYY }

Also:

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

should rather be:

    ::= { mplsStdMIB ZZZ }

in draft-ietf-ccamp-gmpls-tc-mib-10.txt

      -- This MIB module is contained in the OID sub-tree
      -- rooted at mplsStdMIB.
      "Initial version published as part of RFC XXX."
  ::= { mplsStdMIB XXX }

-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

should be:

  ::= { mplsStdMIB YYY }

[Ballot discuss]
DISCUSS:

ietf-ccamp-gmpls-te-mib-15.txt based on comments from Dave Thaler and Bert Wijnen.

ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module under transmission. That seems weird. By convention, transmission assignments generally correspond to ifType values, which would result in a "Relationship to the Interfaces MIB" section of the document.  If they don't define a new ifType value, I don't see why it should be under transmission.  If, on the other hand, this is intended to be the MIB for ifType = mpls (166), then it should have a "Relationship to the Interfaces MIB" section. I think it would be better to put this under the mib-2 tree or under the mplsStdMIB tree

[Ballot discuss]
DISCUSS:

ietf-ccamp-gmpls-te-mib-15.txt based on comments from Dave Thaler and Bert Wijnen.

ietf-ccamp-gmpls-te-mib-15.txt is requesting assignment of a TC module under transmission. That seems weird. By convention, transmission assignments generally correspond to ifType values, which would result in a "Relationship to the Interfaces MIB" section of the document.  If they don't define a new ifType value, I don't see why it should be under transmission.  If, on the other hand, this is intended to be the MIB for ifType = mpls (166), then it should have a "Relationship to the Interfaces MIB" section. I think it would be better to put this under the mib-2 tree or under the mplsStdMIB tree

COMMENT:

draft-ietf-ccamp-gmpls-lsr-mib-14.txt

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note


The intention is I believe:

    ::= { mplsStdMIB YYY }

Also:

    DESCRIPTION
      "Initial version issued as part of RFC XXX."
    ::= { mplsStdMIB XXX }
-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace ZZZ above with the OID assigned by IANA
-- and remove this note

should rather be:

    ::= { mplsStdMIB ZZZ }

in draft-ietf-ccamp-gmpls-tc-mib-10.txt

      -- This MIB module is contained in the OID sub-tree
      -- rooted at mplsStdMIB.
      "Initial version published as part of RFC XXX."
  ::= { mplsStdMIB XXX }

-- RFC Editor. Please replace XXX above with the correct RFC number and
-- remove this note.

-- RFC Editor. Please replace YYY above with the OID assigned by IANA
-- and remove this note

should be:

  ::= { mplsStdMIB YYY }

IANA Last Call Comments:

Upon approval of this document, the IANA will make the following assignments
in the "NETWORK MANAGEMENT PARAMETERS" registry located at
http://www.iana.org/assignments/smi-numbers
in table:
...mib-2.transmission.mplsStdMIB (1.3.6.1.2.1.10.166)

Decimal Name References
------- ----- ----------

TBD+2 GMPLS-LSR-STD-MIB [RFC-ccamp-gmpls-lsr-mib]
TBD+3 GMPLS-LABEL-STD-MIB [RFC-ccamp-gmpls-lsr-mib]

We understand the above to be the only IANA Actions for this document.

[Ballot discuss]
draft-ietf-ccamp-gmpls-te-mib-15:
  I don't understand gmplsTunnelLinkProtection.  I gather it is
  described in RFC3471.  However it seems like this ought to be
  discussed in the security considerations.

[Ballot comment]
draft-ietf-ccamp-gmpls-lsr-mib-14

Section 1., paragraph 2:
>    Comments should be made directly to the CCAMP mailing list at
>    ccamp@ops.ietf.org.

  Remove.


Section 1.1., paragraph 2:
>    LSRs may be migrated to be modeled and managed using the MIB modules
>    in this document in order to migrate the LSRs to GMPLS support, or to
>    take advandtage of additional MIB objects defined in these MIB

  Nit: s/advandtage/advantage/


Section 4.2., paragraph 10:
>    - Optionally specifying segment traffic parameters in the
>      MPLS-LSR-STD-MIB module [RCF3813].

  Nit: s/[RCF3813]./[RFC3813]./


Section 6., paragraph 10:
>      -- RowPointer MUST point to the first accsesible column.

  Nit: s/accsesible/accessible/


Section 7., paragraph 55:
Section 7., paragraph 57:
Section 7., paragraph 72:
Section 7., paragraph 74:
>        "The only valid value for unidrectional LSPs is forward(1)."

  Nit: s/unidrectional/unidirectional/


Section 9., paragraph 7:
>    if the network itself is secure (for example by using IPSec), even

  Nit: s/IPSec),/IPsec),/


Section 10., paragraph 0:
>    10. Acknowledgments

  Nit: Typically after IANA considerations.


Section 10., paragraph 2:
>    This document extends [RFC3813].

  "Extends" as in "updates?" If so, must reflect in
  headers/abstract/intro.


Section 11., paragraph 3:
>    New assignments can only be made via a Standards Action as specified in
>    [RFC2434].

  Missing Reference: 'RFC2434' is mentioned on line 1867, but not
  defined

------------------------------------------------------------------------------
draft-ietf-ccamp-gmpls-tc-mib-10

Section 1., paragraph 3:
>    Comments should be made directly to the CCAMP mailing list at
>    ccamp@ops.ietf.org.

  Nit: Remove.


Section 3., paragraph 23:
>        For manually
>        configured bidirecitonal LSPs, an arbitrary decision must be

  Nit: s/bidirecitonal/bidirectional/


Section 5., paragraph 3:
>    New assignments can only be made via a Standards Action as specified in
>    [RFC2434].

  Nit: Missing Reference: 'RFC2434' is mentioned on line 274, but not
  defined

------------------------------------------------------------------------------
draft-ietf-ccamp-gmpls-te-mib-15

Section 1.1., paragraph 2:
>    LSRs may be migrated to model and manage their TE LSPs using the MIB
>    modules in this document in order to migrate the LSRs to GMPLS
>    support, or to take advandtage of additional MIB objects defined in

  Nit: s/advandtage/advantage/


Section 8., paragraph 185:
>        If the value of
>        gmplsTunnelErrorLastErrorType is protocol (2) the error should
>        be interpreted in the context of the signling protocol

  Nit: s/signling/signaling/


Section 8., paragraph 198:
>          The notification rate applies to the sum
>          of all notificaitons in the MPLS-TE-STD-MIB and

  Nit: s/notificaitons/notifications/


Section 9., paragraph 7:
>    if the network itself is secure (for example by using IPSec), even

  Nit: s/IPSec),/IPsec),/


Section 12.1., paragraph 22:
>    [GMPLSTCMIB] Nadeau, T. and A. Farrel, "Definitions of Textual
>                Conventions for Multiprotocol Label Switching (MPLS)
>                Management", draft-ietf-ccamp-gmpls-tc-mib, work in
>                progress.

  Nit: 'GMPLSTCMIB' is defined on line 2850, but not referenced

Tom Petch has open questions about freeform labels.  The plan is to move ahead with the Last Call and treat Tom's comments as Last Call comments if they need to be resolved.

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

New MIB doctor review posted to WG mailing list.
Seems to warrant a new revision.

> -----Original Message-----
> From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
> Sent: Wednesday, March 15, 2006 06:31
> 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-lsr-mib-11.txt
>
>
> 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."
>
>
>
>
>
>
> 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"   
> 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
>
>
> 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.
>
>
>
> 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?
>
> 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.
>
>
> 6) As previously mentioned could MPLS objects be denoted
> in a separate GROUP (e.g., gmplsLabelMplsLabel and possibly other
> objects).
>
> 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.
>
>
> --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

MIB Doctor review by Joan Cucchiara

-----Original Message-----
From: jcucchiara@mindspring.com [mailto:jcucchiara@mindspring.com]
Sent: Thursday, September 08, 2005 17:49
To: tnadeau@cisco.com; adrian@olddog.co.uk; ccamp@ops.ietf.org
Cc: bwijnen@lucent.com; jcucchiara@mindspring.com
Subject: review of draft-ietf-ccamp-lsr-mib-08.txt




Hello,

I would like to thank Bert for his input, especially
on the MIB compliances and document reference section.

Thank you,
  -Joan



draft-ietf-ccamp-gmpls-lsr-mib-08.txt
=======================================


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

1) Does the following statement refer to the
GMPLS LSR MIB module?

  "The GMPLS Label MIB module may be referenced using a row pointer from
  objects within the LSR MIB module."
                    ^^^^
As previously mentioned, using the entire MIB module name
would be clearer.


Section  4. Outline
---------------------

2)  Need to clarify the phrase "this MIB module" because
there are 2 MIB modules in this document.


"-  Enabling GMPLS on GMPLS capable interfaces using this MIB module."

(which is referring to the GMPLS-LSR-STD-MIB module??)

...

  "-  Optionally setting up labels in the label table in this MIB module
      if the textual convention MplsLabel is not capable of holding the
      required label (for example, if the label requires more than 32
      bits to encode it), or if the operator wishes to disambiguate
      GMPLS label types."

The phrase, "in this MIB module", needs to be clarified since there
are 2 mib modules in this document.  Here, I think you are
referring to the GMPLS-LABEL-STD-MIB, but prior to this you use
a similar phrase and are referring the the GMPLS-LSR-STD-MIB.
Please consistently specify the MIB modules by using their
names.


3) Please move section, 4.1 MIB Modules to section 1.1, Migration
Strategy.  There is much overlap in these 2 sections so please
combine them.


Section 4.1.2  Summary of GMPLS Label MIB Module
-------------------------------------------------

4)      "Generalized Labels can be of variable length and have distinct
      bit-by-bit interpretations according to the use that is made of
      them."

Please change the above to:

      "Generalized Labels can be of variable length and have distinct
      bit-by-bit interpretations depending upon how they are defined
      by the specific service provider."


5) Same section, 4.1.2  Summary of GMPLS Label MIB Module

Please remove this last sentence:

    These tables are described in the subsequent sections.


Section 5. Bidirectional LSPs
-------------------------------


6) "This MIB module..."

Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module

7)  Please specifically call out which term you will be using in
this document.  Beginning with the 3rd paragraph, there is much
terminology, so please add some statement such as:

"In this document, the terms 'forward' and 'reverse' will be used.


Section 6. Example of LSP Setup
-------------------------------

8) First and second sentences:
  "In this section we provide a brief example of using the MIB objects
  described in sections 7 and 8 to set up an LSP. While this example is
  not meant to illustrate every nuance of the MIB, it is intended as an
  aid to understanding some of the key concepts..."

The phrase, "every nuance of the MIB" should probably be
"every nuance of the MIB modules"  since you are referring to both
of the MIB modules (sections 7 and 8).

9) Typo:  gmplsLableTable

10) Typo:  accesible  (in several places)


Section 7.  GMPLS-LSR-STD-MIB
======================


11) smicngpro gives the following:

E: f(GMPLS-LSR-STD-MIB), (315,8) Item "ifGeneralInformationGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (316,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (322,8) Item "mplsInterfaceGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (323,8) Item "mplsInSegmentGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (324,8) Item "mplsOutSegmentGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (325,8) Item "mplsXCGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (326,8) Item "mplsPerfGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (327,8) Item "mplsLsrNotificationGroup" should be IMPORTed
W: f(GMPLS-LSR-STD-MIB), (358,18) For "gmplsOutSegmentTTLDecrement", syntax is identical
E: f(GMPLS-LSR-STD-MIB), (378,8) Item "ifGeneralInformationGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (379,8) Item "ifCounterDiscontinuityGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (385,8) Item "mplsInterfaceGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (386,8) Item "mplsInSegmentGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (387,8) Item "mplsOutSegmentGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (388,8) Item "mplsXCGroup" should be IMPORTed
E: f(GMPLS-LSR-STD-MIB), (389,8) Item "mplsPerfGroup" should be IMPORTed
W: f(GMPLS-LSR-STD-MIB), (404,14) For "gmplsInterfaceSignalingCaps", syntax is identical
W: f(GMPLS-LSR-STD-MIB), (415,18) For "gmplsInterfaceRsvpHelloPeriod", syntax is identical
W: f(GMPLS-LSR-STD-MIB), (431,18) For "gmplsInSegmentExtraParamsPtr", syntax is identical
W: f(GMPLS-LSR-STD-MIB), (447,18) For "gmplsOutSegmentTTLDecrement", syntax is identical
W: f(GMPLS-LSR-STD-MIB), (454,18) For "gmplsOutSegmentExtraParamsPtr", syntax is identical


Please correct the above.

Also, please change the following 2 statements (which appear twice)
to remove the SYNTAX, since this is redundant, unless there is
a reason why you prefer to leave it.

    OBJECT      gmplsInSegmentDirection
    SYNTAX      GmplsSegmentDirection
    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      gmplsOutSegmentDirection
    SYNTAX      GmplsSegmentDirection
    MIN-ACCESS  read-only
    DESCRIPTION
      "Write access is not required. Only forward(1) needs to be
        supported by implementations that only support unidirectional
        LSPs."

Compiles cleanly with smilint.


12) DESCRIPTION
  Please change the first paragraph to (this comment applies to
  the other MIB modules also.)

            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.


13) Change the following:

    GmplsSegmentDirection
      FROM GMPLS-TC-STD-MIB                            -- GMPLSTCMIB
                      -- RFC-Editor please resolve the reference above

TO:

    GmplsSegmentDirection
      FROM GMPLS-TC-STD-MIB                            -- RFCXXXX
                      -- RFC-Editor please resolve the reference above
                      -- and remove this note.

14) Please remove:

  -- Notifications
  -- no notifications are currently defined.
  gmplsLsrNotifications OBJECT IDENTIFIER ::= { gmplsLsrStdMIB 0 }

(You don't need to change any numbering, but no sense defining
a number you don't need).

15) Please remove comments such as (this request is made
    for all MIB modules in all 3 documents):
  -- Top level components of this MIB module.
  -- Tables, Scalars
  -- Conformance
  -- GMPLS Interface Table.

  -- End of gmplsInterfaceTable

  -- In-segment table.

etc.


16)  gmplsInterfaceEntry OBJECT-TYPE

      "A conceptual row in this table is created automatically by an
        LSR for every interface capable of supporting GMPLS and which
        is configured to do so."

Please change first sentence:

      "A conceptual row in this table is created automatically by an
        LSR when the interface is capable of supporting GMPLS and is
        correctly configured to do so."

        ....

Please change the first sentence of the last paragraph:

      "The indexing is the same as that for mplsInterfaceTable."

to:

      "The indexing is the same as the mplsInterfaceTable."

17) object:    gmplsInterfaceSignalingCaps OBJECT-TYPE

    SYNTAX  BITS {
      unknown (0),
      rsvpGmpls (1),
      crldpGmpls (2), -- note the use of CR-LDP is deprecated
      otherGmpls (3)
    }


What is otherGmpls(3)??

Also, this description is confusing.  How can unknown(0) and
rsvpGmpls(1) be set simultaneously?

Additionally, how can no bits be set?  If this is a GMPLS interface,
then doesn't one of these bits HAVE to be set?

18)  gmplsInterfaceRsvpHelloPeriod OBJECT-TYPE
      "Period, in milliseconds, between sending RSVP Hello messages on
        this interface. A value of 0 indicates that no Hello messages
        should be sent on this interface."

This object is only valid if the gmplsInterfaceSignalingCaps
object is set ot rsvpGmpls.  Please update the description
to reflect that.


19)    gmplsInSegmentEntry  OBJECT-TYPE
      "An entry in this table extends the representation of an incoming
        segment represented by an entry in mplsInSegmentTable. An entry
        can be created by a network administrator or an SNMP agent, or a
        GMPLS signaling protocol.

Please use the phrase:  "via SNMP SET commands to create an entry"
in place of "SNMP agent".

20) same entry, gmplsInSegmentEntry

        Note that the storage type for this entry SHOULD be inherited
        from the corresponding entry in the mplsInSegmentTable given by
        the value of the mplsInSegmentStorageType object."

Please change to:

Note that the storage type for this entry is given by the value
of mplsInSegmentStorageType in the corresponding entry of the
mplsInSegmentTable.


21)    gmplsInSegmentDirection OBJECT-TYPE

Please use "corresponding" instead of "associated"


22)    gmplsInSegmentExtraParamsPtr  OBJECT-TYPE
    SYNTAX      RowPointer
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
      "Some Tunnels will run over transports that can usefully support
        technology-specific additional parameters (for example, SONET
        resource usage). Such can be supplied from an external table and
        referenced from here. A value of zeroDotzero in this attribute
        indicates that there is no such additional information."
    DEFVAL      { zeroDotZero }
    ::= { gmplsInSegmentEntry 2 }

What is meant by "external table"?  If this is an enterprise-specific
table, then is it necessary to have this object in the MIB.  In other
words, why is this MIB dictating that a row-pointer be used when
an enterprise-specific MIB may which to simply use indices.

I think this object is unnecessary, but maybe I don't understand
something.

23)  gmplsOutSegmentEntry  OBJECT-TYPE
Same comments as with gmplsInSegmentEntry

24)    gmplsOutSegmentDirection OBJECT-TYPE
Same comment as with gmplsInSegmentDirection

25)    gmplsOutSegmentTTLDecrement OBJECT-TYPE

      "This object indicates the amount by which to decrement the TTL
        of any payload packets forwarded on this segment if per-hop
        decrementing is being done.

Please change above to:

This object indicates the amount to decrement the TTL...



26)    same object's gmplsOutSegmentTTLDecrement OBJECT-TYPE

        A value of zero indicates that no decrement should be made or
        that per-hop decrementing is not in force.

Please change:  in force to enforced.

27)    gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE

Same comment as with gmplsInSegmentExtraParamsPtr


28) Compliance Statements

I believe that gmplsInSegmentExtraParamsPtr and
gmplsOutSegmentExtraParamsPtr do not need to be
supported, so these maybe should be optional.


Section 8.  GMPLS-LABEL-STD-MIB
===================================
smicngPRO gives the following:

E: f(GMPLS-LABEL-STD-MIB), (21,13) Module "MPLS-TC-STD-MIB" has already been specified in IMPORTS clause


E: f(GMPLS-LABEL-STD-MIB), (481,12) Group "gmplsLabelTableGroup" is both a MANDATORY and conditional group for module "GMPLS-LABEL-STD-MIB"


Compiles cleanly with smilint.

Also, disconnect in the numbering of the
gmplsLabelTable:

  |        \-v-1 gmplsLabelInterface, name "InterfaceIndexOrZero", na, current
  |          |-2 gmplsLabelIndex, Unsigned32(0..4294967295), na, current
  |          |-3 gmplsLabelSubindex, Unsigned32(0..4294967295), na, current
  |          |-4 gmplsLabelType, name "GmplsGeneralizedLabelTypes", rc, current

--->  5 is missing


  |          |-6 gmplsLabelMplsLabel, name "MplsLabel", rc, current
  |          |-7 gmplsLabelPortWavelength, Unsigned32, rc, current
  |          |-8 gmplsLabelFreeform, name "GmplsFreeformLabel", rc, current
  |          |-9 gmplsLabelSonetSdhSignalIndex, Integer32(0..4095), rc, current
  |          |-10 gmplsLabelSdhVc, Integer32(0..15), rc, current
  |          |-11 gmplsLabelSdhVcBranch, Integer32(0..15), rc, current
  |          |-12 gmplsLabelSonetSdhBranch, Integer32(0..15), rc, current
  |          |-13 gmplsLabelSonetSdhGroupBranch, Integer32(0..15), rc, current
  |          |-14 gmplsLabelWavebandId, Unsigned32, rc, current
  |          |-15 gmplsLabelWavebandStart, Unsigned32, rc, current
  |          |-16 gmplsLabelWavebandEnd, Unsigned32, rc, current
  |          |-17 gmplsLabelRowStatus, name "RowStatus", rc, current
  |          \-18 gmplsLabelStorageType, name "StorageType", rc, current



29)  DESCRIPTION
  Please change the first paragraph to (this comment applies to
  the other MIB modules also.)

            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.

30) Please remove these statements (don't need to change any numbers).

  -- Notifications
  -- no notifications are currently defined.
  gmplsLabelNotifications  OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 }


31)  gmplsLabelTable OBJECT-TYPE


The last part of the last paragraph is awkward:

        "... Labels in the tables in other MIBs are referred to using
        row pointer into this table. The indexing of this table provides
        for arbitrary indexing and also for concatenation of labels."

Are you saying that other MIBs can use a row pointer to point to
this table?  Why would they do that if they could just use the
indices directly?  Also, I don't follow the comment about
concatenation of labels.  Could you explain this?

32)    gmplsLabelEntry OBJECT-TYPE

The last sentence of the DESCRIPTION, please remove
the word "more" from the phrase "is more persistent."

I still don't understand how the subindex provides a way
to concatenate the labels.  Could you give an example?


33) please switch RowStatus and StorageType (this will
more closely match the other MPLS MIBs).


34)    gmplsLabelInterface OBJECT-TYPE

DESCRIPTION also needs to specify that zero may be
used to indicate that the InterfaceIndex is not known
or that an InterfaceIndex exists but it is not important
wrt this implementation so zero is used.

35)  gmplsLabelIndex OBJECT-TYPE
    SYNTAX        Unsigned32 (0..4294967295)

36a) I was expecting the SYNTAX to be IndexInteger due
to the gmplsLabelIndexNext in the DESCRIPTION.
Please explain why the use of zero is needed.  You
explain the use of zero in the gmplsLabelInterface
and gmplsLabelSubindex indices.


36b)Please change the "may" to "should" in this statement:
        A management application may read the gmplsLabelIndexNext
        object to find a suitable value for this object."


37)    gmplsLabelType OBJECT-TYPE

        of gmplsMplsLabel (1) denotes that a 23 bit MPLS packet label is
        present, but does not describe whether this is signaled using
        MPLS or GMPLS.

Is this 23 bit value correct?  Is this a FrameRelay DLCI label?


38)  gmplsLabelRowStatus OBJECT-TYPE
MUST explain which columns must be properly configured
before the row can be made active (as per RFC2579)


39) Please clarify in the DESCRIPTION of each of
the following groups, if the group is optional
or needs to be supported by such implementations:
    GROUP gmplsLabelPacketGroup
    DESCRIPTION
      "This group extends gmplsLabelTableGroup for implementations that
        support packet labels."

    GROUP gmplsLabelPortWavelengthGroup
    DESCRIPTION
      "This group extends gmplsLabelTableGroup for implementations that
        support port and wavelength labels."

    GROUP gmplsLabelFreeformGroup
    DESCRIPTION
      "This group extends gmplsLabelTableGroup for implementations that
        support freeform labels."

    GROUP gmplsLabelSonetSdhGroup
    DESCRIPTION
      "This group extends gmplsLabelTableGroup for implementations that
        support SONET or SDH labels."

    GROUP gmplsLabelWavebandGroup
    DESCRIPTION
      "This group extends gmplsLabelTableGroup for implementations that
        support Waveband labels."


40)  gmplsLabelModuleROCompliance MODULE-COMPLIANCE

Please change the name to: gmplsLabelModuleReadOnlyCompliance
to be consistent with the other MPLS and GMPLS MIB modules.

41) The ReadOnly compliance for gmplsLabelRowStatus
does NOT have a MIN-ACCESS of read-only.  Is this
intentional?

42) Also, (related to the above)
    OBJECT      gmplsLabelRowStatus
    SYNTAX      RowStatus {
      active(1),
      notInService(2)
    }


    WRITE-SYNTAX RowStatus {
      active(1),
      notInService(2),
      createAndGo(4),
      destroy(6)
    }
    DESCRIPTION
      "Support for notInService, createAndWait and notReady is not
        required."

The DESCRIPTION clause conflicts with the WRITE-SYNTAX.
Please clarify the intentions for this ReadOnly compliance
object.



Section 12.2 Informational References
---------------------------------------

43a) The title of this section should be
Informative.


43b) Please move the following from
Informative to Normative.

  [RFC3471]        Berger, L. (Editor), "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling Functional
                    Description", RFC 3471, January 2003.

  [RFC3472]        Ashwood-Smith, P., Berger, L. (Editors),
                    "Generalized MPLS Signaling - CR-LDP Extensions",
                    RFC 3472, January 2003.

  [RFC3473]        Berger, L. (Editor), "Generalized MPLS Signaling -
                    RSVP-TE Extensions", RFC 3473 January 2003.

  [GMPLSSonetSDH]  Mannie, E., Papadimitriou, D. (Editors),
                    "Generalized Multi-Protocol Label Switching
                    Extensions for SONET and SDH Control",
                    draft-ietf-ccamp-gmpls-sonet-sdh, work in progress.

43c)  The above reference now appears to be RFC 3946.

Please change the above (NOTE also the changes in the
reference itself, more on the Reference format next):

  [GMPLS-SONET]  Mannie, E. and D. Papadimitriou, "Generalized Multi-
                  Protocol Label Switching (GMPLS) Extensions for
                  Synchronous Optical Network (SONET) and Synchronous
                  Digital Hierarchy (SDH) Control", RFC 3946, October
                  2004.



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


Here are some to change. One suggestion is to copy a reference
(if possible) from an existing RFC.  Sometimes a date is missing
and sometimes the authors/editors names do not appear as
expected.  Also, titles need to appear exactly as on
the RFC.  Please check the other GMPLS docs also.
(NOTE: see also draft-rfc-editor-rfc2223bis-08.txt)


Please change:
  [RFC2026]        S. Bradner, "The Internet Standards Process --
                    Revision 3", RFC 2026, October 1996.

to:

  [RFC2026]        Bradner, S., "The Internet Standards Process --
                    Revision 3," BCP 9, RFC 2026, October 1996.

Please change:

  [RFC2863]        McCloghrie, K. and F. Kastenholtz, "The Interfaces
                    Group MIB", RFC 2863, June 2000.

to (author name misspelled):

  [RFC2863]  McCloghrie, K. and F. Kastenholz,  "The Interfaces Group
              MIB", RFC 2863, June 2000.

Please change:

  [RFC3032]        Rosen, E. et al, "MPLS Label Stack Encoding",
                    RFC 3032, January 2001.

to:

  [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.


Please change:

  [RFC3212]        Jamoussi, B., Aboul-Magd, O., Andersson, L.,
                    Ashwood-Smith, P., Hellstrand, F., Sundell, K.,
                    Callon, R., Dantu, R., Wu, L., Doolan, P., Worster,
                    T., Feldman, N., Fredette, A., Girish, M., Gray,
                    E., Halpern, J., Heinanen, J., Kilty, T., Malis,
                    A., and P. Vaananen, "Constraint-Based LSP Setup
                    using LDP", RFC 3212, December 2001."

to:

  [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
            Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A.,
            Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
            Malis,  "Constraint-Based LSP Setup using LDP", RFC 3212,
            January 2002.


Please change:

  [RFC3411]        Harrington, D., Presuhn, R., and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    RFC 3411, December 2002.

to:
  [RFC3411]            Harrington, D., Presuhn, R., and B. Wijnen, "An
                        Architecture for Describing Simple Network
                        Management Protocol (SNMP) Management
                        Frameworks", STD 62, RFC 3411, December 2002.

Please change:

  [RFC3413]        Levi, D., Meyer, P., Stewart, B., "SNMP
                    Applications", RFC 3413, December 2002.
to:
  [RFC3413]  Levi, D., Meyers, P. and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62, RFC
              3413, December 2002.


Please change:
  [RFC3443]        Agarwal, P. and Akyol, B., "Time To Live (TTL)
                    Processing in Multi-Protocol Label Switching
                    (MPLS) Networks", RFC 3443, January 2003.

to:
  [RFC3443]        Agarwal, P. and B. Akyol, "Time To Live (TTL)
                    Processing in Multi-Protocol Label Switching
                    (MPLS) Networks", RFC 3443, January 2003.


Please change:
  [RFC3471]        Berger, L. (Editor), "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling Functional
                    Description", RFC 3471, January 2003.


to:
  [RFC3471]        Berger, L., Editor, "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling Functional
                    Description", RFC 3471, January 2003.


Please change:

  [RFC3472]        Ashwood-Smith, P., Berger, L. (Editors),
                    "Generalized MPLS Signaling - CR-LDP Extensions",
                    RFC 3472, January 2003.

to:
  [RFC3472]        Ashwood-Smith, P. and L. Berger, Editors,
                    "Generalized Multi-Protocol Label
                    Switching (GMPLS) Signaling Constraint-based
                    Routed Label Distribution Protocol (CR-LDP)
                    Extensions", RFC 3472, January 2003.

Please change:

  [RFC3473]        Berger, L. (Editor), "Generalized MPLS Signaling -
                    RSVP-TE Extensions", RFC 3473 January 2003.

to:
  [RFC3473]        Berger, L., Editor, "Generalized Multi-Protocol
                    Label Switching (GMPLS) Signaling - Resource
                    ReserVation Protocol-Traffic Engineering (RSVP-TE)
                    Extensions", RFC 3473, January 2003.



--- the end ----

General comments from MIB Doctor Joan.
These comments apply to all 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.