I'm not sure what the value here is. CDN deployments will base which QUIC versions they support on what their customers are asking for, and client deployments will base their versions on what servers support. Neither will make decisions based on what IETF recommends.
David On Mon, Jan 31, 2022 at 11:42 AM Spencer Dawkins at IETF < [email protected]> wrote: > > > On Mon, Jan 31, 2022 at 12:32 PM Lucas Pardue <[email protected]> > wrote: > >> Hey, >> >> Responding to the theme of this thread, as an individual. >> >> I think it's a laudable goal to have scheduled releases and up-front >> support cycles. However, I fear what that requires is switching the group >> from a QUIC standards development and maintenance transport WG into a >> software and hardware delivery and operations group. Yes, if there are >> problems found in QUIC protocol versions or extensions, we should seek to >> fix them. However, I think it is a major challenge to attempt coordination >> across the diverse set of implementations and platforms where QUIC already >> runs. It also seems the antithesis of our goal in building an >> ossification-resistant protocol that encourages evolution and >> experimentation. >> >> Instead, as an individual, I would rather the WG continue to build robust >> versioning capabilities that allow the community to drive their own >> evolution. I trust the WG will, if required, make judgement calls on the >> right time and circumstances to deprecate IETF versions of QUIC. I would >> not be optimistic that we can drive deployments to change their supported >> versions just because we said so. >> > > I'm sympathetic to this point of view (and this is one of the reasons I > was thinking that this might not be possible in an all-volunteer > organization in my previous comment), but I thought it was useful to ask, > because if anything like an expiration date was possible to establish, I'm > sure that talking about that sooner rather than later would make > establishing an expiration date much easier. > > I didn't say this out loud, but I think my suggestion makes much more > sense if something like Bill's suggestion about telling people to expect a > new release each year, on some date, even if it's just bumping the version > number and salts, was also happening. If the notice of a new QUIC version > number included something like "you can expect to use this protocol version > for the next three years without worrying about obsolescence", or whatever > the right thing to say is. > > Do The Right Thing, of course! > > Best, > > Spencer > > >> Cheers, >> Lucas >> >
