Hello Quic-WG, Robin, Someone pointed me to draft-marx-qlog-main-schema-02 because "You showed interest in structured logging". I've had a quick read and have some initial thoughts.
The first thought was "yes, there is need for a specified schema for logs, that can be serialized to a variety of formats". However, the draft is a bit hand-wavy about the schema and instantiated format. For starters, section 1.1 notes the use of a datatype language "inspired loosely by the "TypeScript" language". This language is not an IETF standard. The IETF has standardized at least 3 data definition languages: 1. ABNF as RFC 5234 [1] 2. Concise Data Definition Language (CDDL) as RFC 8610 [2] 3. YANG as RFC 7950 [3] Apart from ABNF, both CDDL and YANG have specified how to convert the instantiated data to JSON (RFC 7951[4] for YANG, CDDL in its own RFC). I would highly recommend the author to choose either YANG or CDDL to define all qlog structures. Skipping over the schema definition, section 4 deals with the serialization of qlog. The schema has a field that contains the serialization format. But this serialization is actually metadata. It is up to the parties exchanging the serialized data to agree on the format (possibly using Accept/Content-Type headers when using HTTP to transfer and a file-extension when stored on disk). Section 4.1 should be superfluous if the author uses either CDDL or YANG as a modeling language, as those have defined how to serialize data. Section 4.2 then uses a non-IETF serialization format (NDJSON) to accomplish the streaming property of qlog. In the DNS world, the C-DNS (RFC 8618[5]) logging format is specified using CDDL, uses CBOR (RFC 8949[6]) as its primary 'storage' mechanism, using tables inside blocks to 'compress' repeated data. It implements streaming on a specific level of the schema. Using such an approach in qlog would mitigate the need of the "optimization" section (4.3). It is up to the tooling to translate from CBOR to JSON or any other format the user or tools can read. Section 5 then goes into how tools should behave, down to the use of certain environment variables. This is needlessly restrictive and stifles any attempt to differentiate between the multitude of tools that could be developed. I hope the WG and author consider these reservations on the draft seriously. Best regards, Pieter Lexis 1 - https://tools.ietf.org/html/rfc5234 2 - https://tools.ietf.org/html/rfc8610 3 - https://tools.ietf.org/html/rfc7950 4 - https://tools.ietf.org/html/rfc7951 5 - https://tools.ietf.org/html/rfc8618 6 - https://tools.ietf.org/html/rfc8949 -- Pieter Lexis PowerDNS.COM BV -- https://www.powerdns.com
