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

[Ballot discuss]
carrying over from Lars Eggert's DISCUSS:


[Ballot discuss]
  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 ...
  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.

[Ballot discuss]
Issue #5 on the list of issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 needs some clarifying edits as agreed in the mail discussion with Ron.

[Ballot comment]
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.

[Ballot comment]
The author's response to cross-area review was unprofessional and not in the spirit of achieving community
consensus.  I support Dan's discuss requiring a reasonable response...

[Ballot discuss]
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/

[Ballot discuss]
Discuss-discuss, which I will clear after the telechat:

* a+p supports and encourages the extended use of IPv4 while providing
  no incentive or support for the transition away from IPv4 to IPv6
* any effort spent on correcting technical issues with a+p would be
  better spent on resolving issues impeding the transition to IPv6

[Ballot discuss]
This document says:

    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.

  I find nothing in the write-up to indicate why this is acceptable.
  In general, IETF stream documents provide change control to the IETF.
  This document is not providing that change control.  There may be a
  reason for the exception, but I cannot find it.

[Ballot discuss]
This document says:

    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.

  I find nothing in the write-up to indicate why this is acceptable.
  In general, IETF stream documents provide change control to the IETF.
  This document is not providing that change control.  There may be a
  reason for the exception, but I cannot find it.

[Ballot discuss]
This document should not be published as it does not address the
fundamental issues that were raised during the shara BoF at IETF 76:

* a+p supports and encourages the extended use of IPv4 while providing
  no incentive or support for the transition away from IPv4 to IPv6
* there are several technical issues that would impede successful
  deployment of a+p
* any effort spent on correcting technical issues with a+p would be
  better spent on resolving issues impeding the transition to IPv6

[Ballot discuss]
The issues raised by Tina Tsou in her review https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=55308&tid=1297852737 were not addressed at the technical level. I would like to see a response on these issues before approving the document. If these were already answered please point me to the answer.

[Ballot comment]
Support Lars' discuss on providing details on evaluating the experiment

Please consider adding the text proposed by Richard Barnes at


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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
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"

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (The A+P Approach to the IPv4 Address Shortage) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'The A+P Approach to the IPv4 Address Shortage'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ymbk-aplusp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ymbk-aplusp/