Dear colleagues, On Mon, Dec 01, 2014 at 02:38:32PM -0800, The IESG wrote: > > The IESG has received a request from an individual participant to make > the following status changes: > > - RFC6346 from Experimental to Proposed Standard > (The Address plus Port (A+P) Approach to the IPv4 Address Shortage) Having re-read that document and having read the reasoning behind the move from experimental, I do not support the current proposal, but I support the idea of moving A+P to the standards track. RFC6346bis needs to address a few issues. First, since there was an experiment, somewhere one needs to determine what experimental pieces worked well and what parts did not. Any RFC6346bis should include some notes about what changed between RFC 6346 and whatever new comes out. In particular, section 5 has more than one deployment scenario, and it would be really helpful to understand which scenarios work well (or, better, well enough) and why. Similarly, it seems to me that section 1 should be expanded to include observations about problems with A+P. In addition, I agree with the remarks elsewhere in the thread that reducing the number of ports available to clients reduces their resilience to certain kinds of DNS attacks. I'm aware that someone offers an alternative mechanism elsewhere in this thread, but that is not yet standardized or widely deployed, so it is not an answer today. A+P effectively reduces the utility of a spoofing-resilence technique already deployed, so that surely needs to be in the security considerations. I do not accept the arguments, however, that A+P should not be put on the standards track because doing so would somehow chip away at the legitimacy of the arguments to deploy IPv6. First, I do not think that Experimental status is supposed to be some sort of second-class version of standardization. It is used that way too often, but that is a mistake. The experimental deployments have happened; there are results. If it worked, we should put this on the standards track. At the same time, if the deficiencies of this technique compared to IPv6 are sufficiently described, then either that will be positive evidence that IPv6 is the right thing to do, or else IPv6 is not actually so shiny. Best regards, A -- Andrew Sullivan ajs@xxxxxxxxxxxxxxxxxx