Scalable Operation of Address Translators with Per-Interface Bindings
RFC 6619
Yes
No Objection
Recuse
Note: This ballot was opened for revision 05 and is now closed.
Lars Eggert Recuse
(Ralph Droms; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
(Adrian Farrel; former steering group member) (was Discuss) No Objection
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?
(Alexey Melnikov; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
Thanks for this clearly written document. This document feels Informational (not Standards Track) to me, but I'm fine with publication as Proposed Standard.
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
(Stewart Bryant; former steering group member) (was Discuss, No Objection) No Objection
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.
(Tim Polk; former steering group member) No Objection
(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.
(Jari Arkko; former steering group member) Recuse