[Tsv-art] Tsvart last call review of draft-ietf-v6ops-transition-comparison-02

[Brian Trammell via Datatracker <[e-mail]>]

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
[e-mail] 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.