Hey Martin, all, I think you're correct in pointing out that the term unpredictable is a term of art within the context of QUIC that this draft operates. However, I find also in RFC 9000 that supporting text for various unpredictable elements usually provides a justification or some guidance. Arguably, the justification _is_ the entire document, but in the context of other grease-like mechanisms in the IETF, it seems a single bit might need a more holistic approach beyond just the value itself.
The closest parallel, for me, is the spin bit text that goes so far as saying > [if your TPs let you randomize] It is RECOMMENDED that endpoints set the spin bit to a random value either chosen independently for each packet or chosen independently for each connection ID. Stating explicitly that the unpredictability can be per connection or per packet might be all that's need to make the intent crystal clear, while leaving the actual decisions to implementations. Cheers Lucas On Fri, Jul 1, 2022 at 12:45 AM Martin Thomson <[email protected]> wrote: > 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. >
