Scalable Operation of Address Translators with Per-Interface Bindings
draft-arkko-dual-stack-extra-lite-05

[Ballot comment]
I agree with Peter about this feeling more Informational than Standards Track as it feels more like how you might configure or operate a single node. However, the responsible AD assures me there are implementation/interop implications, so I have moved this point out of my Discuss and just leave it for consideraiton of the authors along with the other Comments.

---

I didn't really find that Section 2 "Solution Outline" was an
outline of the solution. It looks more like an overview of the
problem space and the benefits of the yet-to-be-introduced
solution.

---

Maybe Section 3 should also say that "internal realm" and
"external realm" are derived from somewhere?

---

Section 3
  This document uses the term mapping as defined in [RFC4787] to refer
  to state at the NAT necessary for network address and port
  translation of sessions.
Could you put "mapping" in quotes to stop the reader getting confused
that you are refering to a process of "term mapping".

---

Section 4
Strictly speaking, isn't there a limit to the "arbitrary number" of
devices served by a NAT? So it isn't really arbitrary?

---

Maybe take the chance to update the info about the IANA free pool?

[Ballot comment]
I agree with Peter about this feeling more Informational than Standards Track as it feels more like how you might configure or operate a single node. However, the responsible AD assures me there are implementation/interop implications, so I have moved this point out of my Discuss and just leave it for consideraiton of the authors along with the other Comments.
---
I didn't really find that Section 2 "Solution Outline" was an
outline of the solution. It looks more like an overview of the
problem space and the benefits of the yet-to-be-introduced
solution.
---                                                 
Maybe Section 3 should also say that "internal realm" and
"external realm" are derived from somewhere?
---
Section 3                                                 
  This document uses the term mapping as defined in [RFC4787] to refer
  to state at the NAT necessary for network address and port
  translation of sessions.
Could you put "mapping" in quotes to stop the reader getting confused
that you are refering to a process of "term mapping".
---
Section 4
Strictly speaking, isn't there a limit to the "arbitrary number" of
devices served by a NAT? So it isn't really arbitrary?
---
Maybe take the chance to update the info about the IANA free pool?

[Ballot comment]
I cannot remember why discuss "I understand that one of the authors raised some late comments and I would like to evaluate them" was added to the tracker - perhaps something that came up on the telechat. I can find no followup email, so I am clearing.

[Ballot discuss]
Discuss updated after discussion with authors

I support this document, but I struggled with this document to understand what there is to implement. It all seemed a bit "obvious". Is this really a BCP or Informational?

[Ballot comment]
I agree that this looks a lot more like informational that standards track.

I also agree that the introduction should be updated to reflect the exhaustion of the IPv4 address space.

[Ballot comment]
(1) Some of the introductory material is out of date.  Specifically, the IANA free pool has now been exhausted but the document states:

  At the time of writing, the IANA "free pool" contained only 12 unallocated unicast IPv4 /8 prefixes.

This should be corrected, since the date on the RFC will be long after the free pool was depleted.

(2) I support Adrian's discuss.  Feels like informational or BCP.  Given that the free pool is exhausted I lean towards BCP, but that would require another IETF Last Call.

[Ballot comment]
(1) Some of the introductory material is out of date.  Specifically, the IANA free pool has now been exhausted but the document states:

  At the time of writing, the IANA "free pool" contained only 12 unallocated unicast IPv4 /8 prefixes.

This should be corrected, since the date on the RFC will be long after the free pool was depleted.

(2) I agree with Adrian's discuss.  Feels like informational or BCP.  Given that the free pool is exhausted I lean towards BCP, but that would require another IETF Last Call.

[Ballot comment]
Some of the introductory material is out of date.  Specifically, the IANA free pool has now been exhausted but the document states:

                                                                              At the time of
  writing, the IANA "free pool" contained only 12 unallocated unicast
  IPv4 /8 prefixes.

This should be corrected, since the date on the RFC will be long after the free pool was depleted.

[Ballot comment]
I didn't really find that Section 2 "Solution Outline" was an
outline of the solution. It looks more like an overview of the
problem space and the benefits of the yet-to-be-introduced
solution.
---                                                 
Maybe Section 3 should also say that "internal realm" and
"external realm" are derived from somewhere?
---
Section 3                                                 
  This document uses the term mapping as defined in [RFC4787] to refer
  to state at the NAT necessary for network address and port
  translation of sessions.
Could you put "mapping" in quotes to stop the reader getting confused
that you are refering to a process of "term mapping".
---
Section 4
Strictly speaking, isn't there a limit to the "arbitrary number" of
devices served by a NAT? So it isn't really arbitrary?
---
Maybe take the chance to update the info about the IANA free pool?

[Ballot discuss]
I support this document, but...
---
I struggled with this document to understand what there is to
implement. It all seemed a bit "obvious". Is this really a BCP
or Informational?
---
Shouldn't section 4 talk about what to do when an interface has used up the available number of IP addresses? Crea ting a "parallel" virtual interface may not be a big deal, but creating the first virtual interface when a physical insterface is "full" seems like a major operational step

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:  (Scalable Operation of Address Translators with Per-Interface Bindings) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Scalable Operation of Address Translators with Per-Interface Bindings'
  as a Proposed Standard

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-10. 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-arkko-dual-stack-extra-lite/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-arkko-dual-stack-extra-lite/

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication? 

There is no document shepherd. The authors believe the document is
ready.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed? 

There has been some discussion about this in various forums, including
SOFTWIRE WG, 3GPP, and various smaller groups. The draft obviously
would benefit from additional review at IETF Last Call, but given that
it crystallizes a simple idea behind existing implementations as well
as some other IETF technology (dual stack lite), its hard to see any
technical issues popping up.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML? 

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director and/or
the IESG should be aware of? For example, perhaps he or        she
is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here. 

No.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it? 

We have not encountered any individual who would disagree with the
basic principles outlined in this draft, though, of course, whether
this approach is sufficient in a particular environment vs. some other
mechanisms can still bring up discussions.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
          and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews? 

It does satisfy all of this. In rev -03...

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967]. 

All OK.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation? 

N.A.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker? 

N.A.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

  Technical Summary 

This document explains how to employ address translation in
networks that serve a large number of individual customers without
requiring a correspondingly large amount of private IPv4 address
space.

  Working Group Summary

This is a submission outside the working groups, but has been
discussed in the SOFTWIRE working group and in the 3GPP in the context
of discussions around transition to IPv6.

  Document Quality   

There are implementations of this specification, according to
information from IETF participants, Cisco for instance has an
implementation. There are also plans for additional implementations.