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.

The TSV-ART review for this informational document was requested with a deadline of only 4 days during Pentecost holidays in Europe. As a result, this TSV-ART review only represents a quick check.

At first sight, there are some issue related to transport protocols. They are probably not hard to address in a revised draft:

- In section 8, the document assumes that HTTP(S) uses TCP. This is correct for HTTP/1.x and HTTP/2, but not for HTTP/3, as HTTP/3 uses QUIC. The statement regarding HTTP in Section 8 should be reworded.

- Section 4 should more precisely define what a "connection" is in the context of the benchmark test. The text probably assumes "TCP connection" in a number of places, but this should be made very explicit. Some use of the word "connection" probably also applies to all transport protocols, including TCP and UDP, but this is not always true. For instance, Section 4.8 ("Connection Tear-Down") seems to focus only on TCP. In all descriptions of tests, it should be made very clear what transport protocol is assumed.

- The document as a whole does not consider implications of use of QUIC. Given the increasing share of QUIC in the total Internet traffic, this is somewhat surprising. It could make sense to have at least some short discussion on the impact of QUIC on the benchmarking, e.g., in section 8.

- The document only mentions TCP and UDP as Internet transport protocols. It could make sense to at least mention somewhere other that other transport protocols exist (SCTP, possibly also DCCP), possibly as a topic outside the scope of the document. Similarly, issues resulting from multipath transport (e.g., MPTCP) are not discussed in the document. That could be also stated explicitly.

In general, I am not sure if it makes sense to use RFC2119/RFC8174 language in such an informational document. At least in some cases the use of RFC2119/RFC8174 language does not really affect interoperability. An example would be Section 6.

Nit: s/athours/authors/ in Secion 8