IETF Last Call Review of draft-ietf-quic-reliable-stream-reset-09
review-ietf-quic-reliable-stream-reset-09-genart-lc-holmberg-2026-08-03-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-quic-reliable-stream-reset-09
Reviewer: Christer Holmberg
Review Date: 2026-08-03
IETF LC End Date: 2026-08-03
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, and easy to understand. However, I do
have some comments and questions that I'd like to authors to address.

Major issues: N/A

Minor issues:

---
Section 4:

The text says that RESET_STREAM_AT frames must not not violate flow control
limits at the time of sending, and that the sender makes a commitment to
retransmit Reliable Size amount of data.

Q: What happens if the available flow control credit drops below Reliable Size
after RESET_STREAM_AT has been sent? E.g. due to a connection migration. Should
the draft mandate sending a new RESET_STREAM_AT frame, with a Reliable Size
that fits the new control credit (as described in Section 5.2)?

---
Section 5:

The text says:

"When using a RESET_STREAM_AT frame, the initiator MUST guarantee
reliable delivery of stream data of at least Reliable Size bytes.  If
STREAM frames containing data up to that byte offset are lost, the
initiator MUST retransmit this data, as described in Section 13.3 of
[RFC9000].  Data sent beyond that byte offset SHOULD NOT be
retransmitted."

Q: Are there cases where data sent beyond the byte offset would be
retransmitted? If so, maybe adding some examples? If not, could SHOULD NOT be
replaced with MUST NOT?

---
Section 5.4:

The text says:

"While it is permissible to send a RESET_STREAM_AT frame in this case,
endpoints SHOULD send a RESET_STREAM frame, since the peer has already
indicated that it does not intend to process any further data."

Q: Is there a reason why RESET_STREAM_AT with Reliable Size = 0 could not be
sent? It would be explicit, and match the peer's indication that it does not
intend to process any further data.

---

Nits/editorial comments:

---
Section 3:

Q: Please add a reference to RFC 9001 for 0-RTT.

---
Section 3:

The text first says that the transport parameter is sent with an empty value,
and then the text says that both endpoints must remember the value.

Q: It sounds a little confusing to "remember an empty value". Perhaps saying
that both endpoints must remember the presence of the transport parameter with
the empty value, or something like that?

---