Re: Consensus on Deploying QUIC v1 with HTTP/3

[Spencer Dawkins at IETF <[e-mail]>]

Speaking from painful experience ...

On Thu, May 6, 2021 at 9:54 AM Lucas Pardue <[e-mail]>
wrote:

> Hi Julian.
>
> On Thu, May 6, 2021 at 3:24 PM Julian Reschke <[e-mail]>
> wrote:
>
>> Am 06.05.2021 um 06:11 schrieb Matt Joras:
>> > ...
>> >         You may want to clarify what *exactly* you mean by "the QUIC
>> RFCs".
>> >
>> >
>> >     Lucas was referring to C430:
>> >     https://www.rfc-editor.org/cluster_info.php?cid=C430
>> >     <https://www.rfc-editor.org/cluster_info.php?cid=C430>
>> >
>> > ...Excepting the qpack and http documents. I hit the send button too
>> > quickly.
>>
>> See? That's why I was asking.
>>
>> So we're discussing just -invariants, -transport, -tls, and -recovery,
>> right?
>>
>
> Thanks for pointing this out. The email was written from a position
> familiar with the current documents' status. I should have been more clear
> and explicit.
>

I've spent literally decades trying to explain to people who weren't
familiar with the IETF standards track what "TCP" means - and, now, 40
years later, "Standard TCP", STD 7, is still RFC 793, with no other RFCs
that update it included in the standard.

I was still having that conversation with IETF participants in other areas
who just wanted to reference "TCP", after several discussions during IESG
Evaluation balloting, RFC 793 was the right answer.

Yes, https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/ is in
WGLC, but that's not my point.

The QUIC working group could reasonably do a short Applicability Statement (
https://datatracker.ietf.org/doc/html/rfc2026#section-3.2) that (as part of
the RFC 2026 description)

   An AS identifies the relevant TSs and the specific way in which they
   are to be combined, and may also specify particular values or ranges
   of TS parameters or subfunctions of a TS protocol that must be
   implemented.  An AS also specifies the circumstances in which the use
   of a particular TS is required, recommended, or elective (see
section <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>
   3.3 <https://datatracker.ietf.org/doc/html/rfc2026#section-3.3>).


And THEN, we could just refer to one specification that explained what we
mean when we say "QUICv1", or "core QUIC", or whatever we want to call it,
and everyone would know what we mean, without having to guess. This would
be especially helpful for participants in other SDOs, but not only for
them.

I'm not sure whether the QUIC community would ever advance QUICv1 to full
Internet Standard, when it would become eligible for a STD  designation
that could include the relevant RFCs, but even if you do, that's probably
years in the future (and a lot of successful IETF protocols don't advance
beyond Proposed Standard).

If that was the right thing to do, I'd be happy to knock out a -00. Please
advise.

Best,

Spencer


> Yes, the -invariants, -transport, -tls, and -recovery, are the QUIC
> documents that are presently in AUTH48 and we expect to be published as
> RFCs before -http and -qpack. Other documents adopted by the QUIC WG are
> not in scope for this discussion (the applicability drafts, datagram
> extension, etc.). So to restate the original position more clearly:
>
> This email commences a formal consensus call for permitting the deployment
> of QUIC "0x00000001" with HTTP/3 ALPN identifier "h3" *after*
> -invariants, -transport, -tls, and -recovery have been published as RFCs
> but *before *-http and -qpack are published as RFC. The call will end on
> May 13.
>
> Cheers,
> Lucas
>
>