RFC Errata
RFC 4783, "GMPLS - Communication of Alarm Information", December 2006
Source of RFC: ccamp (rtg)
Errata ID: 971
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-05-16
Held for Document Update by: Adrian Farrel
(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]
It should say:
[see above]
Notes:
from pending