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 document tries to mildly improve the wire efficiency of RFC 8935 by allowing multiple Security Event Tokens (SETs) in a single POST request, and multiple acknowledgement/error messages for such tokens in a single POST response. This saves some bytes, which IMO is not a big deal. The real benefit is that it prevents head-of-line blocking when pipelining SETs over HTTP/1.1.

In this reviewer's opinion, simply switching to a multi-stream protocol (HTTP/2 or 3) would achieve much of these gains without requiring a lot of bespoke code. Nevertheless, the design is workable, but raises certain transport topics that could use more attention.

1) Flow control: when there is one SET per request as in RFC 8935, HTTP/2 and 3 intrinsically flow control SETs by limiting the number of open request streams. In this draft, this system no longer works, requiring out of band flow control information.

There is also the possibility that a POST is so large (see Sec 7.1) that either the response is delayed by the extended latency of the transfer, or a response is sent before the server recognizes a 413 is in order.

2) Retransmission: The draft appears to introduce much more scope for retransmissions than RFC 8935. The RFC discusses retry after error or connection failure, while Section 6 of the draft implies that a transmitter should send SETs again if the response is much delayed. If not simply poorly worded, this is a major expansion of the mechanic. I have two concerns: first, HTTP goes over reliable transports, so barring connection failure or application-layer error, there should be no need for an app layer retransmission. Second, if there is to be some sort of timer-based response to missing ACKs, something like BCP 233 should be a consideration in the design. As it stands, any such timer-based system is wildly underspecified. I would recommend that the document more closely adhere to the conventions of RFC 8935, which does not attempt to preempt transport-layer retransmissions.

3) Hanging POSTs. One of the examples shows that a common pattern may be that a request includes multiple SETs and only some of them may be closed in the response. If acks/errors are outstanding when all requests have responses, the client will have to send one or more "Hanging POSTs" to elicit a Response that has the remaining information. While this will work, it is inferior to properly full-duplex designs like WebSockets or WebTransport.

If a client *doesn't* send a hanging POST, then a server could be stuck with pending ACKs indefinitely. Is there a DoS attack in there?

4) Mapping ACKs to responses. The ack(s) for a POST can be completely detached from the response to that POST. Say the protocol uses HTTP/2 and there are five POSTs sent out on different streams in rapid succession; as acks are readied for the SETs in them, are there any best practices for how to respond to those POSTS? e.g. should the acks get grouped into the response to the POST that carried the SET? Should all available ACKs be batched into one response so that other streams are still open for future responses? Once all acks are ready, should the server strive to make sure all the streams are closed?