* 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.
Like David, I don’t s
Hey,
Still speaking as an invidiual:
On Mon, 31 Jan 2022, 20:24 Bill Gage, wrote:
> Hello Lucas and Spencer -
>
> Just to clarify, when I said "there could be a new rolling release of the
> QUIC spec at least once a year on March 21 that, as a minimum, greases the
> codepoints and salts", I did
Hello Lucas and Spencer -
Just to clarify, when I said "there could be a new rolling release of the QUIC
spec at least once a year on March 21 that, as a minimum, greases the
codepoints and salts", I didn't mean to imply a change to the existing WG mode
of operation - RFCs would continue to be
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
On Mon, Jan 31, 2022 at 12:32 PM Lucas Pardue
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 de
On 1/31/2022 10:32 AM, Lucas Pardue wrote:
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 deprec
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
FWIW, I REALLY want to encourage the working group to consider a formal
statement of how long QUIC versions would be "supported", as in "if someone
finds a serious problem, we'll work to fix it", as Bill proposed below.
That might not be the right thing to do, and might even be impossible to
commi
Regular version releases are the most obvious way to grease the version.
However, before we get around to v3 I'd like to ship Version Aliasing
instead:
https://datatracker.ietf.org/doc/draft-duke-quic-version-aliasing/
It's a more comprehensive solution that carries security and privacy
benefits
How about using the same strategy as planned OS releases - e.g. there will be a
new rolling release of the QUIC spec at least once a year on March 21 that, as
a minimum, greases the codepoints and salts. Officially, the new release could
be identified with a label such as something like "v01-202
On 2022-1-22, at 17:05, Lucas Pardue wrote:
> Whatever moniker we chose, I think there will be some part of the population
> that will be surprised and read something more into it than what the
> specification is attempting to do or solve. Personally I think QUIC 1.1 would
> be a very bad name
Hello Martin,
As someone who had seen a lot of misinformation spread about HTTP/2
and actively tried to prevent the same happening for HTTP/3 and QUIC
by providing "correct" sources early on, I can sadly only agree with Lucas
here.
There will always be people who don't do any of the legwork requi
Hi Martins,
Wearing no hats.
On Sat, 22 Jan 2022, 02:05 Martin J. Dürst, wrote:
> Hello everybody,
>
> The following concern just popped up in my mind:
>
> Some people (in particular the press,...) may take version numbers very
> seriously. Reading "QUIC version 2", my guess is that there migh
Hello everybody,
The following concern just popped up in my mind:
Some people (in particular the press,...) may take version numbers very
seriously. Reading "QUIC version 2", my guess is that there might be
articles saying things such as "Quic already is at version 2" or "Quic
version 1 is ou
All outstanding issues are resolved. The biggest practical change for
developers is the random version number, although many asked for the
narrative about how compatible negotiation works, which is now there.
In some sense, this is ready for WGLC, but we may want to wait for the VN
draft to catch
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 : QUIC Version 2
Author : Martin Duke
Filename: draft-ietf-quic-v2-01.txt
Pages : 15
16 matches
Mail list logo
