Hi, Lucas, On Thu, May 6, 2021 at 11:06 AM Lucas Pardue <[email protected]> wrote:
> Hi Spencer, > > > On Thu, May 6, 2021 at 4:18 PM Spencer Dawkins at IETF < > [email protected]> 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 > >
