IETF Last Call Review of draft-ietf-quic-reliable-stream-reset-09
review-ietf-quic-reliable-stream-reset-09-secdir-lc-mihalcea-2026-07-29-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is Almost Ready.

The draft defines a new frame for QUIC, allowing senders to reset a stream with
the promise of reliable delivery for a given amount of data on said stream.

The document is well written and seems comprehensive in integrating the new
mechanism in the QUIC stream management machinery. I noticed a few
inconsistencies (which might be due to my lack of expertise with QUIC),
described below.

At the end of sec. 1: "application protocols continue to treat this stream
function as an abrupt termination". Clarifying question: is this in the sense
that application protocol can expect no new data to be sent over this stream?
Because "abrupt termination" doesn't seem representative of the new behaviour
overall.

In sec. 5: "A RESET_STREAM_AT frame with this value is logically equivalent to
a RESET_STREAM frame". I'm not sure this is consistent with the state machine
transitions described in sec. 5.3. For example, with RESET_STREAM the state
machine is not expected to go from Recv through Size Known.

In sec 5.3: "Conversely, if bytes below that offset still need to be sent or
acknowledged, the transition might take multiple network roundtrips and *might
require additional flow control credit issued by the receiver*." (emphasis
mine) It seems impossible to reach the state described at the end, requiring
additional flow control credit. In sec. 4 you note that "An endpoint MUST NOT
send a RESET_STREAM_AT frame that exceeds the largest maximum stream data value
advertised by the receiver for the stream, or that violates the receiver's
maximum data limit." Coupled with "If the Reliable Size is larger than the
Final Size, the receiver MUST close the connection", Reliable Size must always
be fully accounted for in the current flow control credit.

In sec. 5.3: "This might require the receiver to issue additional flow control
credit." - identical reasoning to above.

Thanks!