Hey Spencer, On Tue, Mar 23, 2021 at 12:47 PM Spencer Dawkins at IETF < [email protected]> wrote:
> > In the Days before CoViD-19 (IETF 106), we talked in TSVAREA ( > https://datatracker.ietf.org/doc/minutes-106-tsvarea/) about two ideas > that seemed to have traction: > > - running a couple of QUIC Dispatch sessions for all the extensions > that were stacked up behind the core QUIC documents ( > https://datatracker.ietf.org/wg/quic/documents/ shows 11 docs adopted, > 28 not yet adopted), so that proposals could get the benefit of guidance > from the QUIC community without using QUIC working group time, and > > Our intent is that the recharter gives us a clearer formal statement about what is, and is not, in scope for the QUIC WG. I hope things are naturally more clear than they were during IETF 106. We can of course field ideas and help people figure out where work might best belong, or best be broken apart into reusable transport extensions and application-specific things that belong elsewhere. The important thing is to get people to the most appropriate place in a speedy manner. For the uncertainty of doubt, the list of I-Ds in "Related Internet-Drafts" is populated by a regex that looks for "quic". It really is as simple as that. Unfortunately it means that some documents get listed when our new charter would mark them out of scope. Or even when a doc author has no intention to pitch the idea into a WG. I skimmed over the drafts in the current list and put them in my sorting hat. I won't list them by name because I'm not talking authoritatively about them. Here's my take: * 6 are application mappings * 7 are transport extensions * 2 are maintenance-oriented * 2 are non-QUIC extensions * 7 are multipath-related * the remainder are loosely tied to QUIC Several of the items that are possibly in-scope are already in hand. > > - doing something to give guidance to implementers, before QUIC is > like SIP or TCP with dozens of documents for people to read and grok (see > https://tools.ietf.org/html/rfc7414 for TCP, > https://tools.ietf.org/html/rfc5411 for SIP, but those aren't perfect > models, because the number of specifications was so large before anyone > tried to organize guidance). > > Good idea and we're open to suggestions about effective ways to do this. We've already been doing a bit of this on the QUIC WG base-drafts repository I think https://quicwg.org/ is possibly a good place to consolidate different information and pointers about all things QUIC. Capturing information in an RFC seems to invite going stale immediately, and is maybe a bit rigid for the types of things people might find useful to know about. Cheers, Lucas
