QUIC Stream Resets with Partial Delivery
draft-ietf-quic-reliable-stream-reset-10

[Ballot comment]
# IESG review of draft-ietf-quic-reliable-stream-reset-10

CC @MikeBishop

## Comments

### Section 4, paragraph 8
```
    Reliable Size:  A variable-length integer indicating the amount of
        data that needs to be delivered to the application even though the
        stream is reset.
```
I would suggest "minimum amount". An implementation could reasonably deliver more if
the packets have arrived, as you note in Section 5.

### Section 4, paragraph 11

We've all assumed the normal QUIC extension convention, but nothing
here actually *says* you MUST NOT send this frame unless the peer set the
corresponding transport parameter. Worth being explicit.

### Section 5, paragraph 1
```
    A sender that wants to reset a stream but also deliver some bytes to
```
"Deliver some bytes" doesn't feel like it captures why this matters. Perhaps
"...stream while retaining reliable delivery of certain data"?

### Section 5.2, paragraph 1
```
    When reducing the Reliable Size, the sender MUST retransmit the
    RESET_STREAM_AT frame carrying the smallest Reliable Size as well as
```
RFC 9000 is very deliberate that frames are not retransmitted; their information
is (Section 13.3, para 1). Suggest rephrasing to say that the Reliable Size can
only decrease, and acknowledgement of a frame carrying one size does not
acknowledge a later, smaller size. The Reliable Size must be retransmitted until
the current value has been acknowledged.

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Section 5, paragraph 2

Context; suppressed or withheld from the application by an implementation.

### Section 5.2, paragraph 0

"the stream data" => "that stream data" to be clear it's only the data "up
to that size"

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]
Section 5.4:

317 >    An endpoint that receives a STOP_SENDING frame is required to send a
318 >    RESET_STREAM frame in some stream states, as described in Section 3.5
319 >    of [RFC9000].  While it is permissible to send a RESET_STREAM_AT
320 >    frame in this case, endpoints SHOULD send a RESET_STREAM frame, since
321 >    the peer has already indicated that it does not intend to process any
322 >    further data.

I support Ketan's and Éric's COMMENTs on the SHOULD here. There's a concrete
answer available that the text doesn't spell out: Section 5.2 already gives
implementers a graceful way to walk back a commitment made before
STOP_SENDING arrived.

248 >    The initiator MAY send multiple RESET_STREAM_AT frames for the same
249 >    stream in order to reduce the Reliable Size.  It MAY also send a
250 >    RESET_STREAM frame, which for purposes of data delivery is equivalent
251 >    to sending a RESET_STREAM_AT frame with a Reliable Size of zero.

If an endpoint already sent a RESET_STREAM_AT with a positive Reliable Size
before STOP_SENDING arrived, it isn't stuck honoring that commitment -- it
can follow up with a RESET_STREAM (or a RESET_STREAM_AT with Reliable Size
zero) to reduce the commitment to nothing, per Section 5.2's "MUST NOT
increase" rule, which only constrains increases. That's presumably why
SHOULD rather than MUST is sufficient here: there's always a path back to
the RESET_STREAM-equivalent behavior Ketan and Éric are asking about. Making
that connection explicit in 5.4 -- even just a cross-reference to 5.2 --
would resolve the tension both of them flagged without changing the
normative language.

---

Section 4:

158 >    RESET_STREAM_AT Frame {
159 >      Type (i) = 0x24,
160 >      Stream ID (i),
161 >      Application Protocol Error Code (i),
162 >      Final Size (i),
163 >      Reliable Size (i),
164 >    }

On the list, Martin Thomson pushed back on Éric's ask for a normative
reference here, on the grounds that the notation is illustrative and RFC
9000 is already a normative reference. That's true as far as it goes, but
RFC 9000 Section 1.3 is where this "custom format" is actually defined -- it
isn't defined anywhere else, and the draft never says so. Éric's simplest
fix from the thread (a sentence like "using the notation of Section 1.3 of
RFC 9000") costs nothing and points the reader at the right place without
adding a new reference.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool), so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 5:

208 >    A sender that wants to reset a stream but also deliver some bytes to
209 >    the receiver sends a RESET_STREAM_AT frame with the Reliable Size
210 >    field specifying the amount of data to be delivered.

