Re: [Last-Call] Tsvart last call review of draft-ietf-v6ops-transition-comparison-02

> On 15. Mar 2022, at 17:13, Brian Trammell via Datatracker <noreply@ietf.org> 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@ietf.org 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@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call