Hello,
I've reviewed this document as part of the transport area directorate's ongoing
effort to review key IETF documents. These comments were written primarily for
the transport area directors, but are copied to the document's authors for
their information and to allow them to address any issues raised. The authors
should consider this review together with any other last-call comments they
receive. Please always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or
forward this review.
I found no major issues with the document, and the document is ready for
publication. Below are some minor nits you might want to consider addressing
before publishing:
* Section 1.1: You could add reference to UPnP/NAT-PMP.
* Bottom of page 16: you could describe with a few words what "delayed
translation" is. (is it address translation that doesn't happen at the edge of
the A+P subsystem?)
* Section 5.2: "There is a general observation that the more demanding customer
uses around 1024 ports when heavily communicating." -- on what is this based
on? Do you have some reference or other data to back this up?
* The typical initial scenario probably is that an A+P gateway is NATing the
traffic to a legacy host in private address realm, but I understood that if a
host/application supports A+P, it could use A+P addressing directly without
NAT. Have you thought how this would be reflected on the socket API? For
example, what would be the intended behavior, if an application tries to bind a
port that was not part of the port range assigned for the host? Is there an
error, or does that trigger some other behavior? You might want to mention
something about such API interactions in some appropriate place (maybe in
5.3.4?). Apparently it is thought that there would be some extended API for an
A+P-aware application to query which ports are available, right?
- Pasi
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf