Original text:
select a mutually supported version.  Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an <del> extra round trip. </del>  1.

Reviewer comments:
This PR just updates the tag. Which I think is not adequate. The abstract should clearly mention that it is updating 8999 and the respective sections should say what it is updating.
The whole document updates Section 6 of RFC 8999. I think it's sufficient to state that in a stand-alone sentence in the abstract and introduction.
As per the IETF tradition, I've modified the abstract to mention that this document updates RFC 8999. There is no requirement to update the introduction or the rest of the text.
Please merge and update the datatracker version.
I would like to have a discussion to determine whether this specification should update RFC9000 or not. This version negotiation draft adds new functionality on top of RFC9000 using the version negotiation packet from RFC8999. The update tag might be seen as useful to let other aware of the added mechanism for version negotiation, also because it actually changes how section 6 of RFC9000 deals with QUIC versions, which mentions potential future work regarding the negotiation. On the other hand, this new mechanism is not really a must to implement to make things works for RFC9000and both mechanism can co-exists, hence falls into QUIC extension categories. It seems all about how we want the future QUIC versions to get deployed. I have checked with WG chairs and authors that we didn't really discussed this in the working group. I think having a discussion now would be useful to know where the WG stands on this and have an response ready for potential questions (from reviews) along the path of publication.
Speaking in capacity as individual and chair: I still find the commentary on use of the Updates tags in URL compelling. If I dare to summarise, the Updates tag is used inconsistently across the IETF. Any use of it is ambiguous and open to interpretation. I'd encourage people to familiarise themselves with some of the background and wider discussion, in order to avoid playing all of it out here. Trying to document or describe how the QUIC WG treats use of Updates is probably a futile activity, since its unlikely to be found by the target audience. Adding an Updates tag risks confusing people just as much as it might help some people. Absent a strong reason to provide an Updates tag, I don't think we should. And I don't class subjective opinions as a strong reason on their own.
I largely agree with Lucas, but I think that the change in behaviour with respect to Version Negotiation is significant enough to warrant an Updates tag in this case. I generally subscribe to the view that Amends is the only useful application of Updates, but this clearly fits into that interpretation. (It is also an instance of Extends, but I don't care about that.) I can see how you might argue that this new document only applies to people implementing versions of QUIC other than version 1, but that seems too much like sophistry. On balance though, given the importance of this feature, I think that a strong pointer is useful in this case.
I do not care whether this has an Update tag or not, because it has no impact whatsoever on implementations. I'll follow the WG consensus on this.
yes, getting the WG consensus is the target here. May be the chairs (NAME NAME ) should explicitly ping the WG about it now.
I agree with Lucas and Martin. "RFC X updates RFC Y" has been used with a lot of different meanings, such as: RFC X defines version N+1 of the EXAMPLE protocol, whose version N is defined in RFC Y RFC X reflects IETF consensus to change some parts of the specification of the EXAMPLE protocol defined in RFC Y RFC X specifies extensions to the EXAMPLE protocol using the extension mechanisms defined in RFC Y In my mid, the first case should be noted as "obsoletes", as in RFC 8446 (TPS 1.3) obsoletes RFC 5246 (TLS 1.2). The second case is properly noted as "updates". The third case does neither update not obsolete. This is certainly the interpretation that the WG has used so far: neither RFC 9287, greasing the Q bit, nor RFC9221, datagram frames, are marked as updating RFC 9000. The compatible version negotiation should also not be stated as updating RFC 9000. In any case, if the compatible version negotiation updates something, it is not RFC 9000 but RFC 8999, the QUIC invariants, which defines the basic version negotiation.
Agreed with NAME that this doesn't sound like an update to RFC 9000. The only reference to QUICv1 () doesn't require any updates to implementations of RFC 9000, just handling for newer versions. I could see an argument for marking it as an Update to RFC 8999, but I'm ambivalent about that.
I vote yes for the update: we want implementors of RFC 9000 to be aware of this later doc, even if they don't strictly need to be, and it seems to be within the scope of existing uses.
chair hat off: I am coming around to the idea that this doc should not update RFC 9000 and might update RFC 8999 (specifically because of URL). Whether we do add an updates tag is borderline. Adding a tag doesn't hurt either this draft or 8999, the confusion risk I mentioned earlier does not seem high after hearing others views. It might improve discoverability but I'm skeptical of the efficacy discovery via tags in practice; a link with no context seems like a pretty lame hint. I'd rather us have more detailed and expressive ways to communicate with implementers the "why" and broader context about things that they should consider - for example, adding resources on URL and the interop runner that nudge people to "Do the best thing". An updates tag doesn't prevent that though, so all good. Finally, adding an updates tag here risks us having to ask the question every time. I'm encouraged by the discussion here that we can logically reason why something like Datagram extension doesn't while version negotiation does. In summary, as an individual, I'm seeing what appears to be ambivalence to RFC 8999 but no objections
QUIC WG chairs have to update 8999 but not 9000. I've written this up as PR .
Let's merge the PR and cut a new release for Zahed to progress Hello all, To summarize the outcome, while the usage of the "Updates" tag across the IETF is generally not very consistent, the chairs believe that there is consensus for adding the "Updates" tag for RFC 8999, but not for RFC 9000, as the implications and precedent-setting of the latter are not as clear. Best, Matt Joras On behalf of the QUIC WG Chairs Lucas Pardue wrote:

Revised text:
select a mutually supported version.  Optionally, if the client's chosen version and the negotiated version share a compatible first flight format, the negotiation can take place without incurring an  <ins> extra round trip.  This document updates RFC 8999. </ins> 1.