jiebi/CodeConvo huggingface dataset:
Change:
uses a series of consecutive sequence numbers without creating holes. <ins> 7.1.2. The ACK Delay field of the ACK frame is relative to the largest acknowledged packet number (see Section 13.2.5 of QUIC-TRANSPORT). When using paths with different transmission delays, the reported host delay will most of the time relate to the path with the shortest latency.  To collect ACK delays on all the paths, hosts should rely on time stamps as described in QUIC-Timestamp. </ins> 7.2. If the multipath option is enabled with a value of 2, each path has

Discussion:
To estimate path delay accurately, loss recovery of QUIC utilizes the ACK Delay field of ACK frame (see ). However, when single packet number space is being used, it is difficult for the sender to obtain ACK Delay for all the paths being used, because ACK Delay is reported only for the packet carrying the largest packet number. It is the only the ACK delay of the path with shortest path-delay that can be reported. I think it might be a good idea to acknowledge this shortcoming in the documentation, so that we do not miss the downside when we compare the approaches (or when we try to address the shortcomings of the single packet number space approach).
I agree that this issue should be addressed in the current draft. Regarding the problem itself, I think using the one-way timestamp can solve this problem for single PN.
I believe this is discussed in section 5: URL Can you propose a PR if you think more text is useful?!
I think Section 5 should relate to both packet number space designs, while this issue is specific to one. I summarised the discussion in .
We move section 5 from the single packet number section into an own section, as we agreed that it is applicable to both cases as we don't require ack to be send on the same path and the packet was received. I also don't understand the point about being only able to measure the shortest path with a single PN space. It kind of randomly depends on with packet you ack as discussed in section 5. If we want to add some additional consideration we should probably add them to section 5.
Yes, there is an issue with single space here. Suppose that the sender sends packets 1 and later 3 on path long delay path A, packets 2 and later 4 on short delay path B. The receiver will get the packets in the order 2, 1, 4, 2. The ACK will be: ACK, highest = 2. Ack delay = time ACK sent minus time 2 received. ACK, highest = 2, also ACK 1. Ack delay = time ACK sent minus time 2 received. ACK, highest = 4, also ACK 2 and 1. Ack delay = time ACK sent minus time 4 received. ACK, highest = 4, also ACK 3, 2 and 1.

Ack delay = time ACK sent minus time 4 received. The RTT of path B will be evaluated precisely, with the help of the ACK delay. The RTT of path A will be evaluated less precisely. When the ACK of 2 and 1 is received, the sender cannot use the ACK delay to narrow the estimate of the RTT of path A. Same for packet 4.
Looks good.
Change:
4. <del> Against a passive attacker AdvP or active attacker AdvA, desired privacy properties might include: Peer Authentication.  The client's view of the peer identity should reflect the server's identity.  If the client is authenticated, the server's view of the peer identity should match the client's identity.  Moreover, the client's view of the peer identity should not match its own identity Selfie. Channel Binding.  External PSKs should include channel bindings from any protocol run a priori to provision the PSKs. Identity Confidentiality.  AdvP should learn no information about the external PSK or its identifier.  Similarly, AdvA should be unable to replay ClientHello messages and learn information about the PSK. Identity Unlinkability.  AdvP should be unable to link two or more connections together that use the same external PSK. Unlinkability for the PSK receiver, i.e., ensuring that the recipient of a ClientHello with a given PSK k cannot link k to a prior session, is out of scope.  (PSKs are explicitly designed to support mutual authentication.) 4.1. As discussed in use-cases, there are use cases where multiple clients or multiple servers share a PSK.  In such cases, TLS only authenticates the entire group.  Not only can a compromised group member impersonate another group member, but a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways. The TLS external PSK authentication mechanism implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and that these never switch roles.  If this assumption is violated, standard TLS 1.3 security properties are invalidated. TLS 1.3 tries to maintain the following eight security properties: </del> <ins> TLS 1.3 tries to maintain the following seven security properties: </ins> Matching the same session keys;

Discussion:
Addresses , , and .
... and don’t prohibit or otherwise interfere with PAKEs. (Though we may want to state that PAKEs should produce PSKs that adhere to this limit if run out of band.)
Fixed in .
Fixed in .
Start with the general recommendation and invariant: Identities should be unique across all nodes, roles, and keys. For each use case, how a part of the invariant is violated and leads to one of the known attacks.
Fixed in .
Change:
A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an <del> immediate acknowledgement when the peer receives CE-marked packets (out-of-order).  0 represents 'false' and 1 represents 'true'. A 1-bit field representing a boolean truth value.  This field is set to "true" by an endpoint that does not wish to receive an </del> immediate acknowledgement when the peer receives a packet out of order (out-of-order). 0 represents 'false' and 1 represents 'true'.

