Re: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS)

[Martin Thomson <[e-mail]>]

I'm surprised at this question.  We used the word "unpredictable" in RFC 9000 a few times, with exactly this meaning and had no issue.  See for example:

> When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value.

Or

> To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing an unpredictable payload on the path to be validated.

Or

Stateless Reset {
  Fixed Bits (2) = 1,
  Unpredictable Bits (38..),
  Stateless Reset Token (128),
}

As you say, a bit can assume one of two values, 0 or 1.  Setting a bit to a predictable value would mean choosing 0 or 1 in a way that someone might be able to guess the next value.  Always 1, always 0, or alternating 0 and 1 are examples of predictable methods of selecting a value.  Setting a bit to an unpredictable value would mean setting it to either 0 or 1 such that someone else is unlikely to correctly guess the next value.  A random draw is unpredictable, but there are other methods that would also be unpredictable.

On Thu, Jun 30, 2022, at 22:52, Andrew Alston via Datatracker wrote:
> Andrew Alston has entered the following ballot position for
> draft-ietf-quic-bit-grease-04: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-quic-bit-grease/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for the work on this document,
>
> Hopefully this discuss will be relatively easy to resolve - and may result from
> a lack of understanding - but -
>
>    Endpoints that receive the grease_quic_bit transport parameter from a
>    peer SHOULD set the QUIC Bit to an unpredictable value unless another
>    extension assigns specific meaning to the value of the bit.
>
> Now, this is in reference to a bit - which can only be 0 or 1 - and the
> document further goes on to clarify certain situations where this bit should be
> set or unset - so I am not at all sure what this paragraph really means and
> hoping this can be clarified because I'm not sure how this will be interpreted
> on implementation.