Hi Martin, I prefer the more complete text – just makes it easier for people to parse during implementation in my view.
So if you’re ok with that I will go ahead and clear my discuss once that’s pushed Thanks Andrew From: Martin Thomson <[email protected]> Sent: Tuesday, July 5, 2022 2:21 AM To: Andrew Alston - IETF <[email protected]>; Lucas Pardue <[email protected]> Cc: Andrew Alston - IETF <[email protected]>; The IESG <[email protected]>; [email protected]; WG Chairs <[email protected]>; QUIC WG <[email protected]> Subject: Re: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS) I've prepared two versions: Something like what Lucas said: https://github.com/quicwg/quic-bit-grease/pull/30<https://github.com/quicwg/quic-bit-grease/pull/30> Minimal: https://github.com/quicwg/quic-bit-grease/pull/29<https://github.com/quicwg/quic-bit-grease/pull/29> I'll leave this to those that had more trouble with the language to let me know what they prefer. On Mon, Jul 4, 2022, at 19:07, Andrew Alston - IETF wrote: > Sorry for the delayed response, > > I think Lucas’s statement is fair here – so if we can agree on t hat – > I’d be ok with clearing my discuss on this one > > Thanks > > Andrew > > > *From:* Lucas Pardue > <[email protected]<mailto:[email protected]>> > *Sent:* Friday, July 1, 2022 3:58 AM > *To:* Martin Thomson <[email protected]<mailto:[email protected]>> > *Cc:* Andrew Alston - IETF > <[email protected]<mailto:[email protected]>>; The IESG > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; > WG Chairs > <[email protected]<mailto:[email protected]>>; QUIC WG > <[email protected]<mailto:[email protected]>> > *Subject:* Re: Andrew Alston's Discuss on > draft-ietf-quic-bit-grease-04: (with DISCUSS) > > 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]<mailto:[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/<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/<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.