212 >    When using a RESET_STREAM_AT frame, the initiator MUST guarantee
213 >    reliable delivery of stream data of at least Reliable Size bytes.

Section 5 opens by calling the party that sends RESET_STREAM_AT the
"sender," then switches to "initiator" for the normative MUST two sentences
later, and Section 5.2 uses "initiator" throughout. Section 4 and the frame
field description use "sender." Picking one term and using it consistently
would help implementors grep the document for the relevant role.

[Ballot comment]
Thanks to the authors and the WG for their work on this document.

Please take this as someone that is not an expert in this area and, therefore,
feel free to just tell me that I am wrong and/or oversimplifying :-)

Please find below a couple of comments on this document inline in the idnits
output of v10. Lookout for the  tag at the end to ensure you are seeing
the full review.

1) Mix up of things that perhaps needs clarification

265   Reordering of packets might lead to a RESET_STREAM_AT frame with a
266   higher Reliable Size being received after a RESET_STREAM_AT frame
267   with a lower Reliable Size.  The receiver MUST ignore any
268   RESET_STREAM_AT frame that increases the Reliable Size.
270   When sending another RESET_STREAM_AT, RESET_STREAM or STREAM frame
271   carrying a FIN bit for the same stream, the initiator MUST NOT change
272   the Application Error Code or the Final Size.  If the receiver
273   detects a change in those fields, it MUST close the connection with a
274   connection error of type STREAM_STATE_ERROR or FINAL_SIZE_ERROR,
275   respectively.

Two closely related points in this text would benefit from one
clarification. First, “ignore any RESET_STREAM_AT frame” can be read as ignoring
the whole frame, which would conflict with the following requirement to detect
changes in its other fields. I think the intent is only to ignore the attempted
increase in Reliable Size. Second, the following sentence grammatically applies
Application Error Code consistency to a STREAM frame carrying FIN, even though
(I believe) a STREAM frame has no Application Error Code; only Final Size
applies to that frame type.

How about the following?

SUGGEST
Reordering of packets might lead to a RESET_STREAM_AT frame with a higher
Reliable Size being received after a RESET_STREAM_AT frame with a lower
Reliable Size. The receiver MUST ignore the increase in Reliable Size and
continue to use the smallest Reliable Size received. The other fields of the
RESET_STREAM_AT frame remain subject to the consistency requirements below.

When sending another RESET_STREAM_AT or RESET_STREAM frame for the same stream,
the initiator MUST NOT change the Application Error Code or the Final Size.
When sending a STREAM frame carrying the FIN bit for the same stream, the
initiator MUST NOT change the Final Size. If the receiver detects a change in
the Application Error Code, it MUST close the connection with a connection
error of type STREAM_STATE_ERROR. If the receiver detects a change in the
Final Size, it MUST close the connection with a connection error of type
FINAL_SIZE_ERROR.

2) Is that a SHOULD or indeed a MUST ?

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

The above reliable-delivery requirement needs to reconcile with the the text
below:

317   An endpoint that receives a STOP_SENDING frame is required to send a
318   RESET_STREAM frame in some stream states, as described in Section 3.5
319   of [RFC9000].  While it is permissible to send a RESET_STREAM_AT
320   frame in this case, endpoints SHOULD send a RESET_STREAM frame, since
321   the peer has already indicated that it does not intend to process any
322   further data.

I support Éric Vyncke’s comment asking why the SHOULD in Section 5.4 is
not a MUST. RFC 9000 Section 3.5 says that after STOP_SENDING, STREAM frames
“can be discarded upon receipt”, while Section 5 of this draft requires a
sender using RESET_STREAM_AT to guarantee delivery through the Reliable Size.
A positive Reliable Size after STOP_SENDING therefore appears to create a case
where the draft requires delivery of data that RFC 9000 permits the receiver to
discard. Please correct me if I am missing a QUIC rule that reconciles these
requirements.

Suggestion: change the Section 5.4 SHOULD to a MUST, as Éric suggests. There may
be other ways (perhaps restricting Reliable Size to 0) to reconcile with RFC 9000?

