Search RFCs

RFC Editor

Found 1 record.

Status:Held for Document Update (1)

RFC 4204, "Link Management Protocol (LMP)", October 2005

Note: This RFC has been updated byRFC 6898

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 followingparameter:   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 similarcontexts 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 willbe  <Rl> - 1 , thereby restricting the allowed range for <Rl> to 1or above, excluding the value 0, without mentioning this fact.Because Section 10.2 codifies the abovementioned definition and thiscertainly should not be changed after the fact of publication as anRFC, it might be advisable to post a warning note pointing to thespecific semantics of 'retry limit' with LMP, the admitted valuerange, 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 ascomprising the cumulative size of the object contents *and* theobject prefix (4 bytes).  This unnecessarily creates illegalvalues (0..3) for 'Length' which must be checked for in allimplementations.  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 efficientlytestable) 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 diagramfor '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 sectionsays 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.8a) The explanation for "Flags:" on page 57 contains the improperlyindented 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 ofpage 58, contains:      0x8000 Payload:Test Message transmitted in the payload                    ^^It should say:      0x8000 Payload: Test Message transmitted in the payload                    ^^^(5) Wavelength encodingsThis 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 theadmissible encoding[s] and the related units for data elementsspecifying Wavelengths.I suspect there could not be reached consensus on a single encodingstyle.  Nevertheless it would have been very desirable for the sakeof 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 forthe 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 inconsistentthe 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

Report New Errata