The Address plus Port (A+P) Approach to the IPv4 Address Shortage
draft-ymbk-aplusp-10

  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/