David: Hi!
Hmmm... Thanks for pointing at the thread, even if I wouldn't call it "a discussion". I believe there is obvious language in §4 that modifies what an rfc9000 endpoint is expected to do, which to me is a sufficient condition to tag the document as updating rfc9000. However, the thread in the WG is correct in pointing out that there is no consistent definition for the tag. :-( I won't object more. Thanks! Alvaro. On October 24, 2022 at 7:00:02 PM, David Schinazi ([email protected]) wrote: Hi Alvaro, and thank you for your review. At the request of our responsible AD, the QUIC WG had an official discussion [1] about whether to update 8999 and/or 9000. The consensus was that this document updates 8999 but not 9000. David [1] https://mailarchive.ietf.org/arch/msg/quic/wRnoeh8tQmX5yBGtBGtbjqjFM18/ On Mon, Oct 24, 2022 at 2:45 PM Alvaro Retana via Datatracker < [email protected]> wrote: > Alvaro Retana has entered the following ballot position for > draft-ietf-quic-version-negotiation-12: No Objection > > 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-version-negotiation/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This document updates rfc8999, which points at rfc9000 "for a more thorough > description of how an endpoint that supports QUIC version 1 generates and > consumes a Version Negotiation packet". > > There is also text in §4 that seems to modify how a QUIC version 1 endpoint > behaves. > > Should rfc9000 also be updated? > > > >
