Some remarks on draft-marx-qlog-main-schema-02

[Pieter Lexis <[e-mail]>]

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