Issues with Private IP Addressing in the Internet
draft-ietf-grow-private-ip-sp-cores-07

I have no objection to the publication of this document.

It did feel to me,on reading the doument, that the problems reported are all associated with attempting to deploy a flat network using private addressing. However, the observation that one motivting factor is "core hiding" makes it reasonable to observe that the problems do not exist if proper network layereing is applied. Of course, such layering makes network operation more complex and also makes some functions (like traceroute) impossible or secret, while other functions (such as PMTUD) require cross-layer coordination.

That doesn't detract from the document, but suggest that issues may be less black/white.

OTOH one might note that IPv6 removes the largest "need" for private addressing and so this document should be reporting an interesting quirk of history!

When I read in the abstract RFC1918 + loopbacks, I was immediately thinking: that's bad from a opeational/management point of view, because, in many networks, the loopback IP address is the unique router identifier in the NMS applications.
Thinking some more... as long as the loopback addresses are unique, this should be fine.
However, applying RFC1918 IP addresses to loopbacks is still looking for problem from an operational point of view.
- Let's assume, in this world of acquisitions, that the network operator has to merge two networks, each using the same same private IP block for their respective loopbacks... he has to renumber one of the two networks.
- Let's assume, in this connected world, that the network operator has to compare NetFlow/IPFIX flow records from different routers in different networks and those networks use the same private IP addresses block for their respective loopbacks... He has a problem, because, most of the time, the unique id in the collector is the source IP address of the UDP export, so the loopback. Same thing for syslog btw.

I'm wondering if it would not be worth completing the section 9 "Operational and Troubleshooting issues"?

1. The document uses several acronyms without expansion.  For example, the introduction does not expand RIR on its first use.

2. The note in the introduction could be clarified.  I don't think "stolen" is appropriate in this context.  The draft actually uses the correct term "squat", but only as an alternative.  I would suggest removing the use of "stolen" and replacing it with "squat" since addresses are not property.

3. The figures, especially the one in Section 3, are hard to follow.  Would it be possible to re-work them with more/better delineation between devices?  I can provide an example if it would help.

I support Brian's DISCUSS point no. 1 about why only TCP is named for PMTUD in Section 4. 

Another point to be considered:

Section 5., paragraph 1:

>    Private addressing is legitimately used within many enterprise,
>    corporate or government networks for internal network addressing.
>    When users on the inside of the network require Internet access, they
>    will typically connect through a perimeter router, firewall, or
>    network proxy, that provides Network Address Translation (NAT) or
>    Network Address Port Translation (NAPT) services to a public
>    interface.

  Why not simply saying that this type of traffic passes through a NAT
  when heading for the public Internet. It does not matter if the NAT
  is implemented on a stand-alone device, a router, a set top box, etc.
  The current text might just cause confusion for an average reader.

  Please consider the suggested changes from the Gen-ART Review by
  Suresh Krishnan on 16-July-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07609.html