errata logo graphic

Found 3 records.

Status: Verified (2)

RFC4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006

Note: This RFC has been obsoleted by RFC4631

Source of RFC: ccamp (rtg)

Errata ID: 123

Status: Verified
Type: Technical

Reported By: Adrian Farrel
Date Reported: 2006-01-18
Report Text:

RFC 4327 makes use of the TruthValue textual convention defined in RFC
2579.

Several places in the text identify the enumerations of the textual
convention ("true" and "false") using their names and their numeric values
(1 and 2 respectively).

However, several references to the enumerations of the textual convention
use the incorrect numeric values.

All references to the enumerations of this textual convention in this RFC
should take the names ("true" and "false") as the definitive settings, and
should disregard the numeric values when stated incorrectly.



Errata ID: 705

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Verifier Name: Adrian Farrel
Date Verified: 2009-10-30

 

(1)  [plaintext flaw]

In the final paragraph of Section 7, on page 8, RFC 4327 says:

   In parallel with the entry created in the lmpTeLinkTable, an entry
   may be created in the teLinkTable of TE Link MIB module
   [RFC4220].

It should better say:

   In parallel with the entry created in the lmpTeLinkTable, an entry
|  may be created in the teLinkTable of the TE Link MIB module
   [RFC4220].
                                       ^^^^^

(2)  [plaintext flaw]

In the second paragraph of Section 8, at the bottom of page 8,
RFC 4327 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].
                        ^^^^^


(3)  LmpInterval TEXTUAL-CONVENTION  (page 12)

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


(4)  LmpRetransmitInterval TEXTUAL-CONVENTION  (page 12)

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


(5)  lmpNbrRetransmitInterval OBJECT-TYPE  (page 14)

The sentence in the DESCRIPTION clause,

   "[...]  This object ... is used to implement congestion-handling
   mechanism as defined in Section 10 of the Link Management Protocol
   specification, which is based on RFC 2914."

should perhaps better say:
                                               vvvvv
|  "[...]  This object ... is used to implement the congestion-handling
   mechanism as defined in Section 10 of the Link Management Protocol
   specification, which is based on RFC 2914."


(6)  lmpNbrRetryLimit OBJECT-TYPE  (page 14)

The correction from item (5) above should be applied here as well.


(7)  lmpCcRemoteAddressType OBJECT-TYPE  (page 20)

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

   DESCRIPTION
       "[...]
        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 }


(11)  lmpControlChannelPerfEntry OBJECT-TYPE  (page 24)

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

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 }


(14)  lmpTeLinkPerfEntry OBJECT-TYPE  (page 42)

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 45/46)

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

is inappropriate.  In accordance with the text supplied for the
other objects in the LMP TE Link Performance 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 47)

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

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 }


(20)  lmpDataLinkPerfEntry OBJECT-TYPE  (page 55)

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


(21)  lmpNotificationMaxRate OBJECT-TYPE  (page 57/58)

The DESCRIPTION text near the top of page 58 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.


(23)  lmpControlChannelGroup OBJECT-GROUP  (page 72)

At the bottom of page 72, 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."

It should say:

[see above]

Notes:

Verifier's analysis:

1. Yes. Editorial nit.
2. Yes. Editorial nit.
3. Yes. Editorial nit.
4. Yes. Editorial nit.
5. Yes. Editorial nit.
6. Yes. Editorial nit.
7. Yes. Editorial nit.
8. Yes. Editorial nit.
11. Yes. Editorial change of substance.
12. Yes. Editorial change of substance.
14. Yes. Editorial change of substance.
15. Yes. Editorial change of substance.
16. Yes. Editorial change of substance.
17. Yes. Editorial change of substance.
18. Yes. Editorial change of substance.
20. Yes. Editorial change of substance.
21. Yes. Editorial nit.
23. Yes. Editorial nit.

Rejected items have been moved to Errata ID 1938.


Status: Rejected (1)

RFC4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006

Note: This RFC has been obsoleted by RFC4631

Source of RFC: ccamp (rtg)

Errata ID: 1938

Status: Rejected
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2006-02-24
Rejected by: Adrian Farrel
Date Rejected: 2009-10-30

 

(9)  lmpCcHelloInterval OBJECT-TYPE  (page 21)

An established 'default' specifies the value of a (newly created)
tabular object to be used when this object is not SET explicitely.
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 21) ,
(9'')  lmpCcHelloIntervalMax OBJECT-TYPE  (page 21/22) ,
(10)   lmpCcHelloDeadInterval OBJECT-TYPE  (page 22) ,
(10')  lmpCcHelloDeadIntervalMin OBJECT-TYPE  (page 22) , and
(10'') lmpCcHelloDeadIntervalMax OBJECT-TYPE  (page 22)

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


(13)  lmpTeLinkEntry OBJECT-TYPE  (page 36)

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


(19)  lmpDataLinkEntry OBJECT-TYPE  (page 51)

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 value is
        controlled from the ifEntry.  [...]


(22)  lmpNodeGroup OBJECT-GROUP  (page 71/72)

Near the top of 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! ]


(24)  lmpDataLinkGroup OBJECT-GROUP  (page 76)

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 }

It should say:

[see above]

Notes:

Verifier's analysis:

9. No. Editorial change of no substance.
9' No. Editorial change of no substance.
9" No. Editorial change of no substance.
10. No. Editorial change of no substance.
10' No. Editorial change of no substance.
10" No. Editorial change of no substance.
13. No. The value is controlled, not the status.
19. No. The value is controlled, not the status.
22. No. The English is correct.
24. No. The English is correct.

Verified items are in Errata ID 705.


Report New Errata