[Ballot comment]
Thanks for the work done in this document. While QUIC is not within my area of expertise, I have only two non-blocking COMMENT, but addressing them will probably help implementers.

### Section 4

Please add a normative reference for the syntax/notation used in Figure 1.

### Section 5.4

Why not a "MUST" in `endpoints SHOULD send a RESET_STREAM frame` ? The use of BCP14 terms is specific for interoperability, so, add guidance to implementers when the "SHOULD" can be bypassed if this is not a "MUST"

Regards,

-éric

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-quic-reliable-stream-reset-09. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the QUIC Transport Parameter in the QUIC registry group located at:

https://www.iana.org/assignments/quic/

A single new registration will be made as follows:

Value: 0x1d
Parameter Name: reset_stream_at
Status: Permanent (upon approval of [ RFC-to-be ] )
Specification: [ RFC-to-be ]
Date: [ TBD-at-Registration ]
Change Controller: IETF (iesg@ietf.org)
Contact: QUIC Working Group (quic@ietf.org)
Notes:

Second, in the QUIC Frame Types registry also in QUIC registry group located at:

https://www.iana.org/assignments/quic/

A single new registration will be made as follows:

Value: 0x24
Frame Type Name: RESET_STREAM_AT
Status: Permanent (upon approval of [ RFC-to-be ] )
Specification: [ RFC-to-be ]
Date: [ TBD-at-Registration ]
Change Controller: IETF (iesg@ietf.org)
Contact: QUIC Working Group (quic@ietf.org)
Notes:

We understand that these two actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2026-08-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-quic-reliable-stream-reset@ietf.org, gorry@erg.abdn.ac.uk, lucas@lucaspardue.com, quic-chairs@ietf.org, quic@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (QUIC Stream Resets with Partial Delivery) to Proposed Standard


The IESG has received a request from the QUIC WG (quic) to consider the
following document: - 'QUIC Stream Resets with Partial Delivery'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-08-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  QUIC defines a RESET_STREAM frame to abort sending on a stream.  When
  a sender resets a stream, it also stops retransmitting STREAM frames
  for this stream in the event of packet loss.  On the receiving side,
  there is no guarantee that any data sent on that stream is delivered.

  This document defines a new QUIC frame, the RESET_STREAM_AT frame,
  that allows resetting a stream, while guaranteeing delivery of stream
  data up to a certain byte offset.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/



No IPR declarations have been submitted directly on this I-D.

Marten (Editor) confirmed he was aware of the following implementations:
  - Chrome
  - Firefox
  - Safari
  - quic-go
  - mvfst
  - quicly

The new revision seems ready to go, when this note is discussed:

The document targets PS status, but there is no stated implementation experience, which is often expected - a short list of implementation work and/or interop testing would be useful to justify publication as a PS.

Thank you for submitting this I-D for publication. This is my AD Review, after a revised I-D is submitted, I plan to pass this to IETF-LC.

    I have a few editorial suggestions, see a separate PR.
    The clause 'SHOULD remain vigilant' is understood, but could say more about how and specifically the action to be taken is not specified. Could a sentence be added to explain what ought to happen in this case?
    There is a section marked; "Acknowledgments" with the contents: "TODO acknowledge'. Please finish this text or remove this section.

The document could include a short "Operational Considerations" Section, e.g., to explain in a sentence how an implementation handles the reception of a reset_stream_at (0x1d) transport parameter, when this is not supported, perhaps by simply referring to standard QUIC processing.

Finally, the document targets PS status, but there is no stated implementation experience, which is often expected - a short list of implementation work and/or interop testing would be useful to justify publication as a PS. This section can be removed after IESG review by the RFC-Ed.

# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The working group reached broad agreement. The work on this draft was largely
driven by the needs, inputs and feedback of the WebTransport WG members that
attended QUIC WG sessions and/or participated via GitHub.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Yes, there were several independent implementations of the protocol extension,  driven
primarily by WebTransport use cases (including, but not limited to, Media over
QUIC). These have not been captured formally. Interoperability has been reported
in an adhoc nature, but has been deemed accurate and true.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes. The WebTransport WG requested this extension and have actively
participated in the design, reviews, and implementation.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document defines a new QUIC Transport Parameter (reset_stream_at) and a new
QUIC Frame Type (RESET_STREAM_AT), which require standard IANA allocations under
the QUIC registries and Expert Review per RFC 8126. Martin Thomson, one of the
designated experts for the relevant registries was actively engaged in the codepoint
selection of draft -08 in accordance with the registration policy.


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A.


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A.


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

