jiebi/CodeConvo huggingface dataset:
Change:
Connection retried was never properly specced. The main reason is that a retried connection is completely separate from the original connection attempt, except for the value, and as such is usually logged in a separate file / separate context from the original connection qlog data. Current qlog deployments either have other ways of correlating retried connections with the original attempts, or don't need to do this. Either way, there is no tangible need for at this time.
I don't think that's correct. You also take your Connection IDs with you to the new connection. quic-go logs it to the same file, as it is the same connection attempt. I don't see value in though.

Discussion:
4.6. <del> TODO 4.7. </del> Importance: Base This event is used to track progress through QUIC's complex handshake

state = handshake_confirmed <del> 4.8. </del> <ins> 4.7. </ins> e.g., path_updated

For now, infer from other connectivity events and path_challenge/ path_response frames <del> 4.9. </del> <ins> 4.8. </ins> Importance: Extra
Change:
In doing the exercise to try and define a new DATAGRAM extension for qlog (at URL), it became clear that we only had a CDDL extension point for the events themselves () but NOT for the individual QUIC and HTTP/3 frames. This is needed so we can add the CDDL definitions for new frames in other documents and have them properly matched to the CDDL expectations of "main document" events like and .
LGTM modulo some editorial nits

Discussion:
5.2. <ins> The generic "$HTTPFrame" is defined here as a CDDL extension point (a "socket" or "plug").  It can be extended to support additional HTTP/3 frame types. The HTTP/3 frame types defined in this document are as follows: </ins> 5.2.1. 5.2.2.

8.11. <ins> The generic "$QuicFrame" is defined here as a CDDL extension point (a "socket" or "plug").  It can be extended to support additional QUIC frame types. The QUIC frame types defined in this document are as follows: </ins> 8.11.1. In QUIC, PADDING frames are simply identified as a single byte of
Change:
This field is not particularly useful, because it will always be 16, see URL it's a property of the TLS cipher suite in use, so it can be trivially looked up, if necessary
So this is a bit of a tough one for me, since I've gone through the pain of trying to determine the length of the TLS trailer for TLS-over-TCP from wireshark output that does NOT explicitly include the size and also makes it difficult to get the proper cipher name to heuristically determine it. That said, for QUIC V1 it's indeed all 16, so you -could- make an argument we can drop it here and add it back in with a V2.1/V3 if new ciphers start being used. I don't have a particularly big preference either way. If we do this change though, the prose could use tightening, because in the current version we have 2 sentences after another that indicate the aead_length depends on the cipher suite.
I'm leaning on the side of removing this field. The information is made redundant by the cipher suite. Things that care about the tag length can do a lookup or make their own assumptions based on other information
Discussed on call. NAME will make the requested prose change and should be good to go.
Rebased and tightened the text around the tag length.
Minus the comment above, this LGTM.

Discussion:
2.1. <ins> QUIC packets always include an AEAD authentication tag at the end. In general, the length of the AEAD tag depends on the TLS cipher suite, although all cipher suites used in QUIC v1 use a 16 byte tag. </ins> 2.2. A single qlog event trace is typically associated with a single QUIC
Change:
Partially Main change is adding as a PacketType. The is added as a field to packetsent and packetreceived. Any of the "unpredictable bits" can be logged as Added a trigger to to indicate if a connection goes into draining/closing because a valid statelessreset was received. Backwards compatibility break: renamed to on the NewConnectionID frame definition (for consistency). Been thinking about a way to signal an "invalid" stateless reset, but figured there is no way to distinguish it from an otherwise garbage datagram, so decided it was impossible. Not 100% sure about the "looping case" where you continually lower the packet size. Maybe that's solved by adding a generic "packetsize" trigger value to though?
LGTM!
These concepts were in flux when -01 was made and are now much more settled. Any thoughts on how to best approach this are more than welcome.
For stateless reset, I can see two options: make it a new PacketType and then simply use / make it a new event type with custom semantics At least one implementer has indicated a preference for (1), since their stack only intends to support the core events.
For stateless reset, both works for me. Most important thing is to get a way to log it at all, since this would be an interesting signal in production.

