Splitting HTTP/3 and QUIC into separate documents, so they can evolve separately makes, sense, though I would be comfortable with them both remaining in QUICWG for now.
As an AD, I will facilitate a discussion with other areas about the main schema. Robin, it might be useful for you to go on a roadshow at IETF 110 to pitch it to other areas to see if there's wider IETF energy to pursue qlog extensions. If so, the case for putting the main schema outside quicwg is pretty strong. On Mon, Nov 23, 2020 at 12:14 PM Lucas Pardue <lucaspardue.2...@gmail.com> wrote: > Thanks Robin! > > I have some responses in line. > > On Mon, Nov 23, 2020 at 7:05 PM Robin MARX <robin.m...@uhasselt.be> wrote: > >> Hello everyone, >> >> I was happy to see a large amount of support from you all for qlog at the >> QUIC wg meeting last week [0]! >> While it seemed there was consensus that it would benefit from a more >> formal adoption, it wasn't entirely clear if this should be in the QUIC wg. >> >> (I am also CC'ing the HTTP wg via Lucas Pardue, who thought this would >> somewhat concern them as well) >> >> To recap, qlog consists of two parts: >> 1) the main schema, which is protocol agnostic and mostly defines the >> serialization and container format [1] >> 2) the QUIC and HTTP/3 specific events [2] >> > > Yes sorry HTTP folks blame me for your additional email traffic. The > reason I thought the discussion on qlog was pertinent to the HTTP WG is > because one of the major places I've found benefit is in analyzing stream > multiplexing using qvis. This has particularly been useful for developing > an implementation of Extensible Priorities in an HTTP/3 stack. The most > mature way to get qlog for HTTP/2 stacks would be to define qlog schemas > for TCP, TLS and HTTP/2. > > There are potentially other application mappings. As was discussed at the > IETF 109 session, I think congestion control is going to be something that > benefits from logging and tooling. Is there an interest in making qlog work > the same for a CCA across TCP and QUIC? I suspect that might drive some > opinion of what to do here. > > >> I can see roughly 3 main options and would like additional feedback on >> which people want: >> A) Adopt both in QUIC wg for now, bring them to ~full maturity for QUIC >> and H3, and then see if/how to generalize later (it seemed to me most were >> leaning to this side last week) >> B) Adopt document [2] in QUIC wg and find another place for [1], either >> in an existing wg or a new one via BOF by IETF 110 (what happens if that >> fails though?) >> C) Find an existing wg or do a BOF for both [1] and [2] together by IETF >> 110 (not sure this has enough traction outside of QUIC wg?) >> >> > Option A seems the most pragmatic given where we are. But the more I think > about things, the more concerned I get that a focus on QUIC stifles the > innovation of other qlog use cases simply because they fall out of the > scope of permitted discussion. So far, the main schema discussion has > rightly focused on more operational concerns like serialization format, we > should also let people with interest and expertise in this area flourish if > possible. Finally, I also have a concern that the combined QUIC & HTTP/3 > schema becomes difficult to manage once we hand the reigns of HTTP/3 back. > > So I don't have a personal strong decision yet. But I'd like to consider > an Option D that splits the QUIC & HTTP/3 schema, with each WG getting > first refusal for adoption. Meanwhile, we continue to discuss the main > schema. > > Cheers > Lucas > >
