Reviewer: Scott Bradner
Review result: Has Issues
This is an OPS-DIR review of Greasing the QUIC Bit (draft-ietf-quic-bit-grease).
This document proposes a change in the way that the second-to-most significant
bit in QUIC packets is viewed.
I agree with the observations that Russ made in his review of this document
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.
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?
“ 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
“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
Section 3.1
First paragraph seems redundant with the 2nd paragraph of section 3
Seems to me that the key concept is not that the sender can set the value to
“0” but that the sender can set the value to anything it wants to (i.e. “0” or
“1”)
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”
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
