RFC Errata
Found 3 records.
Status: Verified (2)
RFC 4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006
Note: This RFC has been obsoleted by RFC 4631
Source of RFC: ccamp (rtg)Errata ID: 123
Status: Verified
Type: Technical
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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)
RFC 4327, "Link Management Protocol (LMP) Management Information Base (MIB)", January 2006
Note: This RFC has been obsoleted by RFC 4631
Source of RFC: ccamp (rtg)
Errata ID: 1938
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
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.