Original text:
efficient than logging the observed CID with each packet in the .header field of the "packet_sent" or "packet_received" events. <del> 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. </del>  Definition: Definition: <del> Note: We do not explicitly log the encryption_level or packet_number_space: the header.packet_type specifies this by inference (assuming correct implementation) </del>  Note: for more details on "datagram_id", see transport-datagramssent. It is only needed when keeping track of packet coalescing. This event is emitted when a packet is buffered because it cannot be processed yet.  Typically, this is because the packet cannot be <del> parsed yet, and thus we only log the full packet contents when it was parsed in a packet_received event. </del>  Definition: Importance: Extra <del> 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. </del>  Definition: Importance: Extra <del> When we receive one or more UDP-level datagrams from the socket. </del>  This is useful for determining how datagrams are passed to the user space stack from the OS. Importance: Extra <del> 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). </del>  Definition: This event's main goal is to prevent a large proliferation of specific purpose events (e.g., packets_acknowledged, <del> 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. </del>  Note: This event can be used to signal internal state change not resulting directly from the actual "parsing" of a frame (e.g., the 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 <del> different events low, we group this signal for all types of retransmittable data in a single event based on existing QUIC frame definitions. </del>  Implementations retransmitting full packets or frames directly can just log the constituent frames of the lost packet here (or do away By definition, an application error is defined by the application- level protocol running on top of QUIC (e.g., HTTP/3). <del> As such, we cannot define it here directly.  Though we provide an extension point through the use of the CDDL "socket" mechanism. </del>  Application-level qlog definitions that wish to define new ApplicationError strings MUST do so by extending the to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR." <del> 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. </del>  9.

Reviewer comments:
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

Revised text:
efficient than logging the observed CID with each packet in the .header field of the "packet_sent" or "packet_received" events.  <ins> 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. </ins> Definition: Definition:  <ins> Note: The encryption_level and packet_number_space are not logged explicitly: the header.packet_type specifies this by inference (assuming correct implementation) </ins> Note: for more details on "datagram_id", see transport-datagramssent. It is only needed when keeping track of packet coalescing. This event is emitted when a packet is buffered because it cannot be processed yet.  Typically, this is because the packet cannot be  <ins> parsed yet, and thus only the full packet contents can be logged when it was parsed in a packet_received event. </ins> Definition: Importance: Extra  <ins> 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. </ins> Definition: Importance: Extra  <ins> When one or more UDP-level datagrams are received from the socket. </ins> This is useful for determining how datagrams are passed to the user space stack from the OS. Importance: Extra  <ins> 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). </ins> Definition: This event's main goal is to prevent a large proliferation of specific purpose events (e.g., packets_acknowledged,  <ins> 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. </ins> Note: This event can be used to signal internal state change not resulting directly from the actual "parsing" of a frame (e.g., the 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  <ins> different events low, this signal is grouped into in a single event based on existing QUIC frame definitions for all types of retransmittable data. </ins> Implementations retransmitting full packets or frames directly can just log the constituent frames of the lost packet here (or do away By definition, an application error is defined by the application- level protocol running on top of QUIC (e.g., HTTP/3).  <ins> As such, it cannot be defined here directly.  Applications MAY use the provided extension point through the use of the CDDL "socket" mechanism. </ins> Application-level qlog definitions that wish to define new ApplicationError strings MUST do so by extending the to 0x100 to produce a QUIC error code from the range reserved for CRYPTO_ERROR."  <ins> 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. </ins> 9.