Opsdir last call review of draft-ietf-quic-bit-grease-03

[Scott Bradner via Datatracker <[e-mail]>]

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