Hello everyone, As you might have seen, I submitted draft-02 of the qlog format just before the IETF 109 cutoff [1][2]. The main change from -01 is the move back to a simpler default JSON serialization and explicit support for streaming logs using NDJSON.
A year in the making, this update reflects feedback from a considerable adoption and deployment experience of the format by the IETF QUIC community. Over 60% of active implementations currently (partially) support the format [3] and many of you have actively contributed to improving this project, for which I am eternally grateful. Still, with this email, I am once again asking for your support. With draft-02, I feel we have reached the limits of what the current team can accomplish on its own. There are several issues of scope and approach that would benefit greatly from broader discussion. The main ones are: 1. Should qlog focus on reflecting internal implementation events (for example a "packet_acked" event) or provide ways to log the protocols' wire image (for example the ACK frame). Or both? [4] 2. Should qlog feature a wide range of events, each reflecting a specific small aspect, or rather fewer, consolidated events? How much should the qlog events reflect the exact protocol mechanics/internal details? [5] 3. What are the privacy and security best practices for this kind of endpoint logging and how can/should they be enforced? 4. Is qlog as a concept more widely applicable to other protocols than just QUIC/H3? If yes: what does that mean exactly? The answers to these and other questions will follow largely from concrete future applications and use cases people have in mind. This in turn will influence if, how and where we continue work on qlog. Early on, we already discussed wider applications for the qlog concept in tsvarea [6]. However it was decided to first get qlog implementation experience for QUIC/H3, which I believe has now happened. However, this also means qlog now has the most direct value for QUIC/H3 and it feels natural to me to first hear the perspective of the QUIC wg on its future. I can see many possible ways forward, including: adopting this within the QUIC wg, adopting this in another wg, doing a BoF to try and form a new wg, create a design team, organize a single interim session to decide the main points, switch to maintenance mode and use qlog as-is, etc. I have requested an "if time permits" slot for the IETF 109 QUIC meeting in two weeks to get a feel for what people think. This email is to have a backup in case we don't have time then and so people can prepare (or already share) their opinion (if any). Thanks again to everyone who has already contributed to qlog and with best regards, Robin [1]: https://tools.ietf.org/html/draft-marx-qlog-main-schema-02 [2]: https://tools.ietf.org/html/draft-marx-qlog-event-definitions-quic-h3-02 [3]: https://qlog.edm.uhasselt.be/anrw/files/DebuggingQUICWithQlog_Marx_final_21jun2020.pdf [4]: https://github.com/quiclog/internet-drafts/issues/53 [5]: https://github.com/quiclog/internet-drafts/issues/85 [6]: https://www.youtube.com/watch?v=LiNLz1QuT0s&t=3233 -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
