Hello, There was only meta discussion during this call, so we will consider that a consensus on the previous proposal.
Thanks, QUIC Chairs On Thu, Apr 22, 2021, 11:34 AM Matt Joras <[email protected]> wrote: > Hello all, > > As noted in previous mail, the draft minutes are available here[1]. A > high level summary of the meeting, as well as next steps, follows. > > About 25 people attended and David kicked us off with a short update > as editor. Some of the attendees spoke briefly to the ideas that they > had shared to the list since the last meeting. Watson presented the > sketch of an alternative mechanism to achieve version negotiation to > the existing draft[2]. This design was very interesting and provoked > much discussion. There was, after a time, agreement that such a scheme > would likely require a change to the QUIC invariants. While not > strictly impossible there doesn't seem to be much motivation in this > direction or for making a change of that magnitude at this stage. > > Much of the discussion focused on the notion of "compatible" versus > "incompatible" version negotiation and whether or not we require just > one, both, or neither. For definitions of these, please read sections > 2 and 3 of the draft[2]. > > Regarding incompatible version negotiation, several people made > arguments that incompatible version negotiation is not needed in > practice today and we are unlikely to need it in the future. As the > main complexity of the current draft is mostly from incompatible > version negotiation, there is potentially a benefit from removing it > as a requirement. > > On the other hand, many people felt strongly that incompatible version > negotiation is definitely a requirement and they can foresee use cases > for it. No one present strongly opposed a design which includes > incompatible version negotiation. > > Similarly, some made the argument that compatible version negotiation > is also not a requirement. Nominally the same functionality is > achievable with a single QUIC version, transport parameters, and > extensions. There were many people who believe there is still value in > compatible version negotiation. No one present strongly opposed a > design which includes compatible version negotiation. There was a > general desire for clarity around when compatible versions should be > utilized versus simply specifying extensions. > > To help get a sense of the room as the session was coming to an end, > the chairs took a show of hands for version negotiation requirement > options. > > The chairs observed emerging consensus for supporting both compatible > and incompatible version negotiation. We also observed little interest > in alternatives to the design in the current draft[2]. Therefore the > proposal is to move ahead with the current draft and incorporate some > design improvements. Please comment if you disagree with this > proposal, the consensus call will last for one week until Thursday, > April 29th. > > Thanks, > QUIC Chairs > Lars, Lucas, Matt > > [1] > https://github.com/quicwg/wg-materials/blob/main/interim-21-04/minutes.md > [2] https://tools.ietf.org/html/draft-ietf-quic-version-negotiation-03 >
