Speaking as an individual and owner of the qlog crate that is maintained under the quiche project:
my update to support serialization and deserialization of this lastest version took just a couple of hours to do. We plan to merge it [1] once qvis support lands. Cheers Lucas [1] - https://github.com/cloudflare/quiche/pull/1813 On Tue, Jul 16, 2024, at 11:09, Robin Marx wrote: > Hello fellow structured logging enthusiasts, > > It is me again with an update on the qlog drafts, which had new versions > published last week [1]. > > The focus this time was on finalizing (well-defined) extensibility in two > main ways: > 1. making all events and structures properly extensible through CDDL > constructs [2] (meaning later extensions can use tools for automatic code > checking, schema validation, example generation, etc. by hooking into > extension points) > 2. creating a framework to track which events/event documents are included in > a given qlog file [3] (we have an explicit list of "event_schemas" defined by > IANA-backed URIs, as well as a new "file_schema" concept) > > This means the extensibility work is now 95% done (of course we found an edge > case right after submitting the drafts [4]) and that others can start > utilizing/exercising these setups for new extensions. > This has already been done in at least two concrete occasions: > A. the "Convergence of Congestion Control from Retained State" draft at TSVWG > has some qlog events defined [5] > B. the "RoQ qlog event definitions" draft proposes qlog events for RTP over > QUIC [6] > > *At this point, we feel the basic mechanisms are robust and stable enough for > others to utilize them to define new qlog schemas. * > > I personally feel these were the last of planned main/breaking changes, so > I'm also planning to start updating the qvis toolsuite [7] to support the > newest qlog versions in August/September. > I concretely plan to keep the current qvis version available as a "legacy" > option (as-is, unmaintained), with the newer versions ONLY supporting the > latest qlog drafts (so no backwards compat). > > In conclusion, I think we're still on track to move qlog to WGLC by the end > of this year as planned. > Most of the open issues/PRs are either very old (and can be closed with > no/little action) or are simple/editorial-only changes. > Only a few discussion points remain (mainly: adding a new timestamp/clock > option [8]), which can probably be resolved by the editors/on the mailing > list. > > *As such, early reviews of the documents are now welcomed.* > *Additionally, you can now slowly start thinking of updating your qlog > implementations to move to the new drafts. * > At least one stack (xquic [9]) is already doing this, and this will be a big > help in making sure the new qvis version remains a useful tool for debugging. > > Finally, I will personally sadly not be in Vancouver, but potentially Lucas > Pardue will give a (small) update on qlog during the QUIC WG meeting (TBD). > If people have any questions/remarks, do feel free to reach out via email to > me or the other editors! > > With best regards, > Robin (on behalf of the qlog editors) > > [1] https://github.com/quicwg/qlog > [2] https://github.com/quicwg/qlog/pull/417 > [3] https://github.com/quicwg/qlog/pull/424 > [4] https://github.com/quicwg/qlog/issues/432 > [5] > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-careful-resume-10#name-qlog-support-for-quic > [6] https://www.ietf.org/archive/id/draft-engelbart-qlog-roq-events-00.html > [7] https://qvis.quictools.info/ > [8] https://github.com/quicwg/qlog/pull/290 > [9]: https://github.com/alibaba/xquic/blob/main/docs/Features.md >
