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