Re: [Last-Call] Opsdir last call review of draft-ietf-quic-bit-grease-03

[Martin Thomson <[e-mail]>]

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.