Re: review of draft-ietf-ccamp-lsr-mib-08.txt

["Adrian Farrel" <[e-mail]>]

Hi again Joan,

This is the response to your excellent review of the GMPLS LSR MIB module.

As before, I have indicated Ack or Nack for each point you raised.  Where
there is a Nack I have indicated either our reasoning or a proposed
alternate solution.

Feel free to snip in any response you send.

Once we have closure on a few remaining issues we will respin applying
David's
comments on the TE MIB here as well.

Cheers,
Adrian

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

Ack

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

Ack.

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

Ack

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

Nack.
Nothing to do with the service provider.
Will change to:

      "Generalized Labels can be of variable length and have distinct
      bit-by-bit interpretations depending upon how they are defined
      for the specific technology in which they are used. For example,
      labels used for MPLS packet switching are different in length
      and content from labels used in TDM timeslot switching."

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

Ack.

>6) "This MIB module..."
>
>Please clarify which MIB module, i.e. The GMPLS-LSR-STD-MIB module

Ack

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

Ack

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

Ack

>9) Typo:  gmplsLableTable

Ack

>10) Typo:   accesible  (in several places)

Ack

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

Ack. (I wish smilint caught the other errors.)

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

Ack

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

Ack

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

Ack

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

Ack

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

Nack
Agree original is not perfect, but replacement says "the interface"
without
specifying which interface.

Will change to:

       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS."

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

Nack.

Will change to:

       "The indexes are the same as for 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)??

Nack

I'm embarrassed to say that there are other "GMPLS" signaling protocol
variants that have been developed outside the IETF. This was added in
response to a WG request.

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

Ack
Will add:

    ...but if unknown(0) is set, no other bit may be set.

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

Ack

As it says...

        Setting no bits implies
        that GMPLS signaling cannot be performed on this interface and
        all LSPs must be manually provisioned or that this table entry
        is only present to supplement an entry in the mplsInterfaceTable
        by providing the information carried in other objects in this
        row.

This means that we should change gmplsInterfaceEntry to read:

       "A conceptual row in this table is created automatically by an
        LSR for each interface that is both capable of supporting
        GMPLS and that is configured to support GMPLS. Note that
        support of GMPLS is not limited to control plane signaling,
        but may include data-plane only function configured through
        SNMP SET commands performed on this MIB module.

        A conceptual row in this table may also be created via SNMP
        SET commands or automatically by the LSR to supplement a
        conceptual row in the mplsInterfaceTable where the interface
        is not capable of GMPLS but where the other objects carried
        in this row provide useful additional information for an
        MPLS interface."

>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 to rsvpGmpls.  Please update the description
>to reflect that.

Nack
It is also valid for MPLS-TE (it is missing from the MPLS-TE MIB).

We can add:
       This object is not valid if gmplsInterfaceSignalingCaps is
       set to crldpGmpls (2)

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

Ack

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

Ack

>21)    gmplsInSegmentDirection OBJECT-TYPE
>
>Please use "corresponding" instead of "associated"

Ack

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

Nack

rowPointers are typically used when there may be a many-to-one mapping.
This is appropriate for traffic parameters because there may be a few
service
categories defined in a traffic parameters table, and multiple LSPs may
use
those parameters.

Compare with mplsInSegmentTrafficParamPtr in RFC3813.

Now, in this case no such traffic parameters table has been supplied. To
some extent
we are guilty of future-proofing. We are aware that such tables will need
to be
added for TDM (quite soon), for lambda (possibly), and for Ethernet
(almost certainly).

Although it would be possible to leave this out, we feel that the
necessary single-object
extension that would need to be created later would be messy.

>23)   gmplsOutSegmentEntry  OBJECT-TYPE
>Same comments as with gmplsInSegmentEntry

Nack
Same answer

>24)    gmplsOutSegmentDirection OBJECT-TYPE
>Same comment as with gmplsInSegmentDirection

Ack

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

Nack
If we want to be picky, even Webster doesn't recognise "decrement" as a
verb.
But this is a particularly useful verbization that is is common usage.

But I also believe in the use of prepositions. So no change.

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

Nack
Will change to "in use"

>27)    gmplsOutSegmentExtraParamsPtr  OBJECT-TYPE
>
>Same comment as with gmplsInSegmentExtraParamsPtr

Nack
Same answer

