Mike Bishop's Yes on draft-ietf-quic-reliable-stream-reset-10: (with COMMENT)

[Mike Bishop via Datatracker <[e-mail]>]

Mike Bishop has entered the following ballot position for
draft-ietf-quic-reliable-stream-reset-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-reliable-stream-reset/



----------------------------------------------------------------------
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