> On 15. Mar 2022, at 17:13, Brian Trammell via Datatracker <noreply@xxxxxxxx> wrote: > > 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. SCTP uses the port number concept, as do TCP, UDP, and DCCP. However, an endpoint has a list of IP addresses and a single port number. So you can not translate the port independently on a single path. Best regards Michael > > 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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
