IETF Last Call Review of draft-ietf-iotops-7228bis-07
review-ietf-iotops-7228bis-07-tsvart-lc-ihlar-2026-05-07-00

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.”