RFC Errata
RFC 4204, "Link Management Protocol (LMP)", October 2005
Note: This RFC has been updated by RFC 6898
Source of RFC: ccamp (rtg)
Errata ID: 823
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-12-20
Held for Document Update by: Adrian Farrel
(1) Section 10 specifies the required behaviour of *aperiodic* transmission retries with exponential backoff. (1a) Nevertheless, at various places the text talks about "periodically" transmitting certain messages. It should better say "repeated[ly]". Examples for this issue are: - Section 11.1.1, page 28 : introduction, and the paragraphs labelled "ConfSend:" and "Active:" ; - Section 11.1.2, page 30, text for event '12a)' ; - Section 11.2.1, page 32 : introduction, and the paragraphs labelled "Init:" and "Up:" ; - Section 11.3.1, page 35 : paragraph labelled "Test:" ; - Section 12.3.1, page 42, last paragraph; - Section 12.4, page 43, last paragraph; - Section 12.5.1, page 44, last paragraph; - Section 12.5.4, first line on page 46; - Section 12.5.6, final paragraph on page 46 (twice); - Section 12.6.1, second paragraph on page 48. (1b) At the bottom of page 26, Section 10.1 defines the following parameter: Rapid retry limit Rl: Rl is the maximum number of times a message will be transmitted without being acknowledged. The naming of this variable is very unfortunate because in similar contexts in protocol design, the "retry limit" customarily defines the (maximum) number of *re*-tries -- with 0 meaning no retries at all, 1 meaning a single retry, etc. The definition given means that the maximum number of retries will be <Rl> - 1 , thereby restricting the allowed range for <Rl> to 1 or above, excluding the value 0, without mentioning this fact. Because Section 10.2 codifies the abovementioned definition and this certainly should not be changed after the fact of publication as an RFC, it might be advisable to post a warning note pointing to the specific semantics of 'retry limit' with LMP, the admitted value range, and in particular the use '1' for <Rl> to inhibit retries. (2) Section 12.2, on page 41, codifies an (unfortunately very popular) design flaw: the 'Length' field in LMP objects is specified as comprising the cumulative size of the object contents *and* the object prefix (4 bytes). This unnecessarily creates illegal values (0..3) for 'Length' which must be checked for in all implementations. It would have been very muck preferrable to have 'Length' just giving the size of the object contents (in bytes), whereby Length=0 would be the very mnemonic (and most efficiently testable) condition for empty object content [Note: In the case of LMP objects the 16 bit width of length does not constitute an artificial limitation to the size of the object contents, because the whole message must be shorter than 2**16 bytes. This *is* a problem, e.g., for RADIUS with its single-octet 'Length' !] (3) In Section 13.2, on page 51, the explanatory text after the diagram for 'C-Type = 1' says: Node_Id: This identities the node that originated the LMP packet. ^ where it should say: Node_Id: This identifies the node that originated the LMP packet. ^ Similarly, following the diagram for 'C-Type = 2', the same section says at the top of page 52: Node_Id: This identities the remote node. ^ where it should say: Node_Id: This identifies the remote node. ^ (4) Section 13.8 a) The explanation for "Flags:" on page 57 contains the improperly indented and punctuated entry: vvv 0x0002 Data Link Type If set, the data links to be verified are ports, otherwise they are component links ^ It should specify instead: 0x0002 Data Link Type If set, the data links to be verified are ports, otherwise they are component links. ^ b) The explanation for "Verify Transport Mechanism:", on top of page 58, contains: 0x8000 Payload:Test Message transmitted in the payload ^^ It should say: 0x8000 Payload: Test Message transmitted in the payload ^^^ (5) Wavelength encodings This issue is related to: - Section 13.8, on page 57/58, and - Section 13.12.1, on page 64 plus Section 13.12.1.2 on page 65. Obviously -- and unfortunately --, RFC 4204 avoids specifying the admissible encoding[s] and the related units for data elements specifying Wavelengths. I suspect there could not be reached consensus on a single encoding style. Nevertheless it would have been very desirable for the sake of interoperability to specify a (small) set of standard encodings, e.g.: - IEEE floating point, units: meters; - unsigned32, units: nanometers (or picometers?); - unsigned32 implementation specific wavelength identifiers; - 0 always meaning: 'implicit / known by out-of-band methods'. All occurences on 'Wavelength' data elements would have allowed for the addition of some kind of 'wavelength encoding selector', e.g. as a 2-/3-/4-bit subfield of the already present 'Flags' field, or separate values of the already present 'subobject type'. (6) Section 13.12.1 says: This is used to identify the local Interface Switching Type of the TE link as defined in [RFC3471]. It should say: This is used to identify the local Interface Switching Type of the Data link as defined in [RFC3471]. (7) Section 16, near the bottom of page 77, contains wording inconsistent the remainder of this section and with other parts of the document. The two paragraphs: The policy for allocating values out of the LMP Object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class names are allocated. The policy for allocating values out of the LMP Sub-object Class name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated. should better say: vvvv The policy for allocating values out of the LMP Object Class type (C-type) name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which the Object Class types are allocated. The policy for allocating values out of the LMP Sub-object Class type (C-type) name space is part of the definition of the specific Class instance. When a Class is defined, its definition must also include a description of the policy under which sub-objects are allocated. [Notes: The primary name space is the Class type (C-type) name space because its management is essential for interoperability; the class names are subordinated additional labels for the human reader and implementor. Above, I have added "(C-type)" for clarity; this is not absolutely necessary, if you dislike the repetition here. ] (8) There's another small typo in Section 16, at mid-page 82: The headline: o CHANNEL_STATUS_REQUESTClass name (14) should be: o CHANNEL_STATUS_REQUEST Class name (14)
It should say:
[see above]
Notes:
from pending