>28) Compliance Statements
>
>I believe that gmplsInSegmentExtraParamsPtr and
>gmplsOutSegmentExtraParamsPtr do not need to be
>supported, so these maybe should be optional.

Ack

>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

Ack

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

Ack

>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

Ack

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

Ack

>30) Please remove these statements (don't need to change any numbers).
>
>   -- Notifications
>   -- no notifications are currently defined.
>   gmplsLabelNotifications  OBJECT IDENTIFIER ::= { gmplsLabelStdMIB 0 }

Ack

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

Nack
Yes we are saying that other MIB modules can use a row pointer to
point to this table.
Yes they could use indices. This was the subject of a very lengthy
discussion between the co-authors, etc., but in the end we
observed that mplsInSegmentLabelPtr and mplsOutSegmentLabelPtr
(RFC3813) are rowPointers so we had better support being pointed to.

We could soften the language here by replacing "are" with "may".

Note, we should change this to say "MIB modules"

For an example of label concatenation see RFC3945 section 7.1. In essence,
a GMPLS label may be composite in order to identify a set of resources in
the data plane. Practial examples are timeslots and wavelength sets (which
are not contiguous like wavebands).

The indexing mechanism allows multiple entries in this table to be seen
as a sequence of labels that should be concatenated. Ordering is
potentially
very sensitive for concatenation.

I don't believe we need to add text or references for concatenated labels
since they are part of the architecture.

>32)    gmplsLabelEntry OBJECT-TYPE
>
>The last sentence of the DESCRIPTION, please remove
>the word "more" from the phrase "is more persistent."

Nack.
The Textual Convention gives us degrees. That is, 'readOnly' is more
durable than 'permanent' which is more durable than 'nonNolatile' which
is more durable than 'volatile'.
We need to convey that there is a ranked inheritance.
"Persistence" is acceptable in a comparative.

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

Nack
If you are asking for an example in the I-D, I don't think it is
necessary.

For your information, the composite label {{A}, {B}, {C}} might be
constructed
as...

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 1
gmplsLabelFreeform  = A

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 2
gmplsLabelFreeform  = B

gmplsLabelInterface = 1
gmplsLabelIndex     = 1
gmplsLabelSubindex  = 3
gmplsLabelFreeform  = C

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

Ack

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

Nack
The use of zero is very precisely specified at the moment.
The reasons for setting zero that you cite are:
- the InterfaceIndex is not known
  You cannot have a per-interface label space without knowing the
  interface to which it applies.
- InterfaceIndex exists but it is not important wrt this implementation
  That is exactly the case of the global label space, and is already
  stated.

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

Nack

This is explained by the paragraph:

        Note that implementations that are representing 32 bit labels
        within this table MAY choose to align this index with the value
        of the label, but should be aware of the implications of
        sparsely populated tables.

We believe it would be inappropriate to use IndexInteger to have greater
meaning than just an index.

But anyway, IndexInteger is Unsigned32 (1..4294967295) and the quoted
paragraph
must allow zero as well.

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

Nack
Why "should" it do this? This is a convenience offered to it. It may use
any
mechanism it chooses including the one suggested in the quoted paragraph
above.

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

Ack
This is terrible text!
Yes. 23 bits is FrameRelay.
This text should be much more expansive allowing a 20 bit MPLS label, a 10
or
23 bit FR label, or a 28 bit ATM label. It should also refer to the
gmplsLabelMplsLabel object.

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

Ack

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

Ack

>40)   gmplsLabelModuleROCompliance MODULE-COMPLIANCE
>
>Please change the name to: gmplsLabelModuleReadOnlyCompliance
>to be consistent with the other MPLS and GMPLS MIB modules.

Nack
I thought we tried to keep names down to 32 characters. I recall this
conversation before. Not mandatory, but desirable.

A choice between two desires?

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

???
Not sure about this.
I thought the present of a WRITE-SYNTAX made some difference.

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

Ack
There is an error here.

>Section 12.2 Informational References
>---------------------------------------
>
>43a) The title of this section should be
>Informative.

Ack/Nack

I am aware of the RFC Editor's preferences.
Unfortunately these references are only informative if you read an
understand them (and
even then not always :-), but they are informational even if you don't
read or
understand them.

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

Ack.

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

Ack.
My how time flies.

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

Ack

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

Ack