Pretty clear to me overall.
Optional Editorial:
"Version compatibility is not bijective"
could also be stated as:
"Version compatibility is not version equivalence"
One of the things that crosses my mind when reading through is that we don't
address version switching, i.e. performing a version 'negotiation' while the
previous connection's version is in use.
In particular, the draft doesn't describe if this is allowed or disallowed, and
it isn't clear from other documents that version negotiation must happen only
at the start of the connection-- there is not currently a 'must not' send a VN
after connection established.
... probably good to clean that up one way or another.
-=R
On 2/8/21, 9:43 PM, "QUIC on behalf of Martin Thomson" <[email protected]
on behalf of [email protected]> wrote:
Not an enthusiast, but I did read the draft.
Thanks for putting this together David. I think that this is a lot clearer
than previous versions about how it is structured. I have opened a few issues
and plan to open a few more. There are some big open questions there
unfortunately, but I am hopeful we can get through those.
On Fri, Feb 5, 2021, at 11:44, David Schinazi wrote:
> Hi QUIC enthusiasts,
>
> As you can see below, EKR and I have submitted an update to the version
> negotiation draft.
> This is a complete rewrite of the document, aiming at making the
> concepts clearer. Please let
> us know what you think and file issues, we'd love to get the discussion
> started before IETF 110.
>
> Thanks,
> David
>
> On Thu, Feb 4, 2021 at 4:35 PM <[email protected]> wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> > This draft is a work item of the QUIC WG of the IETF.
> >
> > Title : Compatible Version Negotiation for QUIC
> > Authors : David Schinazi
> > Eric Rescorla
> > Filename : draft-ietf-quic-version-negotiation-03.txt
> > Pages : 12
> > Date : 2021-02-04
> >
> > Abstract:
> > 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 offered is unacceptable. This document describes
> > a version negotiation mechanism that allows a client and server to
> > select a mutually supported version. Optionally, if the original and
> > negotiated version share a compatible first flight format, the
> > negotiation can take place without incurring an extra round trip.
> >
> > Discussion of this work is encouraged to happen on the QUIC IETF
> > mailing list [email protected] (mailto:[email protected]) or on the GitHub
> > repository which contains the draft: https://github.com/quicwg/
> > version-negotiation/ (https://github.com/quicwg/version-
> > negotiation/).
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-quic-version-negotiation/
> >
> > There is also an HTML version available at:
> >
https://www.ietf.org/archive/id/draft-ietf-quic-version-negotiation-03.html
> >
> > A diff from the previous version is available at:
> >
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-version-negotiation-03
> >
> >
> > Please note that it may take a couple of minutes from the time of
submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> >
