RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Rejected (2)

RFC 4631, "Link Management Protocol (LMP) Management Information Base (MIB)", September 2006

Source of RFC: ccamp (rtg)

Errata ID: 825

Status: Rejected
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel

 

(1) [[posted separately.]]

(2)  [plaintext flaw]

In the second paragraph of Section 8, near the bottom of page 9,
RFC 4631 says:

                        [...].  The interrelation of entries in the
   ifTable is defined by Interfaces Stack Group defined in [RFC2863].

It should say:

                        [...].  The interrelation of entries in the
|  ifTable is defined by the Interfaces Stack Group defined in
   [RFC2863].
                        ^^^^^


(2') [punctuation] -- legacy, but not reported for RFC 4327

Conformant to the punctuation newly introduced in the REFERENCE
clauses, parts of the DESCRIPTION subclauses of the MODULE-IDENTITY
macro invocation should also be amended with a trailing full-stop:

On top of page 13, change:

        This revision published as RFC 4631"
   REVISION
       "200601110000Z"  -- 11 January 2006
   DESCRIPTION
       "Initial version published as RFC 4327"
   ::= { transmission 227 }

to say:

|       This revision published as RFC 4631."
   REVISION
       "200601110000Z"  -- 11 January 2006
   DESCRIPTION
|      "Initial version published as RFC 4327."
   ::= { transmission 227 }


(3)  LmpInterval TEXTUAL-CONVENTION  (page 13)

The clause,

   DESCRIPTION
       "The interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The delay interval in milliseconds."

or even:

   DESCRIPTION
|      "The interval period for a periodically performed LMP operation,
|       in milliseconds."

[Rationale: It's not the interval that's getting delayed ...]


(4)  LmpRetransmitInterval TEXTUAL-CONVENTION  (page 13)

The clause,

   DESCRIPTION
       "The retransmission interval delay in milliseconds."

perhaps should better say:

   DESCRIPTION
|      "The retransmission delay interval in milliseconds."

or even better:

   DESCRIPTION
|      "The (initial) retransmission interval in milliseconds."

[Rationale: It's not the interval that's getting delayed ...]


(old #5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 15)  -- resolved

(new #5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 15)
          -- legacy, but originally not reported

There's an extraneous blank line in the middle of the REFERENCE clause
that should be deleted (cf. lmpNbrRetryLimit OBJECT-TYPE, below).


(old #6)  lmpNbrRetryLimit OBJECT-TYPE  (page 15)  -- resolved

(new #6)  lmpCcUnderlyingIfIndex and lmpCcIsIf OBJECT-TYPEs  (page 20)
          -- newly introduced

The punctuation within the DESCRIPTION clauses for these objects
has been changed using one semicolon each.
IMHO, this is unfortunate because it might be misinterpreted as
excluding the subsequent half-sentences from the initial "If"
condition in these sentences that in fact are also preconditions
for the statements now after the semicolons.


(7)  lmpCcRemoteAddressType OBJECT-TYPE  (page 21)

   DESCRIPTION
       "This value represents the remote control channel IP address
        type.  In point-to-point configuration, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }

should better say:

   DESCRIPTION
       "This value represents the remote control channel IP address
|       type.  In point-to-point configurations, this value can be set
        to unknown(0)."
   ::= { lmpControlChannelEntry 6 }
                                              ^

[ The possible alternative, "In a point-to-point configuration, ..."
  is not proposed here, to maintain a style similar to the minimal
  change for the next object -- see (8) below.]


(8)  lmpCcRemoteIpAddr OBJECT-TYPE  (page 21) -- partially resolved

   DESCRIPTION
       "[...]
        The Control channel must be numbered on non-point-to-point
        configuration.  For point-to-point configuration, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }

should better say:

   DESCRIPTION
       "[...]
        The control channel must be numbered on non-point-to-point
|       configurations.  For point-to-point configurations, the
        remote control channel address can be of type unknown
        in which case this object must be a zero-length string.  The
        lmpCcRemoteId object then identifies the unnumbered
        address."
   ::= { lmpControlChannelEntry 7 }


(9)  lmpCcHelloInterval OBJECT-TYPE  (page 22)

An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
The default is never 'set', it is defined in the specification.
Hence,

   DESCRIPTION
       "This object specifies the value of the HelloInterval
        parameter.  The default value for this object should be
        set to lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }

should better say:

   DESCRIPTION
       "This object specifies the value of the HelloInterval
|       parameter.  The default value to be used for this object
|       is lmpCcHelloIntervalDefault."
   ::= { lmpControlChannelEntry 10 }


(9')   lmpCcHelloIntervalMin OBJECT-TYPE  (page 22) ,
(9'')  lmpCcHelloIntervalMax OBJECT-TYPE  (page 22) ,
(10)   lmpCcHelloDeadInterval OBJECT-TYPE  (page 23) ,
(10')  lmpCcHelloDeadIntervalMin OBJECT-TYPE  (page 23) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE  (page 23)

The change from item (9) above should be applied there similarly:

Replace the phrase,

           "[...].  The default value for this object should be
        set to lmp<*>Default."

by:

|          "[...].  The default value to be used for this object
|       is lmp<*>Default."

using, at all instances, the appropriate value for the placeholder <*>.


(11)  lmpControlChannelPerfEntry OBJECT-TYPE  (page 25)

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

The latter is not true.
In this MIB module, the discontinuity is monitored per table *entry*
(conceptual row), not for the table as a whole -- see the DESCRIPTIONs
for lmp<*>DiscontinuityTime later in the RFC.

Therefore, the above clause should say:

   DESCRIPTION
       "An entry in this table is created by a LMP-enabled device for
        every control channel.  lmpCcCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(12)  lmpCcChannelStatusAckSent OBJECT-TYPE  (page 35)

The clause,

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }

refers to the wrong message type; it should say:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent on this control channel."
   ::= { lmpControlChannelPerfEntry 47 }


(13)  lmpTeLinkEntry OBJECT-TYPE  (page 37)

The DESCRIPTION clause contains the sentence:

                                                      [...].  The
        administrative status value is controlled from the ifEntry.
        [...]

This sentence should say:

                                                      [...].  The
|       administrative status is controlled from the ifEntry.
        [...]


(13') lmpLinkVerifyTransportMechanism OBJECT-TYPE  (page 41)  -- new

Missing punctution between the two parts of the REFERENCE clause:

   REFERENCE
       "Link Management Protocol, RFC 4204
        Synchronous Optical Network (SONET)/Synchronous Digital
        Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
        Test Messages, RFC 4207."

should say:

   REFERENCE
       "Link Management Protocol, RFC 4204.
        Synchronous Optical Network (SONET)/Synchronous Digital
        Hierarchy (SDH) Encoding for Link Management Protocol (LMP)
        Test Messages, RFC 4207."

[... or use a semicolon after "RFC 4204".]
[Note: This item not reported for RFC 4327 -- there was a page
 break effectively hiding the issue.]


(14)  lmpTeLinkPerfEntry OBJECT-TYPE  (page 43)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
        in this table."

by:

   DESCRIPTION
       "An entry in this table is created by an LMP-enabled device for
        every TE link.  lmpTeCounterDiscontinuityTime is used
        to indicate potential discontinuity for all counter objects
|       in this entry (conceptual row)."


(15)  lmpTeEndVerifyRetransmit OBJECT-TYPE  (page 46)
      -- rationale given now extended

   DESCRIPTION
       "This object counts the number of EndVerify messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 12 }

is inappropriate -- it does not match the indexing structure of the
LMP TE Link Performance Table.  In accordance with the text supplied
for the other objects in this Table, it should say:

   DESCRIPTION
       "This object counts the number of EndVerify messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 12 }


(16)  lmpTeTestStatusFailureRetransmit OBJECT-TYPE  (page 48)

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted on this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

should say:

   DESCRIPTION
       "This object counts the number of TestStatusFailure messages
        that have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 20 }

[ According to Section 12.5.8. of the LMP specification [RFC 4204],
  LMP TestStatusFailure messages are transmitted over the control
  channel; hence, "retransmitted *on* this TE Link" is wrong! ]


(17)  lmpTeLinkSummaryRetransmit OBJECT-TYPE  (page 49)

The correction from item (15) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
        have been retransmitted over this control channel."
   ::= { lmpTeLinkPerfEntry 25 }

by:

   DESCRIPTION
       "This object counts the number of LinkSummary messages that
|       have been retransmitted for this TE link."
   ::= { lmpTeLinkPerfEntry 25 }


(18)  lmpTeChannelStatusAckSent OBJECT-TYPE  (page 50)

The correction from item (12) above is to be applied here as well:

Replace:

   DESCRIPTION
       "This object counts the number of ChannelStatus messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }

by:

   DESCRIPTION
|      "This object counts the number of ChannelStatusAck messages
        that have been sent for this TE link."
   ::= { lmpTeLinkPerfEntry 34 }


(19)  lmpDataLinkEntry OBJECT-TYPE  (page 52)

The correction from item (13) above is to be applied here as well:

The sentence in the DESCRIPTION clause,

                   [...].  The administrative status value is
        controlled from the ifEntry.  [...]

should say:

|                  [...].  The administrative status is controlled
        from the ifEntry.  [...]


(20)  lmpDataLinkPerfEntry OBJECT-TYPE  (page 56)

The correction from item (11) above is to be applied here as well:

Replace:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
        discontinuity for all counter objects in this table."

by:

   DESCRIPTION
       "An entry in this table contains information about
        the LMP performance counters for the data-bearing links.
        lmpDataLinkDiscontinuityTime is used to indicate potential
|       discontinuity for all counter objects in this entry."


(21a) lmpNotificationMaxRate OBJECT-TYPE  (page 58)
      -- item was numbered (21) previously; recent punctuation
         updates now incorporated in text below

The DESCRIPTION text (near the end of its 2nd paragraph, ff.) says:

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
        of 1 minute, with no more than 10% of the links failed at any
        given time, would have 1 notification per second sent from
        each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
        certain type of notifications.

It should say, correcting two flaws (line breaks adjusted):

                        [...].  For instance, a network of 100 nodes
        with 5 links of 128 wavelengths each and a link verification
|       interval of 1 minute, with no more than 10% of the links failed
        at any given time, would have 1 notification per second sent
        from each node, or 100 notifications per second for the whole
        network.  The rest of the notifications are negligible
        compared to this number.

        To alleviate the congestion problem, the
        lmpNotificationMaxRate object can be used to implement a
        throttling mechanism.  It is also possible to enable/disable
|       certain types of notifications.


(21b) lmpUnprotected NOTIFICATION-TYPE  (page 61)  -- newly introduced

In the DESCRIPTION clause,

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
        channels between the pair of nodes and all the TE links
|       between the pair of nodes, will go to degraded state.  [...]
                                 ^

the newly added comma makes no sense, it separates the noun from the
verb after 'and'; this sentence should say:

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
        channels between the pair of nodes and all the TE links
|       between the pair of nodes will go to degraded state.  [...]

Perhaps, a comma migth instead be inserted before the 'and':

                             [...].  If the remaining operational
        control channel fails, then there will be no more control
|       channels between the pair of nodes, and all the TE links
|       between the pair of nodes will go to degraded state.  [...]


(21c) lmpModuleReadOnlyCompliance MODULE-COMPLIANCE, restriction
      clause for (lmpDataLinkTable) OBJECT lmpDataLinkIPAddr  (page 71)

      DESCRIPTION
          "The size of the data-bearing link IP address depends on
           the type of data-bearing link.  Data-bearing link IP
           address size is zero if the link is unnumbered, four if
           the link IP address is IPv4, and sixteen if the link IP
           address is IPv6."

should better say:

      DESCRIPTION
          "The size of the data-bearing link IP address depends on
|          the type of data-bearing link.  The data-bearing link IP
           address size is zero if the link is unnumbered, four if
           the link IP address is IPv4, and sixteen if the link IP
           address is IPv6."


(22)  lmpNodeGroup OBJECT-GROUP  (page 72)

The RFC says:

   DESCRIPTION
          "Collection of objects that represent LMP node
           configuration."
   ::= { lmpGroups 1 }

It should say:

   DESCRIPTION
|         "Collection of objects that represents the LMP node
           configuration."
   ::= { lmpGroups 1 }

[ In fact, it is *the collection* (singular) that represents
  the node configuration! ]


(23)  lmpControlChannelGroup OBJECT-GROUP  (page 72/73)

On mid-pge 73, the RFC says:

   DESCRIPTION
          "Objects that can be used to configure LMP interface."

It should say:

   DESCRIPTION
|         "Objects that can be used to configure LMP interfaces."


(24)  lmpDataLinkGroup OBJECT-GROUP  (page 77)

Similar to item (22) above, the clause,

   DESCRIPTION
          "Collection of objects that represent data-bearing link
           configuration."
   ::= { lmpGroups 9 }

should better say:

   DESCRIPTION
          "Collection of objects that represents data-bearing link
           configurations."
   ::= { lmpGroups 9 }

Notes:

Some of the errata listed above correspond to errata also reported for RFC 4327 (referred to as "old").

from pending

--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.

In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.

Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.

Errata ID: 39

Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-11-06
Rejected by: Adrian Farrel
Date Rejected: 2007-02-24

Section 7 says:

      In lmpDataLinkTable:
   {

It should say:

   In lmpDataLinkTable:
   {

Notes:

spurious indentation

from pending

--VERIFIER COMMENT--
While many of these comments would undoubtedly have led to a more polished
final RFC it is fortunate that none of them makes the document in any way
harder to read or less technically meaningful. I am sure that if and when
the RFC progresses from Proposed Standard to Draft Standard we can look back
at this list to ensure that your comments are addressed.

In future, however, I would urge you to make comments on the content and
format of CCAMP documents as they progress through the working group or
during IETF last call. Comments made later than that are very unlikely to be
considered by the authors for inclusion, but comments made earlier in the
process are very likely to be included.

Obviously, if issues of technical clarity or understanding do come up later
than this, we can address them through Errata while a new revision of the
RFC is prepared. On the other hand, Errata are probably not well used for
recording small format errors in the text as these are not strictly errors
of content or substance.

Report New Errata



Search RFCs
Advanced Search
×