RFC Errata
Found 2 records.
Status: Verified (1)
RFC 4384, "BGP Communities for Data Collection", February 2006
Source of RFC: grow (ops)
Errata ID: 4550
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Warren Turkal
Date Reported: 2015-12-01
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2023-02-06
Section 4.1 says:
The chart at the bottom of 4.1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x0008 | 0x2A7C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It should say:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x08 | 0x2A7C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Notes:
The second group has a hex value that looks like two octets: "0x0008". If I am interpreting the chart, extended community RFCs, and the extended community IANA registry correctly, the second group should be a single octet (i.e., "0x08").
Also, the same error is in the Section 4.2 chart.
Warren Kumari: I've marked this Verified, and retained the previous rejection note below for transparency.
See registry at: https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#trans-two-octet-as for details, and also thread at: https://mailarchive.ietf.org/arch/msg/grow/p0NDCuSN8YfvVqG1mlyGv0b3-Ng/
--PREVIOUS VERIFIER NOTES--
The Transitive Two-Octet AS-Specific Extended Community Sub-Types registry specifies the low order byte as it notes:
Reference
[RFC7153]
Note
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first
octet (the "Type" field) is 0x00.
so the diagram which includes both is correct but obviously somewhat hard to read since it contains both bytes. I think this proposed text ads little additional clarity.
Status: Held for Document Update (1)
RFC 4384, "BGP Communities for Data Collection", February 2006
Source of RFC: grow (ops)
Errata ID: 106
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-02-27
Held for Document Update by: Ron Bonica
(1)
RFC 4384, in the table legend on page 6, and in Section 6,
at the bottom of page 9, refers to ISO 3166-2 for numeric
country codes. This is not correct.
ISO 3166-2 specifies codes for *subdivisions* of countries,
e.g. the States of the U.S.A., or the provinces of Canada.
The numeric Country Codes apparently used in RFC 4384 in fact
are defined and maintained as a part of ISO 3166-1 !
That Standard contains 3 tables: 2-character, 3-character,
and numeric Country Codes. Unfortunately, only the first
table (also used for ccTLDs in the DNS) is made publicly
(online) available by ISO; apparently this has generally
raised the impression that ISO 3166-1 just comprised that
single table. (This might have been the background for
mentioning ISO 3166-2 in the RFC.)
ISO certainly would appreciate if many people bought the
ISO 3166-2 database when looking for the numeric country
codes, but probably neither ISOC/IETF nor the RFC author
would be participating in such earnings of ISO :-)
Therefore, I propose to correct this flaw by means of an
RFC Errata Note, as follows:
RFC 4384, on mid-page 6, says:
<CC> is the 10-bit ISO-3166-2 country code [ISO3166]
Where it should say:
<CC> is the 10-bit ISO-3166-1 country code [ISO3166]
^^^
Accordingly, the final sentence of Section 6, on page 9,
saying:
[...]. Henk Uijterwaal suggested the use
of the ISO-3166-2 country codes.
should say:
[...]. Henk Uijterwaal suggested the use
of the ISO-3166-1 numeric country codes.
^^^^^^^^^
(2)
According to the explanation in Section 3 (page 5), the <Value>
filed is 16 bit wide, and the last sentence on page 5 in Section 4
emphasized the split format "<AS>:<Value>". (The references to
<Value> in section 4.1 are consistent with that terminology.)
Therefore, in the table on page 6, the "<AS>:" leaders in the
column titled "Value" are inappropriate.
Perhaps, a 'minimally invasive' correction should modify the
headline, not the table entries:
The headline of the table on page 6,
Category Value
should say:
Category <AS>:<Value>
(3)
The encoding diagram in section 4.2, on page 9, apparently
contains the concrete sample value, '0x10F2' (from the
immediately preceding example in Section 4.1), where it
probably should contain the abstract notion "<Value>".
The literal encoding as presented is misleading, hence
the following correction seems to be appropriate:
RFC 4384, in section 4.2 on page 9 contains the diagram:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | 0x10F2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This diagram should say:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x0008 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator (cont.) | <Value> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(4)
RFC 4384 makes a Normative Reference to RFC 1771.
But, almost 3 weeks ahead of the publication of RFC 4384,
RFC 1771 has been obsoleted by RFC 4271.
Has this obsolete reference been made intentionally (I cannot
see any immediate reason for doing so) -- or is it just an
editorial oversight?
Notes:
from pending