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 _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
