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

Commentary: Work towards resolving , for the QUIC events document . 
 This is great . There are 2 - 3 instances in the h3 document as well that could use similar re - wording . I 'll post a PR for that
Paragraph (version A):
This is viewed from the perspective of the one applying the new id.
As such, if we receive a new connection id from our peer, we will see
the dst_ fields are set.  If we update our own connection id (e.g.,
NEW_CONNECTION_ID frame), we log the src_ fields.
Paragraph (version B):
This is viewed from the perspective of the endpoint applying the new
id.  As such, when the endpoint receives a new connection id from the
peer, it will see the dst_ fields are set.  When the endpoint updates
its own connection id (e.g., NEW_CONNECTION_ID frame), it logs the
src_ fields.
Paragraph (version A):
This event is emitted when a packet is buffered because it cannot be
processed yet.  Typically, this is because the packet cannot be
parsed yet, and thus we only log the full packet contents when it was
parsed in a packet_received event.
Paragraph (version B):
This event is emitted when a packet is buffered because it cannot be
processed yet.  Typically, this is because the packet cannot be
parsed yet, and thus only the full packet contents can be logged when
it was parsed in a packet_received event.
Paragraph (version A):
When we pass one or more UDP-level datagrams to the socket.  This is
useful for determining how QUIC packet buffers are drained to the OS.
Paragraph (version B):
When one or more UDP-level datagrams are passed to the socket.  This
is useful for determining how QUIC packet buffers are drained to the
OS.
Paragraph (version A):
When we receive one or more UDP-level datagrams from the socket.
This is useful for determining how datagrams are passed to the user
space stack from the OS.
Paragraph (version B):
When one or more UDP-level datagrams are received from the socket.
This is useful for determining how datagrams are passed to the user
space stack from the OS.
Paragraph (version A):
When we drop a UDP-level datagram.  This is typically if it does not
contain a valid QUIC packet (in that case, use packet_dropped
instead).
Paragraph (version B):
When a UDP-level datagram is dropped.  This is typically done if it
does not contain a valid QUIC packet (in that case, use
packet_dropped instead).
Paragraph (version A):
This event's main goal is to prevent a large proliferation of
specific purpose events (e.g., packets_acknowledged,
flow_control_updated, stream_data_received).  We want to give
implementations the opportunity to (selectively) log this type of
signal without having to log packet-level details (e.g., in
packet_received).  Since for almost all cases, the effects of
applying a frame to the internal state of an implementation can be
inferred from that frame's contents, we aggregate these events in
this single "frames_processed" event.
Paragraph (version B):
This event's main goal is to prevent a large proliferation of
specific purpose events (e.g., packets_acknowledged,
flow_control_updated, stream_data_received).  Implementations have
the opportunity to (selectively) log this type of signal without
having to log packet-level details (e.g., in packet_received).  Since
for almost all cases, the effects of applying a frame to the internal
state of an implementation can be inferred from that frame's
contents, these events are aggregated into this single
"frames_processed" event.
Paragraph (version A):
This event indicates which data was marked for retransmit upon
detecting a packet loss (see packet_lost).  Similar to our reasoning
for the "frames_processed" event, in order to keep the amount of
different events low, we group this signal for all types of
retransmittable data in a single event based on existing QUIC frame
definitions.
Paragraph (version B):
This event indicates which data was marked for retransmit upon
detecting a packet loss (see packet_lost).  Similar to our reasoning
for the "frames_processed" event, in order to keep the amount of
different events low, this signal is grouped into in a single event
based on existing QUIC frame definitions for all types of
retransmittable data.
Paragraph (version A):
As such, we cannot define it here directly.  Though we provide an
extension point through the use of the CDDL "socket" mechanism.
Paragraph (version B):
As such, it cannot be defined here directly.  Applications MAY use
the provided extension point through the use of the CDDL "socket"
mechanism.
Paragraph (version A):
This approach maps badly to a pre-defined enum.  As such, we define
the crypto_error string as having a dynamic component here, which
should include the hex-encoded and zero-padded value of the TLS alert
description.
Paragraph (version B):
This approach maps badly to a pre-defined enum.  As such, the
crypto_error string is defined as having a dynamic component here,
which should include the hex-encoded and zero-padded value of the TLS
alert description.