RFC Errata
RFC 4632, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", August 2006
Source of RFC: grow (ops)
Errata ID: 799
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Tony Li
Date Rejected: 2006-11-01
(1) [[posted separately.]] (2) typo (word replication) In the second paragraph of Section 5.2, at the bottom of page 12, RFC 4632 says: [...]. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which | is part of its aggregate), traffic from the "parent" to the to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. [...] ^^^^^^^^^^^^^ It should say: [...]. If the "child" network were to lose internal connectivity to 192.168.65.0/24 (which | is part of its aggregate), traffic from the "parent" to the "child" destined for 192.168.65.1 will follow the "child's" advertised route. [...] (3) garbled sentence The second paragraph of Section 7, on page 18, says: A description of techniques to populate the IN-ADDR.ARPA zone when and used address that blocks that do not align to octet boundaries is described in [RFC2317]. Apparently, this sentence is garbled; as written, it makes no sense. Perhaps, it was intended to say: A description of techniques to populate the IN-ADDR.ARPA zone when | used address blocks do not align to octet boundaries is described in [RFC2317]. (4) typo (singular/plural mismatch) On page 19, the second enumerated bullet in Section 9 says: 2. Acceleration of the exponential trend in late 1993 and early 1994 as CIDR "supernet" blocks were first assigned by the NIC and routed as separate legacy class-C networks by service provider. It should say: 2. Acceleration of the exponential trend in late 1993 and early 1994 as CIDR "supernet" blocks were first assigned by the NIC and | routed as separate legacy class-C networks by service providers. ^ (5) incomplete status change of legacy documents Section 11 (pp. 21/22) re-classifies a couple of legacy RFCs as Historic. Unfortunately, there are additional documents closely related to these re-classified documents left alone -- and apparently still current. IMHO, it would have been much clearer to also re-classify RFC 1797 and RFC 1879 as Historic, as well. Note: Admittedly, there may be a gap in the IETF document maintenance procedures not formally allowing Informational and Experimental RFCs to be re-classified as Historic. If this was the reason for omitting the named RFCs from Section 11 of RFC 4632, it would perhaps have been useful to "obsolete" these RFCs by RFC 4632. This situation is bound to recur with more Informational RFCs published as companion documents to Standards Track RFCs; thus, a general procedural solution should be sought to visibly (in the RFC index) 'outdate' such RFCs when updates get published.
Notes:
from pending
--VERIFIER COMMENT--
Thank you very much for your eagle eyes and your comments. I agree
with all of them. If you had submitted them during the Internet-draft
process, I would make all of these modifications immediately.
However, now that the RFC is issued, I believe that we should be quite
a bit more conservative before issuing Errata, so as to not congest
the Errata and obscure vital and substantive changes that might affect
actual interoperability of standards interpretation. With that view
in mind, I'd like to suggest that we not issue any Errata at this
time. I look forward to your input on subsequent draft documents.