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.

As a preface, this review is performed focusing on the changes since RFC 5766, as this document appears to be a fairly direct update of that content.

Transport issues:

Although this document has substantial implications for transport protocols, it does not significantly alter the content of RFC5766 in this regard. However, there is a significant gap as follows:

- The direct translation of TCP into UDP or UDP into TCP is arguably a host endpoint emulation function, which strongly suggests that this document needs to explicitly address both receiving and transmitting transport options. Even if all received options are ignored and no options are used on transmission, that should be more directly stated – as well as the impact of that decision, both on functionality and security.

Sec 2.7 might also note that the support for UDP fragmentation and reassembly could be of benefit here in avoiding IP fragmentation, but that would be contingent on the previous note – i.e., being able to use and react to UDP options in the translation process.

Non-transport issues:

Like RFC 5766, this doc continues to cite I-D.rosenberg-mmusic-ice-nonsip as guidance, even using a gentle version of “must”, but this no longer seems appropriate because that document has expired over a decade ago. Either the guidance should be summarized in this document or the recommendation should be removed.

Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses the receiver reassembly minimum (EMTU_R, 576) for the link MTU (EMTU_S, 68). See draft-ietf-tunnels for details. If 576 is the focus, at best it could be claimed that 576 is the “de-facto” EMTU_S for IPv4.
Other nits:

Sec 23 indicates the changes since RFC5766; a similar section addressing changes since RFC6156 would be useful to add.