RFC Errata
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.