Discussion:
With the last draft(-03), there is a change on ACKFREQUENCY frame format (Remove Ignore CE and Reordering Threshold ) may be need change minack_delay value for detect what frame format do you need to use for decode ?
I think we should change the minackdelay Transport Param codepoint, which is currently 0xff03de1a, maybe to 0xff04de1a.
yes, I also thought about this and then forgot to bring it up. Maybe we should even submit a new version with a different number right tomorrow.
Submitting and then revving the version SGTM. I can't see a reason not to bump the codepoint, so please merge my PR if you agree NAME
Following up on discussion in issue and . It is not clear if this signal is needed at all. CE should always be provided as soon as possible. Only follow-up CE in the same RTT might be deployed. However, this seem to be part of the ECN specification (e.g. as discussed for AccECN) and not necessarily in scope for this document, as it is not clear why a sender signal for this is needed.
Thanks for filing this, I'll plan to include this in slides for Philadelphia.
Discussion at IETF 114: Remove Ignore_CE; we can add a transport parameter (possible) if someone really wants this feature.
Change:
changes from a fork (or any branch) into their copy. Editors SHOULD make pull requests for all substantial changes rather <del> than committing directly to the "master" branch of the repository. Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </del> <ins> than committing directly to the "master" branch of the repository.  A pull request creates an artifact that records the reasons for changes and provides other contributors with an opportunity to review the change.  Pull requests that address substantive issues SHOULD mention the issue they address in the opening comment. </ins> This document assumes that there is a unified effort on a document, all concentrated on a git "master" branch.  More

Discussion:
Section 4.2 says "Editors SHOULD make pull requests for all substantial changes rather than committing directly to the "master" branch of the repository." Adding a short explanation will help make this more likely to happen.
Change:
empty nodelist is a valid query result. A segment operates on each of the nodes in its input nodelist in <del> turn, and the resultant nodelists are concatenated to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </del> <ins> turn, and the resultant nodelists are concatenated in the order of the input nodelist they were derived from to produce the result of the segment.  A node may be selected more than once and appears that number of times in the nodelist.  Duplicate nodes are not removed. </ins> A syntactically valid segment MUST NOT produce errors when executing the query.  This means that some operations that might be considered

Discussion:
Add clarifications that the input nodelist provides the outer order, the segments provide a middle-level order, and selectors (if multiple) provide the inner order. This may have been obvious to some readers, but now should be obvious to more, including yours truly.
I don't think the example for in Table 17 is right. URL It says: It should be: Note that the descendants list puts out before and . The wildcard selector then has no choice but outputting , , , .
Nice catch! The example needs fixing as does the ordering note below Table 17.
I let the computer do the catching :-) Do you want to make these changes? I'd do a new issue then. (And wait a bit for Greg to catch up.)
NAME Yes, I'm happy to do that and please do create a new issue. I won't be able to fix it before the weekend at the earliest though.
URL
LGTM thanks. Semantics unchanged, but hopefully a lot clearer.
Change:
ICE agents can implement this procedure in any way as long as it produces equivalent results.  An implementation may for instance pre- <del> register mDNS hostnames by executing steps 3 to 6 and prepopulate an ICE agent accordingly.  By doing so, only step 7 of the above </del> <ins> register mDNS hostnames by executing steps 3 to 5 and prepopulate an ICE agent accordingly.  By doing so, only step 6 of the above </ins> procedure will be executed at the time of gathering candidates. <del> An implementation may also detect that mDNS is not supported by the available network interfaces.  The ICE agent may skip steps 3 and 4 and directly decide to not expose the host candidate. </del> <ins> In order to prevent web applications from using this mechanism to query for mDNS support in the local network, the ICE agent SHOULD still provide mDNS candidates in step 6 even if the local network does not support mDNS or mDNS registration fails in step 4. </ins> This procedure ensures that an mDNS name is used to replace only one IP address.  Specifically, an ICE agent using an interface with both

Discussion:
Fixes URL
An implementation should probably expose mDNS candidates to a page regardless of successful registration or mDNS support in the network.
Change:
Diffie-Hellman DH parameters for both clients and servers are encoded in the opaque key_exchange field of a KeyShareEntry in a KeyShare structure.  The opaque value contains the Diffie-Hellman public value <del> (dh_Y = g^X mod p), encoded as a big-endian integer. </del> <ins> (dh_Y = g^X mod p), encoded as a big-endian integer, padded with zeros to the size of p. Note: For a given Diffie-Hellman group, the padding results in all public keys having the same length. </ins> %%% Key Exchange Messages opaque dh_Y<1..2^16-1>;

