Skip to main content

The Address plus Port (A+P) Approach to the IPv4 Address Shortage
RFC 6346

Discuss


Yes

(Ron Bonica)

No Objection

(Dan Romascanu)
(Russ Housley)
(Wesley Eddy)

Abstain

(Peter Saint-Andre)

No Record

(Ralph Droms)

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert
Discuss
Discuss (2011-02-15)
  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.
Tim Polk Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2011-02-17)
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/
Ron Bonica Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2011-02-15)
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.
Dan Romascanu Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection (2011-02-17)
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.
Robert Sparks Former IESG member
No Objection
No Objection (2011-02-15)
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.
Russ Housley Former IESG member
(was Discuss, Yes) No Objection
No Objection ()

                            
Wesley Eddy Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Alexey Melnikov Former IESG member
Abstain
Abstain (2011-02-17)
Similarly to Peter, I found behavior of the editor of this document in response to some comments to be unprofessional.
Peter Saint-Andre Former IESG member
Abstain
Abstain ()

                            
Ralph Droms Former IESG member
(was Discuss) No Record
No Record ()