Early Review of draft-ietf-quic-qlog-main-schema-05
review-ietf-quic-qlog-main-schema-05-secdir-early-harkins-2023-04-26-00

Request Review of draft-ietf-quic-qlog-main-schema-05
Requested revision 05 (document currently at 13)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2023-04-30
Requested 2023-03-25
Requested by Lucas Pardue
Authors Robin Marx , Luca Niccolini , Marten Seemann , Lucas Pardue
I-D last updated 2026-04-23 (Latest revision 2025-10-20)
Completed reviews Secdir Early review of -05 by Dan Harkins (diff)
Comments 
qlog is a format for logging that has been used primarily for QUIC and HTTP/3, whereby the endpoints themselves generate logs that can be used for protocol analysis or debug. draft-ietf-quic-qlog-main-schema is the core specification defining the generalized rules for qlog, additional schema documents can extend this to add specific events relevant to the protocol. 

This is a request for early review of draft-ietf-quic-qlog-main-schema and in particular Section 9 on the Security and privacy considerations. Encrypted transports, such as QUIC, provide some challenges for observability and debuggability. Endpoints can explicitly opt in to logging, such as with qlog. Logs have the potential to hold sensitive details that need careful treatment, which is what we attempt to describe in the considerations. We would appreciate an early review of these in order to ensure we are being comprehensive. 

The focus of the review request is draft-ietf-quic-qlog-main-schema. In parallel the QUIC WG is standardizing draft-ietf-quic-qlog-quic-events and draft-ietf-quic-qlog-h3-events that inherit the security considerations. These concrete schema might help to contextualize the types of information that could be logged. Although we are not asking for early review of those drafts we are receptive to any early input the security directorate might decide to provide.
Assignment Reviewer Dan Harkins
State Completed
Request Early review on draft-ietf-quic-qlog-main-schema by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/PmGIQjD-0GqABR5PK0bA5g429j0
Reviewed revision 05 (document currently at 13)
Result Has nits
Completed 2023-04-26
review-ietf-quic-qlog-main-schema-05-secdir-early-harkins-2023-04-26-00
   Greetings,

   I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

   The document describes a logging schema to ingest data for the
purposes of visualization and protocol debugging. It is protocol
agnostic although it is a product of the QUIC WG. It is also format
agnostic but defines a JSON serialization.

   The security considerations seem appropriate given the generic
nature of the schema.

   The summary of this review is Ready with nits. I almost want to
say Ready with issues but I'm not sure these arise to issues, and
are thus nits. They are:

   - the design goals of section 2 do not really add value. Suggest
     getting rid of them.
   - while I understand that previous versions of this draft (which
     is currently version -03) have been implemented and deployed and
     use versions 0.0, 0.1, and 0.2, it seems odd that a published
     RFC would use something other than 1.0. Change version to 1.0.
     Or maybe ask IANA to make it the RFC number right before
     publication. But 0.3 is not really appropriate for an RFC.
   - the placement of the normative word in second sentence of 3.3.2,
     and what it applies to, seems odd. Just say, "Each trace MUST
     have a single vantage_point".
   - suggest adding a "peer" to the VantagePointType to allow for,
     say, mesh networking traces which are not client-server.
   - in 3.4, make this a normative statement, "Each qlog event at
     minimum requires the 'time' (Section 3.4.1), 'name' (Section
     3.4.2) and 'data' (Section 3.4.3) fields."
   - 3.4.2 says, "Certain serializations CAN emit category and type
     as separate fields, and qlog tools SHOULD be able to deal with
     both the concatenated 'name' field, and the separate 'category'
     and 'type' fields." s/CAN/MAY/ and why would it be OK for a
     qlog tool to not deal with both? Shouldn't that SHOULD be a
     MUST?
   - there's a TODO in 4.1. Get rid of it.
   - Get rid of the first person plural language, "we have seen....",
     "we have refrained....", "we recommend...."
   - You should ask IANA to do something in section 10, it's not
     a TODO. Something like "IANA will allocate a well-known URI
     suffix...."

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius