Thanks for the feedback Scott. I've added a few changes to https://github.com/quicwg/quic-bit-grease/pull/26 which will be on top of the ones in https://github.com/quicwg/quic-bit-grease/pull/25 (which was in response to Russ). On Fri, May 20, 2022, at 10:21, Scott Bradner via Datatracker wrote: > Since this document proposes a change in the way QUIC packets are created and > processed it would seem logical for this document be listed as updating RFC > 9000. If this is the case then the document header and introduction need to be > changed. I don't think that this is necessary. This fits within QUIC's extension model in that you don't need to read and understand this document in order to correctly implement RFC 9000. I know that the definition of "updates" is contested, but that's the definition I've applied here. > Section 3 > > Current: > “The grease_quic_bit transport parameter (0x2ab2) can be sent by both > client and server. The transport parameter is sent with an empty > value; an endpoint that understands this transport parameter MUST > treat receipt of a non-empty value as a connection error of type > TRANSPORT_PARAMETER_ERROR.” > > I find the above wording confusing – “ receipt of a non-empty value” of what? > (the “grease_quic_bit” or something else? I don't see an issue here. Is it that this is missing the context that transport parameters have values? That's pretty elementary stuff that I don't think needs to be contextualized. > “ Advertising the grease_quic_bit transport parameter indicates that > packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. > The QUIC Bit is defined as the second-to-most significant bit of the > first byte of QUIC packets (that is, the value 0x40). > > do you mean that the sender can set the bit to either a 0 or a 1 at its choice? > – if so, maybe it would be clearer to just say that Fixed with the changes I made for Russ' review. > “A server MUST respect the value it previously provided for the > grease_quic_bit transport parameter if it accepts 0-RTT. A client > MAY forget the value. In all other cases, only the presence or > absence of the transport parameter in the current handshake is used > to determine what values can be sent in the QUIC Bit.” > > 1/ it would be good to have a pointer to the RFC & section where “0-RTT” is > defined 2/ what does “respect the value” mean – it would be good to spell it out Conveniently, this paragraph is redundant with one in Section 3.1 - one that is clearer - so I will remove it. > Section 3.1 > First paragraph seems redundant with the 2nd paragraph of section 3 The first sentence, yes. I removed the first sentence, tweaked the second to compensate. > In general I find section 3.1 quite confusing – I suggest that using “set” and > ”clear” are more confusing that saying “set to 0” or “set to 1” Fair. Changed. > Since the stated purpose of this update is “to safeguard future use of this > bit” would it be a good idea to suggest that absent any reason not to senders > should randomly use a 0 or a 1 whenever the session startup says its OK to not > always send a 1 – in this way the development of intermediaries that assume a > particular value will be discouraged Yep, that's the sentence I'm suggested be kept from the paragraph you identified as redundant in Section 3.1. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
