Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan
RFC 4632

[Ballot comment]
There has been a bit of "re-writing of history", when they say that the
idea for CIDR came out of the ROAD effort. In fact Yakov came up with the
idea when reading the NSAP address allocation draft -- basically Yakov
recognized that the same ideas could be applied to the shorter IP addresses
if you went classless. This was then taken into the ROAD effort when the
concern came up that the other approaches that ROAD were discussing wouldn't
be useful in the immediate short term.

However, I don't think that this is important enough to put in a Discuss --
the authors can fix this if they want to or leave as is.

[Ballot comment]
I note that this obsoletes a Standards Track document with a BCP.  I don't see it written down anywhere that this is OK, but I don't see it forbidden either.  I am happy to see RFC1519 replaced with more up-to-date information.

We changed the status to 'BCP' instead of 'Proposed Standard' on
request of the IESG.

Jari Arkko cleared Margaret's DISCUSS that requested to change the status to BCP
but we still need one more 'No Objection' to clear the 10 Yes/NoOb hurdle.

[Ballot discuss]
At this point, these are more questions/comments for the AD than specific issues to be addressed by the document authors:

I share Ted's concerns about what it means to publish this as a Proposed Standard, as I don't see where this document defines a protocol or external behavior for IP nodes.  Maybe BCP would be more appropriate?

Also, I find it strange that this document doesn't even mention IPv6.  IPv6 also uses CIDR-based address allocation, and I think that some of the conclusions will apply if/when IPv6 is widely-enough deployed to present route scaling issues.

Also, is this document intended to advocate that the IETF should be working on an improved multihoming solution for IPv4?  If so, how/where/when do we intend to undertake that work?  I am somewhat concerned about publishing an IETF standards track document that says we need to do something that we don't have any specific plans to do.

[Ballot discuss]
At this point, these are more questoins/comments from the AD than specific issues to be addressed by the document authors:

I share Ted's concerns about what it means to publish this as a Proposed Standard, as I don't see where this document defines a protocol or external behavior for IP nodes.  Maybe BCP would be more appropriate?

Also, I find it strange that this document doesn't even mention IPv6.  IPv6 also uses CIDR-based address allocation, and I think that some of the conclusions will apply if/when IPv6 is widely-enough deployed to present route scaling issues.

Also, is this document intended to advocate that the IETF should be working on an improved multihoming solution for IPv4?  If so, how/where/when do we intend to undertake that work?  I am somewhat concerned about publishing an IETF standards track document that says we need to do something that we don't have any specific plans to do.

[Ballot comment]
>    simple, legacy end-site configurations, they are considered obsolete
>    and should NOT be used in transit networks connected to the global
>    Internet.

Should there be RFC 2119 keywords in this document? It looks like there *almost* is here.

>    Similarly, routing and forwarding tables in layer-3 network equipment
>    must be organized to store both prefix and prefix length or mask.
>    Equipment which organizes its routing/forwarding information
>    according to legacy class A/B/C network/subnet conventions cannot be
>    expected to work correctly on networks connected to the global
>    Internet; use of such equipment is not recommended.  Fortunately,
>    very little such equipment is in use today.

is not recommended, or NOT RECOMMENDED. Again, are we using 2119 or not?

>    1.  Forwarding in the Internet is done on a longest-match basis.
>        This implies that destinations which are multi-homed relative to
>        a routing domain must always be explicitly announced into that
>        routing domain - they cannot be summarized (this makes intuitive
>        sense - if a network is multi-homed, all of its paths into a
>        routing domain which is "higher" in the hierarchy of networks
>        must be known to the "higher" network).

When I read this, I hit a parsing error, incorrectly matching the two hyphens, and the two overlapping parens. Suggest less reliance on the hyphens here.

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

s/provider/providers

>    5.  A new period of exponential growth again from early 1999 until
>        2001 as the "high-tech bubble" fueled both rapid expansion of
>        Internet as well as a large increase in more-specific route
>        advertisements for multi-homing and traffic engineering.

s/Internet/the Internet

[Ballot discuss]
Given that the document is obsoleting a bunch of informational documents as well as a few standards track documents, this may not be surprising, but it is actually fairly difficult to figure out what, if anything, in the current document is normative for implementations.  Given that this standards track, I assume something is, but it seems that most of the heavy lifting would have to be done in the routing protocol documents that carry cidr prefixes.  Are there any 2119 MUSTs/MAYs/SHOULDs here?

[Ballot comment]
The document gives this bit of history:

  In the early days of the Internet, IPv4 address space assignment was
  performed by the central Network Information Center (NIC).  Class
  A/B/C network numbers were assigned in essentially arbitrary order,
  roughly according to the size of the organizations that requested
  them.  All assignments were recorded centrally and no attempt was
  made to assign network numbers in a manner that would allow routing
  aggregation.

This does not match my memory.  I believe the NIC assigned IPv4 address
space sequentially within each of the network classes, not arbitrarily.  While you could
certainly say that this did not allow routing aggregation, since there is no
necessary relationship between sequence of application and upstream, in fairness
there was a single upstream for much of the time this was in place.

Given how many networks use NAT in combination with CIDR, it seems surprising
that the string " NAT " does not occur in the document; declaring a discussion of it
explicitly out of scope might be useful.

[Ballot discuss]
It looks like the authors have not updated the document to meet some of the AD review comments (David appears to have noted the documentation prefix problem in his question 8, but net 10 still appears, as an example).

Given that the document is obsoleting a bunch of informational documents as well as a few standards track documents, this may not be surprising, but it is actually fairly difficult to figure out what, if anything, in the current document is normative for implementations.  Given that this standards track, I assume something is, but it seems that most of the heavy lifting would have to be done in the routing protocol documents that carry cidr prefixes.  Are there any 2119 MUSTs/MAYs/SHOULDs here?