Search RFCs
The Series
For Authors
Sponsor
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 numericcountry 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 factare 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 firsttable (also used for ccTLDs in the DNS) is made publicly(online) available by ISO; apparently this has generallyraised the impression that ISO 3166-1 just comprised thatsingle table. (This might have been the background formentioning ISO 3166-2 in the RFC.)ISO certainly would appreciate if many people bought theISO 3166-2 database when looking for the numeric countrycodes, but probably neither ISOC/IETF nor the RFC authorwould be participating in such earnings of ISO :-)Therefore, I propose to correct this flaw by means of anRFC 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 4emphasized 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 thecolumn titled "Value" are inappropriate.Perhaps, a 'minimally invasive' correction should modify theheadline, not the table entries:The headline of the table on page 6, Category Valueshould say: Category <AS>:<Value>(3)The encoding diagram in section 4.2, on page 9, apparentlycontains the concrete sample value, '0x10F2' (from theimmediately preceding example in Section 4.1), where itprobably should contain the abstract notion "<Value>".The literal encoding as presented is misleading, hencethe 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 cannotsee any immediate reason for doing so) -- or is it just aneditorial oversight?
Notes:
from pending