Discussion:
"application" // e.g., HTTP/3's GOAWAY frame <ins> "stateless_reset" // because a stateless reset was received </ins> 5.1.7. e.g., path_updated
Change:
Not 100% sure this is enough for all the latest draft-27(+) changes though, added a TODO in the draft for that purpose. Also added a packetnumberspace field to metrics_updated to be flexible for implementations that don't want to implement all types of events. It's not a great fit at that location, but it seemed the most synergistic without having a completely new event type. PTAL NAME
Currently, we log in . However, we can have multiple PTO's running across multiple PN spaces and there is no proper way to correlate them with a PN space in metricsupdated. This also impacts the event types. Possible resolutions: Add pnspace attribute to Split PTO count into a separate event (potentially merge with loss_timer?) TODO: reason more about how these metrics are tied to PN spaces in general (are there others than PTO that are duplicated) cc NAME
Most other metrics in the event are independent of the PN space, so that would be weird. I'd prefer to do that. Not sure if it makes sense to merge is with the loss timer events, since we also need to be able to log a reset of the PTO count to 0 (which doesn't require setting of a timer).

Discussion:
Importance: Extra <del> This event is emitted when the single recovery loss timer is set. </del> <ins> This event is emitted when a recovery loss timer changes state.  The three main event types are: set: the timer is set with a delta timeout for when it will trigger next expired: when the timer effectively expires after the delta timeout cancelled: when a timer is cancelled (e.g., all outstanding packets are acknowledged, start idle period) Note: to indicate an active timer's timeout update, a new "set" event is used. </ins> Data:

these events need to be?  Just support QUIC-style recovery from the spec or broader? <del> Triggers: TODO </del> <ins> TODO: read up on the loss detection logic in draft-27+ and see if this suffices </ins> 5.4.5. <del> Importance: Extra This event is emitted when the single recovery loss timer fires. Data: 5.4.6. </del> Importance: Core This event is emitted when a packet is deemed lost by loss detection.

"pto_expired" // draft-23 section 5.3.1, MAY <del> 5.4.7. </del> <ins> 5.4.6. </ins> Importance: Extra
Change:
Per discussion on slack, and can be merged into , given that we have a field for the disambiguation.
NAME Done. Updated the PR.

Discussion:
"unsupported_version" <ins> "unexpected_packet" "unexpected_source_connection_id" "unexpected_version" </ins> Note: sometimes packets are dropped before they can be associated with a particular connection (e.g., in case of "unsupported_version").  This situation is discussed in handling-
Change:
At the moment, the paragraph says "Initial packets that are sent to establish a new connection." That is unclear. It is possible to interpret this text as "all Initial packets that the client sends," because all the Initial packets are used to establish a new connection. As the paragraph right above discusses what endpoints should do once they receive transport parameters, we can be clear that this paragraph discusses what should be done until then.
Thanks Kazuho, this is definitely clearer. WDYT of the tweak?

