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

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?

Thanks for this clearly written document.

This document feels Informational (not Standards Track) to me, but I'm fine with publication as Proposed Standard.

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.

(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.