The Address plus Port (A+P) Approach to the IPv4 Address Shortage
Note: This ballot was opened for revision 10 and is now closed.
DISCUSS: The last item of Pasi Sarolahti's tsv-dir review requires a response. INTRODUCTION, paragraph 1: > Intended status: Experimental DISCUSS: The body of the document does not discuss at all in which way this technology is to be considered experimental, and in which kinds of deployments this technology may be experimented with. In fact, Section 5 is worded in way that suggests a readiness for global deployment. While I understand that this is the opinion of the authors, that is not what Experimental RFCs are for. We had several BOFs on this topic that all failed to convince the community of the value of this approach; I'm surprised to see the same content back with an Experimental label for publication on the IETF Stream. INTRODUCTION, paragraph 10: > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. This document may not be modified, > and derivative works of it may not be created, and it may not be > published except as an Internet-Draft. DISCUSS: The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Section 5.3.4., paragraph 0: > 5.3.4. Limitations of the A+P approach DISCUSS: Just having reviewed draft-ietf-intarea-shared-addressing-issues, this section doesn't even begin to scratch the surface when it comes to limitations. I don't want you to duplicate all the content from draft-ietf-intarea-shared-addressing-issues here, but a reference to this document plus an upfront summary of the limitations described therein need to be added here.
I support publication of this document as an Experimental RFC, but I have concerns that the document content does not accurately reflect community consensus. Since this is being published on the IETF stream, I believe some additional text explaining why this is not on the standards track are in order. To me, the text in combination with publication on the IETF stream gives the impression that this document has significantly more support within the community than it has in reality/
I know the RFC Editor can fix this, but in the spirit of devolving work... You need to not describe the document as a "draft" --- It is not a requirement, but I think it is helpful if Experimental RFCs give some scope to the experiment both in terms of how it is "contained" and how the success of the experiment will be judged. This need not be a lot of text.
I am fine with this document going forward as an experimental RFC, but I would still like the document to be clearer about its role. Its good that it already lists some of its limitations, but I don't think we have IETF-wide agreement on some of the things that the document discusses. These include, for instance, applicability to particular types of networks.
Support Lars' discuss on providing details on evaluating the experiment Please consider adding the text proposed by Richard Barnes at <https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55496&tid=1297789602> This example is somewhat misleading: "(e.g., VoIP clients register a public IP and a single delegated port from the CPE, and accept incoming calls on that port)". Most VoIP clients will ask for a separate port for the voice media from the one used for signaling.
Similarly to Peter, I found behavior of the editor of this document in response to some comments to be unprofessional.