Discussion:
packets. A client MAY also clear the QUIC Bit in Initial packets that are sent <del> to establish a new connection.  A client can only clear the QUIC Bit if the packet includes a token provided by the server in a NEW_TOKEN frame on a connection where the server also included the grease_quic_bit transport parameter.  To allow for changes in server configuration, clients SHOULD set the QUIC Bit if the token was provided more than 7 days prior. </del> <ins> prior to receiving transport parameters from the server.  A client can only clear the QUIC Bit if such packets include a token provided by the server in a NEW_TOKEN frame on a connection where the server also included the grease_quic_bit transport parameter.  To allow for changes in server configuration, clients SHOULD set the QUIC Bit if the token was provided more than 7 days prior. </ins> 3.2.
Change:
It seems like the answer to was already in the draft. It just wasn't precise enough to be useful. I also found the wording of the next section awkward, so I'm bundling my changes.
The editorial improvements seem good but I still don't see an answer about the question of stateless reset. For instance, you mention NEW_TOKEN but not .
Oh, I misread. Good thing I didn't mark this as closing . I'll add that.
Would it be correct to say that packets will never be affected by this extension?
Good question. An Initial with a token from (NEW_TOKEN from) a previous connection can clear the bit if the server originally included the transport parameter. If the server puts this information in the token, processes that token, and decides to send a Retry anyway, it might know that the client previously supported the extension. The question is whether we want to allow that. Allowing that means that the client is now constrained (as the server is) to not offer a token if it changes its attitude toward the extension in the interim. Disallowing it means that Retry doesn't get the benefit of greasing. The other way this might happen is if the Retry is sent after processing the contents of the Initial packet. That's much less likely given the way Retry works, but it is at least theoretically possible. I'm leaning toward forbidding the server from exercising the extension unless it reads the client's opinion from the message it receives. We don't add a bunch of constraints on how clients offer tokens or tickets elsewhere in the stack and it would be bad form to start.
Gah, I misread that as Retry. I keep doing that. As for stateless reset, it seems unlikely that a server would be able to generate a truly stateless reset with the QUIC Bit cleared. Except... A server could condition its use of the QUIC Bit extension on support from the client. That is, it only declares support for the extension if the client does the same. In that case, packets it receives with the QUIC Bit cleared would indicate that the client also supports the extension. In that case, the server would be able to clear the QUIC Bit on its own stateless reset packets. Aside from that, it seems like it would be hard to be confident that the cleared bit would be acceptable to a client.
Right, we might expect that a QUIC server that has a good relationship with e.g. a Load Balancer might be able to share some information about itself and behaviours. But that sounds too hard for the minimal gain it would provide here, so I'm pessimistic anyone would bother just for QUIC bit grease. The new text cuts a good balance on speaking to the consideration and allow people to do what they like.
LGTM thanks

Discussion:
negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <ins> An endpoint cannot clear the QUIC Bit without knowing whether the peer supports the extension.  As stateless reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on stateless reset packets. </ins> 3.2. The purpose of this extension is to allow for the use of the QUIC Bit
Change:
This was unclear as it wasn't clear which extension was operative in the sentence.
changes lgtm

Discussion:
sent in addition to the grease_quic_bit transport parameter.  Though the value of the QUIC Bit in packets received by a peer might be set according to rules defined by the extension, they might also be <del> randomized according to the definition of the grease_quic_bit extension.  Receiving the transport parameter for the extension could be used to confirm that a peer supports the semantic defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according to the rules of the extension, but defer acting on the information conveyed until the transport parameter for the extension is received. </del> <ins> randomized as specified in this document.  Receiving the transport parameter for the extension could be used to confirm that a peer supports the semantic defined in the extension.  To avoid acting on a randomized signal, the extension can require that endpoints set the QUIC Bit according to the rules of the extension, but defer acting on the information conveyed until the transport parameter for the extension is received. </ins> Extensions that define semantics for the QUIC Bit can be negotiated without using the grease_quic_bit transport parameter.
Change:
This is also fewer words :)
URL there is no definition of what an intermediary stands for here to understand the statement. I think rather defining the "intermediary" we can rephrase to inform the original intention of the fixed bit in QUIC packet i.e. coexistence with protocols in RFC7983. The statement here also gives an impression that any node in the network should be able to efficiently distinguish QUIC packets where in our OPS draft we are saying this is not reliable with a notion of "don't use it". so rephrasing should also help from this point of view. I would propose something like this - The purpose of having a fixed value is to allow coexistance with other protocols in ] . As this bit can be used to identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

