Draft: draft-ietf-quic-version-negotiation

Commentary: 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 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 did n'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 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 do n't think we should . And I do n'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 do n'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 ( ) should explicitly ping the WG about it now . 
 I agree with Lucas and  . " 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 that this does n't sound like an update to RFC 9000 . The only reference to QUICv1 ( ) does n'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 do n'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 ) . Whether we do add an updates tag is borderline . Adding a tag does n'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 and the interop runner that nudge people to " Do the best thing " . An updates tag does n'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 does n'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
QUIC does not provide a complete version negotiation mechanism but
instead only provides a way for the server to indicate that the
version the client chose is unacceptable.  This document describes a
version negotiation mechanism that allows a client and server to
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
extra round trip.
QUIC does not provide a complete version negotiation mechanism but
instead only provides a way for the server to indicate that the
version the client chose is unacceptable.  This document describes a
version negotiation mechanism that allows a client and server to
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
extra round trip.  This document updates RFC 8999.