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? > > > >
