Change:
many UDP datagrams, unique identifiers are required to be able to track them individually in qlog traces.  However, neither UDP nor QUIC exchanges datagram identifiers on the wire.  Selecting <del> identifier is values is thus left to qlog implementations, that should consider how to generate unique values within the scope of their created traces. </del> <ins> identifier values is thus left to qlog implementations, which should consider how to generate unique values within the scope of their created traces. </ins> 5.11.

Discussion:
rebase on main should fix the cddl tests
Currently, we have a mechanism for tracking QUIC packet coalescing in a single UDP datagram by means of the field. This was originally added as per . Main intended use: when a UDP payload is received containing multiple coalesced QUIC packets, those QUIC packets are given the same "datagram ID" (which is a receiver-side chosen number that's unique per received datagram, which is needed because UDP datagrams don't have a packet number or similar). As such, when 2 separate packets are logged in 2 separate events, but they have the same value for the field, it's clear they were coalesced. Similarly, 2 events with the same indicate sender-side coalescing. As the original issue indicates, this can be deduced from the events as well, but those are often too chatty to leave on. The fields on the events are for completeness / ability to track coalesced packets across the different events. I'm personally not the biggest fan of this solution (did you eventually implement this in quic-go, NAME but I don't immediately see a better approach. CC NAME as he indicated the use of wasn't clear to him, which means we either need to revisit or clarify its use.
I'll try to summarise my understanding. The is specified for the following events packetsent packetreceived packetbuffered packetdropped datagramssent (an array here, but same purpose) datagramsreceived (an array here, but same purpose) The use of the ID is given in URL and currently says: I don't mind the motivating use case. I'm not sure exactly how my implementations could use it for packet sending events because we generate the packet and qlog it before we get into UDP datagram realms. Changes might address that but I'm not sure it's worth overhead. Other implementations might find it far more natural to use though. The main part I find confusing is the part about . This is vague and quite specific at the same time. How unique does something need to be? Can I just use a counter like datagramid = 0, datagramid=1 for the packets sent on a connection? Or is the expectation that the identifier is more like a UUID, so that packets are uniquely traceable?

Maybe it depends if we are capturing single connections or traces that span mutliple things, so perhaps a reword to state the requirements and expectations of the datagram_id value could help. E.g. "Since QUIC traces may contain many UDP events, unique identifiers are required for each datagram in order to avoid them being confused. Identifiers are not exchanged on the wire, they are only relevant to the logging endpoint. Selecting identifier values is left to implementations that should consider how to generate unique values within the scope of the traces they generate"
LGTM modulo nit