Reviewer: Brian Trammell Review result: Ready with Nits This document has been reviewed as part of the transport area review team'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 and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document is a readable introduction to the landscape of (presently widely deployed, as opposed to "all defined") translation/encapsulation methods for providing IPv4 Internet access with a IPv6-only access network. I've reviewed it solely with an eye toward potential transport issues. In this aspect, the document is essentially ready. The references and analysis in operational tradeoffs in port number sharing seem solid. I especially appreciated the attention to MTU issues, and the reiteration of advice from MAP-E (RFC7597); as well as the reference for multicast in section 3.6. The document clearly explains the reliance of double-translation approaches on ports in the transport layer, though it might be useful to note that "port aware" means "has a 16-bit source port in network order at octet 0 and a 16-bit destination port in network order at octet 2", and though I suspect that very few shipping translators support SCTP, it'd be nice to note that SCTP is indeed port aware. I'm a little surprised by the following: "However, when ports are allocated statically, more customers may get ports from the same public IPv4 address, which may results in negative consequences with higher probability, e.g. many applications and service providers (Sony PlayStation Network, OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that they are used for address sharing." (First, please use "block" instead of "blacklist" here, though the RFC editor respectful language check will also catch that). and... Really? in 2022? Is there some insight into the business reason behind this blocking / a citiation for an analysis of it? Editorial nits (not exhaustive): " The address sharing efficiency of the five technologies is significantly different, it is discussed in Section 4.2" appears to be missing a period at end of sentence. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
