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@xxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf