Draft: draft-ietf-quic-qlog-h3-events

Commentary: Some simple  editorial improvements that 'll be required later on 
 Looks good to me ! thanks
Paragraph (version A):
In some cases, the length fields are also explicitly reflected
inside of frame headers.  For example, all HTTP/3 frames include
their explicit payload lengths in the frame header.  In these
cases, those fields are intentionally preserved in the event
definitions.  Even though this can lead to duplicate data when the
full RawInfo is logged, it allows a more direct mapping of the
HTTP/3 specifications to qlog, making it easier for users to
interpret.  In this case, both fields MUST have the same value.
Paragraph (version A):
there have been several previously broadly deployed qlog versions
based on older drafts of this document (see draft-marx-qlog-main-
schema).  The old values for the "qlog_version" field were "draft-
00", "draft-01" and "draft-02".  When qlog was moved to the QUIC
working group, we decided to switch to a new versioning scheme
which is independent of individual draft document numbers.
However, we did start from 0.3, as conceptually 0.0, 0.1 and 0.2
can map to draft-00, draft-01 and draft-02.
Paragraph (version A):
The RawInfo:data field can be truncated for privacy or security
purposes (for example excluding payload data), see truncated-
values.  In this case, the length properties should still indicate
the non-truncated lengths.
Paragraph (version A):
We do not specify explicit header_length or trailer_length fields.
In most protocols, header_length can be calculated by subtracting
the payload_length from the length (e.g., if trailer_length is
always 0).  In protocols with trailers (e.g., QUIC's AEAD tag),
event definitions documents SHOULD define other ways of logging
the trailer_length to make the header_length calculation possible.
Paragraph (version A):
The exact definitions entities, headers, trailers and payloads
depend on the protocol used.  If this is non-trivial, event
definitions documents SHOULD include a clear explanation of how
entities are mapped into the RawInfo structure.
Paragraph (version A):
Relatedly, many modern protocols use Variable-Length Integer
Encoded (VLIE) values in their headers, which are of a dynamic
length.  Because of this, we cannot deterministically reconstruct
the header encoding/length from non-RawInfo qlog data, as
implementations might not necessarily employ the most efficient
VLIE scheme for all values.  As such, to make exact size-analysis
possible, implementers should use explicit lengths in RawInfo
rather than reconstructing them from other qlog data.  Similarly,
tool developers should only utilize RawInfo (and related
information) in such tools to prevent errors.
Paragraph (version A):
QUIC packets always include an AEAD authentication tag ("trailer")
at the end.  As this tag is always the same size for a given
connection (it depends on the used TLS cipher), this document does
not define a separate "RawInfo:aead_tag_length" field here.
Instead, this field is reflected in "transport:parameters_set" and
can be logged only once.
Paragraph (version A):
In some cases, the length fields are also explicitly reflected
inside of packet headers.  For example, the QUIC STREAM frame has
a "length" field indicating its payload size.  Similarly, the QUIC
Long Header has a "length" field which is equal to the payload
length plus the packet number length.  In these cases, those
fields are intentionally preserved in the event definitions.  Even
though this can lead to duplicate data when the full RawInfo is
logged, it allows a more direct mapping of the QUIC specifications
to qlog, making it easier for users to interpret.
Paragraph (version A):
connection_state_changed with a new state of "attempted" is the
same conceptual event as the connection_started event above from
the client's perspective.  Similarly, a state of "closing" or
"draining" corresponds to the connection_closed event.
Paragraph (version A):
This event is emitted when a (group of) sent packet(s) is
acknowledged by the remote peer _for the first time_. This
information could also be deduced from the contents of received ACK
frames.  However, ACK frames require additional processing logic to
determine when a given packet is acknowledged for the first time, as
QUIC uses ACK ranges which can include repeated ACKs.  Additionally,
this event can be used by implementations that do not log frame
contents.