Subject: RFC 4204 (LMP)

From: Alfred Hönes <[email-masked]>
Date: Tue, 20 Dec 2005 16:10:26 +0100 (MEZ)

Hello,

I'd like to submit a few comments on the LMP RFC 4204 recently
published, using the 'Contact Address' given therein.

The numbered items are presented below according to the first
appearance of a text passage raising the issues.
I freely insert lines with '^^^^' style tags to emphasize the
places of proposed changes to the text.

[Admittedly, that RFC contains an extraordinarily small number
 of typos compared with other documents of similar size!]

- - - - - - - - - - - - -

(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, on page 64, below the diagram, says:

   Switching Type: 8 bits

      This is used to identify the local Interface Switching Type of the
      TE link as defined in [RFC3471].
      ^^
Studying the context lead me to the conclusion that it probably
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)

- - - - - - - - - - - - -

Please comment and decide which of the items above should be
submitted for an RFC Errata Note.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+