Discussion:
TLS 1.2 did not specify this and some implementations have sporadic interoperability issues as a result. Specify that, in TLS 1.3, public keys should be zero-padded. This is believed to be the more compatible TLS 1.2 variant, and having cryptographic messages be fixed-width fields where possible (not that it matters for public keys) seems preferable to saving one byte 1/256 of the time.
(Er, that should say "DHE public keys". I'll go do a force-push to fix the commit description.)
We seem to have reached consensus that the record layer will use the AEAD form only. The stream and CBC forms will be removed.
Fixed.
Change:
If corr (METHOD_CORR mod 4) equals 2 or 3, C_R is omitted, otherwise C_R is not omitted. <del> Compute the transcript hash TH_3 = H(TH_2 , CIPHERTEXT_2, data_3) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence. </del> <ins> Compute the transcript hash TH_3 = H( H(TH_2, CIPHERTEXT_2), data_3 ) where H() is the hash function in the selected cipher suite.  The transcript hash TH_3 is a CBOR encoded bstr and the input to the hash function is a CBOR Sequence.  Note that H(TH_2, CIPHERTEXT_2) can be computed and cached alredy in the processing of message_2. </ins> Compute an inner COSE_Encrypt0 as defined in Section 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in

Discussion:
This addresses . I don't think we need to include names for the intermediary hashes.
Change:
Indicates that x can be any length from A to B; A can be omitted to indicate a minimum of zero bits and B can be omitted to indicate no set upper limit; values in this format always end on <del> an octet boundary </del> <ins> an byte boundary </ins> Indicates that x has a fixed value of C with the length described by ?, as above

Discussion:
Maybe leftovers from , or newly added text.
I'm sure the document was touched by his noodly appendage of the Octocat :octocat:
How did those slip through!?Yes, I think these are mostly new / imported from other docs.Thanks, NAME !
Change:
payload, the packet number length, the source connection ID length, and the token length need to be extracted.  The packet number length is defined by the seventh and eight bits of the header as described <del> in Section 17.2 of QUIC-TRANSPORT, but is obfuscated as described in </del> <ins> in Section 17.2 of QUIC-TRANSPORT, but is protected as described in </ins> Section 5.4 of QUIC-TLS.  The source connection ID length is specified in the byte after the destination connection ID.  The token length, which follows the source connection ID, is a variable-length

Discussion:
The RFC 9000 term is "long header packet"; I'm not a fan of adding hyphenation
ah, right. should we change "long packet header" to "long header" instead?
yes please! That would be consistent with how the terms are used in RFC 9000 (and elsewhere in this document)
done...
Change:
If a new ratchet passed the decryption, all previous ratchets are deleted. <del> 3.2.6.2. </del> <ins> 3.3.5.2. </ins> Frame will set the key immediately on the decrypts when it is received and destroys the old key material, so if the key manager

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
multiple algorithms has been demonstrated in some cases to leak information about that key, provide the opportunity for attackers to forge integrity tags, or gain information about encrypted content. <del> Binding a key to a single algorithm prevents these problems.  Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure.  In addition to checking that algorithms are correct, the key form needs to be checked as well.  Do not use an 'EC2' key where an 'OKP' key is expected. </del> <ins> Binding a key to a single algorithm prevents these problems. Key creators and key consumers are strongly encouraged not only to create new keys for each different algorithm, but to include that selection of algorithm in any distribution of key material and strictly enforce the matching of algorithms in the key structure to algorithms in the message structure.  In addition to checking that algorithms are correct, the key form needs to be checked as well.  Do not use an 'EC2' key where an 'OKP' key is expected. </ins> Before using a key for transmission, or before acting on information received, a trust decision on a key needs to be made.  Is the data or

Discussion:
Remove the sections from the Examples Applenix that were blank, clean up the Security Considerations, and narrow the table in the IANA considerations.
Looks good to me! Thanks! Let us know if you want us to merge it or you plan to do that yourself.
Change:
any distinction between a Trustworthiness Claim with enumeration '0', and no Trustworthiness Claim being provided. <del> Value 1: The Evidence received contains unexpected elements which the Verifier is unable to parse.  An example might be that the wrong type of Evidence has been delivered. </del> <ins> Value 1: The Evidence received contains unknown elements which the Verifier is unable to evaluate.  An example might be that the wrong type of Evidence has been delivered.  Another case is that of Evidence coming from a composite Attester: a Verifier may only understand only part of it and leave as "unknown" the Trustworthiness claims related to features it can't appraise. </ins> Value -1: A verifier malfunction occurred during the Verifier's appraisal processing.

Discussion:
Include changes from Sergei's semantic musings.
a little late, but this is an easy oneLGTM, I have inlined an editorial suggestion.
Change:
server can generally be confirmed by an on- path observer.  An attempted connection after Retry can be detected by correlating the token on the Retry with the token on the subsequent Initial packet <del> and the Destination Connection ID of the new Initial packet. </del> <ins> and the destination connection ID of the new Initial packet. </ins> 3.3.

Discussion:
We've not been capitalizing this in the main spec; so nor should this document. I've fixed those cases that I've touched in my upcoming PR, but it's going to need more work to clean up properly.
Yep, will do that after we merged the PRs. Thanks!
Change:
5.1. "dohpath" is a single-valued SvcParamKey whose value (both in <del> presentation and wire format) MUST be a URI Template RFC6570 encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </del> <ins> presentation and wire format) MUST be a URI Template in relative form (RFC6570, Section 1.1) encoded in UTF-8 RFC3629.  If the "alpn" SvcParam indicates support for HTTP, "dohpath" MUST be present.  The URI Template MUST contain a "dns" variable, and MUST be chosen such that the result after DoH template expansion (Section 6 of RFC8484) is always a valid and functional ":path" value (RFC9113, Section 8.3.1). </ins> When using this SVCB record, the client MUST send any DoH requests to the HTTP origin identified by the "https" scheme, the authentication

