Re: Consensus on Deploying QUIC v1 with HTTP/3

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

Hi, Lucas,

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

> Hi Spencer,
>
>
> On Thu, May 6, 2021 at 4:18 PM Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>>
>> The QUIC working group could reasonably do a short Applicability
>> Statement (https://datatracker.ietf.org/doc/html/rfc
>> <https://datatracker.ietf.org/doc/html/rfc2026#section-3.2>
>> 2026#section-3.2
>> <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.
>>
>
> The document draft-ietf-quic-transport contains in the first paragraph of
> Section 1:
>
> >   QUIC is a secure general-purpose transport protocol.  This document
> >   defines version 1 of QUIC, which conforms to the version-independent
> >   properties of QUIC defined in [QUIC-INVARIANTS].
>
> Subsequent paragraphs go on to explain how -tls and -recovery relate to
> the -transport document.
>

Understood (and I had seen that text previously). So, that's a fine start.


> That seems to cover your goal of pointing people to a single document
> explaining the relationships between documents. But if I'm overlooking
> something please say.
>

I'd ask about these points:

draft-ietf-quic-transport is (checks -34) over 180 pages long. This
material is at the beginning of the Introduction (that's good), but it's a
tiny bit less clear how someone who's not familiar with the QUIC document
suite knows to start there (yes, having QUICv1 published as RFCs at least
makes that a bit more obvious on the documents page, at least at first).

At the bottom of Section 1.1, I find this text,

   This document defines QUIC version 1, which conforms to the protocol
   invariants in [QUIC-INVARIANTS
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].

   To refer to QUIC version 1, cite this document.  References to the
   limited set of version-independent properties of QUIC can cite
   [QUIC-INVARIANTS
<https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-34#ref-QUIC-INVARIANTS>].


but that's following the description of the structure of
draft-ietf-quic-transport. Maybe just moving these paragraphs to Section 1
would be useful?

I note that people who understand QUIC much better than I do had to ask
what "the QUIC RFCs" were in this thread, so I was hoping that might be an
indication that things could be a bit clearer for us all! :-)

Do The Right Thing, of course.

Best,

Spencer


> Cheers
> Lucas
>
>