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 is a useful terminology update to RFC 7228. Since it does not define or update any protocols, I do not see any major TSV issues.
Some of the terminology and classifications are TSV-adjacent, though. I have a few comments and suggestions below, but nothing blocking in my view.

Section 2.2

The term “duty cycle” is used here without further description. It is described later in Section 4.3. Since the term can mean slightly different things in different contexts, it could be useful to add a short explanation at first use, for example:

“low achievable bitrate/throughput, including limits on communication duty cycle (for example, restrictions on transmit airtime or receive availability)”.

Section 3

The description of Class 1 devices states that they cannot easily talk to other devices using HTTP/TLS but are capable of using dedicated stacks such as CoAP. This is probably reasonable. However, many protocol implementations and profiles have evolved since RFC 7228, including compact TLS/DTLS implementations, CoAP profiles, CBOR-based encodings, and constrained-security mechanisms. The text now reads somewhat like a hard boundary between “full” HTTP/TLS stacks and CoAP/UDP. Perhaps a bit more nuance could be useful here.

Section 5.3

As mentioned in other reviews, MSL might not be the most appropriate marker for “challenged networks”. I understand that it is useful to have a somewhat well-defined value to base definitions on, but tying definitions to a TCP-specific parameter might not be the most future-proof choice. For example, the TCP specification uses an MSL value of 2 minutes, whereas different major operating systems use significantly smaller values, such as 15 or 30 seconds. So talking about an assumed MSL on the Internet might not really reflect what implementations assume today.

Perhaps consider more transport-neutral terminology here, for instance something like:

“B0 technologies can lead to very high frame transmission times, which may be comparable to or exceed the time scales assumed by many Internet transport protocols, middleboxes, and applications for retransmission, liveness detection, and state retention.”