[Gen-art] Re: draft-ietf-quic-reliable-stream-reset-09 ietf last call Genart review

[Christer Holmberg <[e-mail]>]

Hi Marten,

Thanks for your reply. Please see inline. I have removed the issues where I am ok with the way they have been addressed and have no further comments.

---

>> "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."
> 
> This is unchanged from RFC 9000: Retransmitting data after RESET_STREAM is
> not forbidden, it's just pointless and wasteful.

I was thinking that there would be no data sent to begin with (with or without retransmission), as the sender using RESET_STREAM_AT has explicitly stated how much it will send reliably.

But, as the sender is allowed to send data even after that, I am ok with the "SHOULD NOT be transmitted".
 
---

>> 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.
>> 
> RESET_STREAM_AT with Reliable Size = 0 is equivalent to RESET_STREAM, as
> explained in section 5. Nothing stops you from sending a RESET_STREAM_AT,
> you're just using more bytes on the wire to encode the same thing.

Agree. I was just wondering about the strong preference (SHOULD) for RESET_STREAM over RESET_STREAM_AT in Section 5.4.

---

> >  Q: Please add a reference to RFC 9001 for 0-RTT.
> 
> The requirement to remember transport parameters comes from section 7.4.1
> of RFC 9000. RFC 9000 mentions 0-RTT 85 (!) times. I don't think referencing
> RFC 9001 provides much value, especially since we're not changing the QUIC
> derivation paths.

My comment is not related specifically to transport parameters, but more general to have a reference for 0-RTT.

But, if the community thinks a reference is not needed I will not argue against it.

---
 
>> 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?
> 
> https://github.com/quicwg/reliable-stream-reset/pull/91
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fquicwg%2Freliable-stream-
> reset%2Fpull%2F91&data=05%7C02%7Cchrister.holmberg%40ericsson.com
> %7C880bdb21f9b0401e9bb208def1f22da2%7C92e84cebfbfd47abbe52080
> c6b87953f%7C0%7C0%7C639214219615026144%7CUnknown%7CTWFpb
> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z
> MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w1qAVd
> ZQy%2BcpOFAGJLtL9cMTca8bCjXVzcsOK3HuUQA%3D&reserved=0>

Looks good! :)

Thanks!

Regards,

Christer