RFC Errata
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)See Also: RFC 4327 w/ inline errata
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.