Discussion:
Section 5.1 says this: The examples are all like this: RFC 6570 says this: I assume that we don't want passed in the SVCB record. Should we clarify that MUST be in relative form, i.e., just the path portion of the URI?
As a normative matter, I think this is already settled in the text, but I'm happy to improve clarity of the description.
Yeah, I think this technically covers it (), but it would be nice to say something at the start of the paragraph to specify that this is just a path segment of the URL.
Change:
The REGISTER_DATAGRAM_CONTEXT capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer of the encoding and semantics of datagrams associated with a given context <del> ID.  Its Capsule Data field consists of: </del> <ins> ID. </ins> The context ID to register.

Discussion:
The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.
Change:
the recovery mechanism used by a flow cannot be known by the network and therefore reordering tolerance should be considered as unknown. <ins> Note that the 5-tuple of a QUIC connnection can change due to migration.  In this case different flows are observed by the path and maybe be treated differently, as congestion control is usualy reset on migration (see also sec-flow-association). </ins> 4.9. Datagram Packetization Layer PMTU Discovery (PLPMTUD) can be used by

Discussion:
Section 4.8 of manageability draft expects that a per-flow basis DSCP and ECMP routing policy is used to ensure same treatment for all the packets belonging to same QUIC connection. I was wondering how does path migration impacts this? As the new path ,potentially via another network, has no idea about QUIC connection insuring all packets belonging to the same QUIC connection get uniform treatment will be difficult. what am I missing here?
During path migration the congestion control is reset and therefore there is no assumption anymore that those packets need to be treated similarly.
Ok then packets belonging to same QUIC connection can be treated differently after path migration. I think it would be good to clarify it.
This is effectively already what the manageability draft says because it says QoS handling should be applied on a per flow basis where a flow is the 5 tuple. If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID.
NAME can we close this issue?
Potentially yes, but would have been better to put a ref. here to the section where this "If there is a path migration event, the 5-tuple changes. The path does need to be QUIC aware and should not use the CID." is discussed. if things are not discussed or referred in one place then one has to infer the same reasoning/conclusion, which I think not always obvious.
Okay, I added another clarifying sentence and a reference to section 3.5 in PR
Change:
An endpoint MUST treat the receipt of a frame of unknown type as a connection error of type FRAME_ENCODING_ERROR. <del> All QUIC frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </del> <ins> All frames are idempotent in this version of QUIC.  That is, a valid frame does not cause undesirable side effects or errors when received more than once. </ins> The Frame Type field uses a variable-length integer encoding (see integer-encoding) with one exception.  To ensure simple and efficient

Discussion:
Less detail above, but a pointer to what follows.

Table 3: Frame Types The notation used in the table took a while to figure out. A little more explanation, and possibly before the table itself might make it clearer.
One suggestion, but LGTM