Subject: RFC 4783 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Wed, 16 May 2007 18:15:12 +0200 (MESZ)

Hello,
after studying the RFC 4783 (GMPLS Alarm Info Signaling) edited by
you and published last December, I did not find the time to send
my comments quickly.  The recent publication of related RFCs has
now pushed me to resume the processing of my marginal notes.

Hereby, I would like to submit a few comments, pointing out some
issues I found with the RFC text, and supplying material future
consideration in derived work, for an eventual appropriate RFC
Errata Note, and for update directives to the IANA.

The items below are presented in RFC textual order.
I use change bars ('|' in column 1) and occasionally
up/down pointing marker lines ('^^^'/'vvv') to emphasize
the location of textual issues and/or proposed corrections.
Modified text has been re-adjusted to match RFC formatting
rules, where appropriate.

(1)  Section 3.1.1

(1a) -- enhancement

In the past, it has turned out to be a useful practice to
present constant values in diagrams of message (parts)
wherever appropriate.  That practice is a service to the
reader and it enhances the readability of the document.

Therefore, I would have appreciated fo find the constant values
listed in the TLV diagrams in section 3.1.1, on pages 6-8.

For instance, in the upper half of page 6, RFC 4783 says:

   The Reference Count TLV has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |              Type             |             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reference Count                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It might better have said:

   The Reference Count TLV has the following format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     |           Type = 512          |           Length = 8          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Reference Count                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(1b) -- typo / grammar / terminology

Near the end of Section 3.1.1, in the explanation for the Error
String field in the Error String TLV, at the top of page 9,
the RFC says:

                                     [...].  The contents of error
         string are implementation dependent.  [...]

It should better say either:

                                     [...].  The contents of error
|        strings are implementation dependent.  [...]
               ^
or, directly quoting the proper name of the field:
                                                             v
|                                    [...].  The contents of Error
|        String are implementation dependent.  [...]
         ^

(2)  Section 5 -- typo/grammar + missing article

On page 15, the RFC text in Section 5 says:

   IANA administered assignment of new values for namespaces defined in
   this document and reviewed in this section.

It should better say:

   vvvv
|  The IANA administered assignment of new values for namespaces defined
|  in this document is reviewed in this section.
                    ^^

(3)  Section 5.2 -- alignment and ref. tagging

On page 16, Section 5.2 says:

   IANA made the following assignments in the "Interface_ID Types"
   section of the "GMPLS Signaling Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters.

      512 8 REFERENCE_COUNT     RFC 4783
      513 8 SEVERITY            RFC 4783
      514 8 GLOBAL_TIMESTAMP    RFC 4783
      515 8 LOCAL_TIMESTAMP     RFC 4783
      516 variable ERROR_STRING RFC 4783

There are multiple problems with that text:

a) Tabular alignment should be maintained for readability.

b) The IANA file contails full references, and hence the
   reference tags should be written in the usual [RFCxxxx] style.

c) The referenced "Interface_ID Types" section of the IANA file
   contains a third column entitled "Format"; yet, the above text
   does not specify the intended content of that column for the
   newly registered values.  Consequently, IANA has entered (by
   copy & paste from previous entries?) the nonsensical value
   "See below" into this column, for all 5 new lines ('below'
   in the IANA file, there is only the new section according to
   Section 5.3 of this RFC, and the References section!)

To address all these issues, including filling in the missing
column, the RFC should perhaps better say in Section 5.2
(substitute alternate text if you prefer):

   IANA made the following assignments in the "Interface_ID Types"
   section of the "GMPLS Signaling Parameters" registry located at
   http://www.iana.org/assignments/gmpls-sig-parameters.

|  Type   Length  Format        Description                    Reference
|  -----  ------  ------------  -----------------------------  ---------
|    512       8  see RFC 4873  REFERENCE_COUNT                [RFC4783]
|    513       8  see RFC 4873  SEVERITY                       [RFC4783]
|    514       8  see RFC 4873  GLOBAL_TIMESTAMP               [RFC4783]
|    515       8  see RFC 4873  LOCAL_TIMESTAMP                [RFC4783]
|    516  varies  see RFC 4873  ERROR_STRING                   [RFC4783]

I strongly recommend to address this issue by an RFC Errata Note
and have the IANA update the "Interface_ID Types" section
accordingly.

(4)  Section 5.3

(4a) -- ref. tagging

As in item (3) b) above, the text in the table in Section 5.3
(on mid-page 16),
                                                v
|  Value       Name                              Reference
   ----------- -------------------------------- -----------------
   0x80000000  Reflect (R)                      [RFC3473/RFC3471]
   0x00000010  Inhibit Alarm Communication (I)  RFC 4783
   0x00000004  Testing (T)                      [RFC3473/RFC3471]
   [...]

should better say (also adjusting an alignment flaw):

|  Value       Name                             Reference
   ----------- -------------------------------- -----------------
   0x80000000  Reflect (R)                      [RFC3473/RFC3471]
|  0x00000010  Inhibit Alarm Communication (I)  [RFC4783]
   0x00000004  Testing (T)                      [RFC3473/RFC3471]
   [...]

(4b) -- missing IANA policy statement

Additionally, the RFC did not specify the assignment policy
for this new sub-reistry.  Should it be "Standards Action" ?

This should be formally decided, communicated to the IANA, and
documented in an associated note in the registry file.

(5)  Section 5.4 -- ref. tagging

Similarly as in (4a) above, the new registry line presented
in Section 5.4, near the bottom of page 16 says:

   31  Alarms                               RFC 4783

It should say:

   31  Alarms                               [RFC4783]

Please comment and decide on IANA action and posting of an
RFC Errata Note..

Preferrably, you should submit an Author's Errata Note to the
RFC Editor's RFC Errata web pages, making freely use of the
material supplied above.  But if you like, I can formally
submit an Errata Note on my own, with your consent.

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]                     |
+------------------------+--------------------------------------------+