general observations

[xquery]

The following is a 'bag' of general comments ... perhaps not so actionable but I did not find a mail list to send these kind of general observations.

scope

Some readers may try to contrast/compare this effort with higher level http logging formats (eg. NCSA, common log format and friends) ... might be worth reducing their confusion by adding some context eg. qlog sits near pcap.

You may consider explicitly constraining scope to h2/h3 and degrade gracefully for use with other protocols as a side effect of good design instead of assert broad applicability.

There is a statement of compliance attempted in 'tooling section' but this document defines a high level schema eg. I would have expected the only statement of compliance achievable (in this document) is the correct validation of schema against instance data.

Unlike pcap (which is defined in terms of an api) qlog (so far) is defined in the form of a schema - hence I was looking for a clear definition of optional vs not required ... my expectation was for the core of qlog to be as small as possible.

I would separate out protocol definition (endpoint) ... I am sure there exists a good IETF example of this ... but I am too lazy to find and will point you to a W3C set of specs as example https://www.w3.org/TR/2013/REC-sparql11-overview-20130321/

json

You might consider adding some section on json convention/style (assert snake_case, etc) eg. remarking on challenges of using json for representing log data (limitations with datetime, decimal, no comments - all come to mind).

You are defining a high level schema (which for me implies no dependency on a concrete format like json) but as you have used json throughout to illustrate relationships/structure - I was looking (maybe missed it) for a non normative json schema definition.

keys

error is buried in the text, should be normatively defined.

I dislike the term 'vantage_point' ... I understand the requirements but maybe considering other terms like 'src' and 'target' are more appropriate.

values

have you considered defining a time unit in some human readable datetime (including tz notation ex.iso-8601 et al https://www.w3.org/International/core/2005/09/timezone.html)

transforms
Have you considered demonstrating how transforms might work
I like the way csv spec goes about this https://www.w3.org/2013/csvw/wiki/Main_Page

general

It is unclear how easy for a database to index qlog formatted json.

I think the section on 'Practical Use' might consider how compressed json compares to a binary format.

[LPardue]

It's two years since @xquery kindly gave us a review of the specification. Some things will have been overtaken by events (OBE), some others might still be valid. Here's a very quick triage response base on https://datatracker.ietf.org/doc/html/draft-ietf-quic-qlog-main-schema-03, that tries to draw out salient points from the OP:

1. contrast to other logging formats and clarifiy the applicability - seems like an opportunity for solid editorial improvement

2. mention of tooling in compliance - OBE

3. optional fields - resolved by using CDDL.

4. "I would separate out protocol definition (endpoint)" - not sure I understand this against current text. OBE?

5. json - I think most of this has been addressed via CDDL. If you're willing to re-review and point out specific things on a new ticket(s), then addressing those sounds entireley reasonable

6. "error is buried in the text" - OBE?

7. "I dislike the term 'vantage_point'" - In general, this describes the role of the actor in the system that is logging, independent of the traffic flows. The suggestion of 'src' or 'target' are too tightly coupled to flows; server role is both a source and a target. I can live with the term vantage_point and, in my limited knowledge, have not heard anyone else complain. If you'd like us to bikeshed the name, please raise a separate issue.

8. human-readable time? - needs to be tracked in a separate new issue. FWIW I'd hazard on the side of this being a tooling presentation matter, let's keep the machine-readable format simple

9. "Have you considered demonstrating how transforms might work" - I don't know. Can you provide some more colour about what you're asking? My gut instinct is that transforms between CDDL, JSON, JSON-SEQ, and other formats is already detailed outside qlog and we don't need to repeat that. But I'd like to hear more.

10. "It is unclear how easy for a database to index qlog formatted json." -please see https://quicwg.org/qlog/draft-ietf-quic-qlog-main-schema.html#section-6.3.1 and surrounding text. If there's more that could be added, a new issue or a PR would be appreciated.

11. Compression - OBE. See https://quicwg.org/qlog/draft-ietf-quic-qlog-main-schema.html#section-6.3.2

[LPardue]

Closing this as I think most things are obsolete in latest copy. Anything that might have been missed can be reopened separately.