Discussion:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow intermediaries and endpoints to efficiently distinguish between QUIC and other protocols; see DEMUX for a description of a scheme that QUIC can integrate with as a result.  As this bit effectively identifies a packet as QUIC, it is sometimes referred to as the "QUIC Bit". </del> <ins> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit". </ins> Where endpoints and the intermediaries that support them do not depend on the QUIC Bit having a fixed value, sending the same value
Change:
URL Has there been any analysis done for the 7 day rule? or is this just an agreed value. It would be nice to provide some reasoning behind the 7 day rule.
This matches the recommendations in TLS for session tickets, which prohibit the use of tickets after 7 days. But I don't think we should hide from the fact that this is completely and unapologetically arbitrary. Arbitrary is OK; justification only papers over that.
If this is completely arbitrary then we should not need to recommend this, this is not an experimental specification. In that case it makes sense to even drop it. But I see this is not really that much arbitrary, and reflects the practice for TLS session token. I think we can just say that. in this case we can go from SHOULD to MAY, making it optional. by the way I also think, the security consideration falls short on this topic. If we are recommending something then we it is better to say what happens when it is not followed.
It is arbitrary, but it does need a specified maximum. What happens when it is not followed is that packets can't be processed.
yes, if we say something then it will be best to specify a maximum. so the question now from my side is - do we need a strong recommendation (SHOULD) or can we make is optional (MAY)? if we don't have enough experience of actual deployment of it them perhaps it is best that we make it optional. But I am interested to hear why this should be a "SHOULD". when you say "packets can't be processed" do you mean at server? can we write this down?
The text already says why:
now that we have explicitly added handshake and 0-RTT packet in this clause, the to me call for a attention from the WG to review. Otherwise looks good to me. Latest text LGTMThanks for addressing my nits

Discussion:
All packets sent after receiving and processing transport parameters might be affected, including Initial, Handshake, and Retry packets. <del> A client MAY also clear the QUIC Bit in packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC) received less than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. </del> <ins> A client MAY also clear the QUIC Bit in Initial, Handshake, or 0-RTT packets that are sent prior to receiving transport parameters from the server.  However, a client MUST NOT clear the QUIC Bit unless the Initial packets it sends include a token provided by the server in a NEW_TOKEN frame (Section 19.7 of QUIC), received less than 604800 seconds (7 days) prior on a connection where the server also included the grease_quic_bit transport parameter. </ins> This 7 day limit allows for changes in server configuration.  If server configuration changes and a client does not set the QUIC
Change:
Broken into separate changes; see the commentary on each. This won't rebase nicely with , but I can manage that later.

Discussion:
The grease_quic_bit transport parameter (0x2ab2) can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST <del> treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. </del> <ins> treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC
Change:
LGTM.
Actually, looking at a bit closer, perhaps consider: "... endpoint and cooperating intermediaries to efficiently ..." and perhaps make the Manageability reference explicitly to section 3.1 that covers identifying QUIC traffic.
Note that this is the second paragraph of the document. I'd prefer not to pile too many unrelated concepts in at this point. I think that it is OK to consider "cooperating intermediaries" to be implicit when we say "endpoint" when operating at this level of abstraction. Toward the end, where manageability is cited, is a better place for that sort of detail. I narrowed the citation to point to Section 3.1 as you suggested.
I think this update addresses NAME 's point in the telechat review.

Discussion:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del> <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del> <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.
Change:
This one says something like what Lucas said, with the caveat that the whole thing about per-connection ID is specific to spin bits, so I dropped that.
LGTM

Discussion:
The second-to-most significant bit of the first byte in every QUIC packet is defined as having a fixed value in QUIC version 1 QUIC. <del> The purpose of having a fixed value is to allow QUIC to be efficiently distinguished from other protocols; see DEMUX for a </del> <ins> The purpose of having a fixed value is to allow endpoints to efficiently distinguish QUIC from other protocols; see DEMUX for a </ins> description of a system that might use this property.  As this bit can identify a packet as QUIC, it is sometimes referred to as the "QUIC Bit".

change makes the task of identifying QUIC more difficult without cooperation of endpoints.  This sometimes works counter to the security goals of network operators who rely on network <del> classification to identify threats. </del> <ins> classification to identify threats; see Section 3.1 of MANAGEABILITY for a more comprehensive treatment of this topic. </ins> 5.
Change:
Get one from IANA
I'll ask for 0x70 9a 50 c4 .
Feedback from NAME was that you should do that after publishing a revision with that number in it. I second that.

Discussion:
specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes: <del> The version field of long headers is TBD.  Note: Unless this document is published as an RFC, implementations should use the provisional value 0xff020000, which might change with each edition of this document. </del> <ins> The version field of long headers is 0x709a50c4. </ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to:

This document requests that IANA add the following entry to the QUIC version registry: <del> Value: TBD </del> <ins> Value: 0x709a50c4 </ins> <del> Status: permanent </del> <ins> Status: provisional </ins> Specification: This Document