N/A.

11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested publication type is Proposed Standard. This is the proper type
because the document specifies a normative wire-level extension to the core QUIC
transport protocol (RFC 9000), defining new frame types and modifying how
transport-level stream resets behave

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The authors have been reminded. There have been no IPR disclosures filed against
this document.

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No true positive nits.

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

The references are of the correct type.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A

17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No.

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

I have reviewed the section inline with the rules and process guidance for QUIC
extensions described in RFC 9000. The IANA considerations is complete and in
accordance with expectations.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A.

Shepherd disclaimer: This report was generated with the assistance of AI tooling:
NotebookLM trained on the the document, together with QUIC WG public resources.

# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The working group reached broad agreement. The work on this draft was largely
driven by the needs, inputs and feedback of the WebTransport WG members that
attended QUIC WG sessions and/or participated via GitHub.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Yes there several independent implementations of the protocol extension,  driven
primarily by WebTransport use cases (including but not limitied to Media over
QUIC). These have not been captured formally. Interoperability hs been reported
in an adhoc nature but has been deemed accurate and true.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes. The WebTransport WG requested this extension and have actively
participated in the design, reviews, and implementation.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document defines a new QUIC Transport Parameter (reset_stream_at) and a new
QUIC Frame Type (RESET_STREAM_AT), which require standard IANA allocations under
the QUIC registries and Expert Review per RFC 8126. Martin Thomson, one of the
designted experts for the relevant registries was actively engaged in codepoint
selection of draft -08 in accordance with the registration policy


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

N/A


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested publication type is Proposed Standard. This is the proper type
because the document specifies a normative wire-level extension to the core QUIC
transport protocol (RFC 9000), defining new frame types and modifying how
transport-level stream resets behave


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The authors have been reminded. There have been no IPR disclosures filed against
this document


13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No true positive nits.

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

The references are of the correct type.


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

I have reviewed the section inline with the rules and process guidance for QUIC
extensions described in RFC 9000. The IANA considerations is complete and in
accordance with expectations


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

Shepherd disclaimer: This report was generated with the assistance of AI tooling:
NotebookLM trained on the the document, together with QUIC WG public resources

# Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

The working group reached broad agreement. The work on this draft was largely
driven by the needs, inputs and feedback of the WebTransport WG members that
attended QUIC WG sessions and/or participated via GitHub.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No


4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?

Yes there several independent implementations of the protocol extension,  driven
primarily by WebTransport use cases (including but not limitied to Media over
QUIC). These have not been captured formally. Interoperability hs been reported
in an adhoc nature but has been deemed accurate and true.

# Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

Yes. The WebTransport WG requested this extension and have actively
participated in the design, reviews, and implementation.


6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document defines a new QUIC Transport Parameter (reset_stream_at) and a new
QUIC Frame Type (RESET_STREAM_AT), which require standard IANA allocations under
the QUIC registries and Expert Review per RFC 8126. Martin Thomson, one of the
designted experts for the relevant registries was actively engaged in codepoint
selection of draft -08 in accordance with the registration policy


7. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?

N/A


8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A


# Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.


10. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

N/A


11. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

The requested publication type is Proposed Standard. This is the proper type
because the document specifies a normative wire-level extension to the core QUIC
transport protocol (RFC 9000), defining new frame types and modifying how
transport-level stream resets behave


12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

The authors have been reminded. There have been no IPR disclosures filed against
this document


13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes

14. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

No true positive nits.

15. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.

The references are of the correct type.


16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

N/A


17. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.

No


18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

No


19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No


20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).

I have reviewed the section inline with the rules and process guidance for QUIC
extensions described in RFC 9000. The IANA considerations is complete and in
accordance with expectations


21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

Shepherd disclaimer: This report was generated with the assistance of AI tooling:
NotebookLM trained on the the document, together with QUIC WG public resources