Speaking from painful experience ... On Thu, May 6, 2021 at 9:54 AM Lucas Pardue <[email protected]> wrote:
> Hi Julian. > > On Thu, May 6, 2021 at 3:24 PM Julian Reschke <[email protected]> > 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 > >
