Subject: RFC 4632

From: Alfred Hönes <[email-masked]>
Date: Wed, 1 Nov 2006 12:48:26 +0100 (MEZ)

Hello,
reading the recently published RFC 4632 (CIDR; BCP 122)
authored by you, I found a couple of flaws worth being noted.
Most issues are pure textual or editorial in nature.

(1)  misleading indentation

In Section 2, on page 4 of RFC 4632, the text after the
enumerated item '3.' up to the end of the section is indented
too much (by 4 columns), making it erroneously appear to belong
to that item '3.'

Where the RFC says:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

|      It was clear that then-current rates of Internet growth would
|      cause the first two problems to become critical sometime between
|      1993 and 1995.  Work already in progress on topological
|      assignment of addressing for Connectionless Network Service
|      (CLNS), which was presented to the community at the Boulder IETF
|      in December of 1990, led to thoughts on how to re-structure the
|      32-bit IPv4 address space to increase its lifespan.  Work in the
|      ROAD group followed and eventually resulted in the publication of
|      [RFC1338], and later, [RFC1519].

|      The design and deployment of CIDR was intended to solve these
|      problems by providing a mechanism to slow the growth of global
|      routing tables and to reduce the rate of consumption of IPv4
|      address space.  It did not and does not attempt to solve the
|      third problem, which is of a more long-term nature; instead, it
|      endeavors to ease enough of the short- to mid-term difficulties
|      to allow the Internet to continue to function efficiently while
|      progress is made on a longer-term solution.

|      More historical background on this effort and on the ROAD group
|      may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

It should say:

   3.  Eventual exhaustion of the 32-bit IPv4 address space.

|  It was clear that then-current rates of Internet growth would
|  cause the first two problems to become critical sometime between
|  1993 and 1995.  Work already in progress on topological
|  assignment of addressing for Connectionless Network Service
|  (CLNS), which was presented to the community at the Boulder IETF
|  in December of 1990, led to thoughts on how to re-structure the
|  32-bit IPv4 address space to increase its lifespan.  Work in the
|  ROAD group followed and eventually resulted in the publication of
|  [RFC1338], and later, [RFC1519].

|  The design and deployment of CIDR was intended to solve these
|  problems by providing a mechanism to slow the growth of global
|  routing tables and to reduce the rate of consumption of IPv4
|  address space.  It did not and does not attempt to solve the
|  third problem, which is of a more long-term nature; instead, it
|  endeavors to ease enough of the short- to mid-term difficulties
|  to allow the Internet to continue to function efficiently while
|  progress is made on a longer-term solution.

|  More historical background on this effort and on the ROAD group
|  may be found in [RFC1380] and at [LWRD].

3.  Classless Addressing as a Solution

(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.

Please comment, and decide on the submission of an RFC Errata Note
to address the above issues -- or some of these.

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