jiebi/CodeConvo huggingface dataset:
Code change:
both were then selected as the default TCP congestion controllers in Linux, and both were deployed globally. <del> The point mentioned in tcp-behavior about TCP congestion controllers being implemented in operating system kernels is different with QUIC. Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features," and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications. It is worth noting that streaming operators using HTTP/3, carried over QUIC, can expect more frequent deployment of new congestion controller behavior than has been the case with HTTP/1 and HTTP/2, carried over TCP. </del> <ins> The point mentioned in reliable-behavior about TCP congestion controllers being implemented in operating system kernels is different with QUIC.  Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features," and to meet this expectation, many implementers have chosen to implement QUIC in user space, outside the operating system kernel, and to even distribute QUIC libraries with their own applications.  It is worth noting that streaming operators using HTTP/3, carried over QUIC, can expect more frequent deployment of new congestion controller behavior than has been the case with HTTP/1 and HTTP/2, carried over TCP. </ins> It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly

Related discussion:
text: Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section
Code change:
"Upgrade". the response SHALL include a single "Upgrade" header with value <del> "masque-udp". </del> <ins> "connect-udp". </ins> the response SHALL NOT include any Transfer-Encoding or Content- Length header fields.

Related discussion:
text: Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.
Code change:
and header protection, as a connection error of type PROTOCOL_VIOLATION.  Discarding such a packet after only removing header protection can expose the endpoint to attacks; see <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> The next bit (0x04) of byte 0 indicates the key phase, which allows a recipient of a packet to identify the packet protection

Related discussion:
text: There are three places which refer to "Section 9.3 of QUIC-TLS". I think they should refer to "Section 9.5 of QUIC-TLS".
Thanks!
Code change:
constrain the types of information for which the trust anchor is authoritative."  The trust anchor may be a certificate or it may be a raw public key along with additional data if necessary such as its <del> public key algorithm and parameters. </del> <ins> public key algorithm and parameters.  In the context of this document, a trust anchor may also be a symmetric key, as in TCG-DICE- SIBDA or the symmetric mode described in I-D.tschofenig-rats-psa- token. </ins> Thus, trusting a Verifier might be expressed by having the Relying <del> Party store the Verifier's public key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </del> <ins> Party store the Verifier's key or certificate in its trust anchor store, or might be expressed by storing the public key or certificate of an entity (e.g., a Certificate Authority) that is in the Verifier's certificate path.  For example, the Relying Party can </ins> verify that the Verifier is an expected one by out of band establishment of key material, combined with a protocol like TLS to communicate.  There is an assumption that between the establishment

Related discussion:
text: Throughout the document the term "trust anchor" is meant in the to be a public key and associated (meta)data. This definition does not cover attestation schemes based on symmetric crypto, e.g., , and Arm PSA, and should be extended to also cover such cases.
Was there specific text that you believe needs to be changed?
yes, we identified at least two places: §7.1 and §12.4.
Reads great to me. Any other opinions?
Code change:
The output of the decryption is the server ID that the load balancer uses for routing. <del> 4.3.3. </del> <ins> 4.2.3. </ins> When generating a routable connection ID, the server writes arbitrary bits into its nonce octets, and its provided server ID into the

Related discussion:
text: by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.
Code change:
5. Several types of ciphers have been defined for use with TLS and DTLS <del> and the MAC calculation for those ciphers differs slightly. </del> <ins> and the MAC calculations for those ciphers differ slightly. </ins> <del> This specification modifies the MAC calculation defined in RFC6347 and RFC7366 as well as the definition of the additional data used with AEAD ciphers provided in RFC6347 for records with content type </del> <ins> This specification modifies the MAC calculation as defined in RFC6347 and RFC7366, as well as the definition of the additional data used with AEAD ciphers provided in RFC6347, for records with content type </ins> tls12_cid.  The modified algorithm MUST NOT be applied to records that do not carry a CID, i.e., records with content type other than tls12_cid.

Related discussion:
text: This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.
Code change:
3.2. <del> This document focuses on QUIC version 1, and this section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </del> <ins> This document focuses on QUIC version 1, and this Connection Confirmation section applies only to packets belonging to QUIC version 1 flows; for purposes of on-path observation, it assumes that these packets have been identified as such through the observation of a version number exchange as described above. </ins> Connection establishment uses Initial and Handshake packets containing a TLS handshake, and Retry packets that do not contain

Related discussion:
text: This goes to the end of "Server Name Indication" Some changes are attempts at clarifications, but I could have incorrectly clarified something, so feel free to reject changes.
Code change:
7.1.2. <ins> When sending to a zero-length CID receiver, senders may receive acknowledgements that combine packet numbers received over multiple paths.  However, even if one packet number space is used on multiple path the sender MUST maintain separate congestion control state for each path.  Therefore, senders MUST be able to infer the sending path from the acknowledged packet numbers, for example by remembering which packet was sent on what path.  The senders MUST use that information to perform congestion control on the relevant paths, and to correctly estimate the transmission delays on each path.  (See ack-delay-and-zero-length-cid-considerations for specific considerations about using the ACK Delay field of ACK frames, and ecn-handling for issues on using ECN marks.) Loss detection as specified in QUIC-RECOVERY uses algorithms based on timers and on sequence numbers.  When packets are sent over multiple paths, loss detection must be adapted to allow for different RTTs on different paths.  When sending to zero-length CID receivers, packets sent on different paths may be received out of order.  Therefore senders cannot directly use the packet sequence numbers to compute the Packet Thresholds defined in Section 6.1.1 of QUIC-RECOVERY. Relying only on Time Thresholds produces correct results, but is somewhat suboptimal.  Some implementations have been getting good results by not just remembering the path over which a packet was sent, but also maintaining an order list of packets sent on each path.  That ordered list can then be used to compute acknowledgement gaps per path in Packet Threshold tests. 7.1.3. </ins> 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

Related discussion:
text: Since NAME prodded me, we now have a PR for the "unified" proposal.
I totally agree with Christian that the issue is about "support for multipath and NULL CID", and the solution that Christian suggested looks really great! It both takes advantage of multiple spaces, and support NULL CID users without affect the efficiency of ACK arrangements. Besides, the solution is more convenient for implementations, because If both endpoints uses non-zero length cids, endpoints only need to support multiple spaces, and if one of the endpoints use NULL CID, it could use single pn space in one direction and could support NULL CID and multipath at the same time.
Very high level summary of IETF-113 discussion seems that there is interest and likely support for the unified solution (review minutes for further details).
Code change:
7.3.4. <del> This method is indicated by "jws" in the "proof" field.  A JWS RFC7515 object is created as follows: </del> <ins> This method is indicated by the method value "jws".  This method defines no additional parameters.  A JWS RFC7515 object is created as follows: </ins> To protect the request, the JWS header contains the following claims.

Related discussion:
text: Expands the key parameter to allow it to be an object or a string, to facilitate methods with multiple parameters such as HTTPSig.
To edit notification comments on pull requests, go to your .
Some key proofing methods have additional options that could be signaled in the GNAP protocol structure. Notable, HTTP Message Signatures has the ability to use different HTTP Signing Algorithms and different HTTP Digest Algorithms. The field could be changed to an object to accomodate this kind of use, allowing each proofing method to define its own parameters: Each method can also define "Default" values for missing parameters, allowing this to collapse in the simple case back to a string as it is today: These string values would have a deterministic expansion defined in the core protocol.
Note that the httpsig document itself wavers between and and does not require either of them. Though maybe this is OK if the current document makes mandatory for the appropriate cases.
There are some updates pending in the Digest draft -- once that's out, we'll reference using as that's the most appropriate for our use case, and examples will be updated.
Code change:
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously <del> received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID. </del> <ins> received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. </ins> 19.16.

Related discussion:
text: If you drop the first paragraph, this is just an editorial fix as far as I'm concerned. That is, not sending a frame that was previously sent is not a change. And - assuming that you dump it - "immediately" has no defined meaning anyway.
NAME I'm happy to drop the first paragraph, and I'm glad to hear that it's editorial. Two people on our team took the existing text to mean that we had to send RCID after receiving NCID even though we'd previously retired that sequence number. Update coming soon.
NAME Feel free to change to "editorial"
This is a small point, but it's pointlessly creating pain in our implementation and possibly some others. In Sec 19.15 (NEWCONNECTIONID frame): IMO this is poorly formulated. If the receiver has already sent an RCID frame for the sequence number and that RCID has been acked, it may have thrown away state for that sequence number and shouldn't have to resend a frame the peer has received. In particular, a buggy or malicious peer might send a very old sequence number, or the NCID receiver might have preemptively retired a sequence number it hadn't seen when it got the retire-prior-to field. Simply appending 'if has not already done so' to the text above would do the trick I think. I'm happy to file a PR unless most people think this is a terrible idea.
As a related point, it would be useful to say that an NCID receiver SHOULD NOT immediately retire old CIDs solely as the result of the NCID frame, except when instructed by Retire-Prior-to. This can lead to infinite loops if the peer tries to keep a specific number of CIDs available.
I think this would be a nice clarification. I think we already prohibit such behavior through the use of activeconnectionidlimit TP. Section 5.1.1 states: endpoints store received connection IDs for future use and advertise the number of connection IDs they are willing to store with the activeconnectionidlimit transport parameter. To paraphrase, by using the TP, an endpoint willing to retain N active connection IDs prohibits the peer from sending more than N.
I was probably unclear. For a while, our implementation was doing something dumb: each time it got a new CID, it started using it and retired all previous ones regardless of Retire Prior To.
Code change:
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously <del> received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID. </del> <ins> received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. </ins> 19.16.

Related discussion:
text: This created infinite loops where the client was trying to make sure that we always had two CIDs. We should probably warn against that. Please see if the text in the PR is clear enough.
Taking a look at the PR, I'm finding the proposed text to be a bit unclear, too. Based on the discussion on the list, this seems to be a misreading of the text itself. From the list: I don't believe that this is actually what the text says. The text says: This to me reads as "If you said everything below CID 10 is done, and then you send me CID 8, I must immediately send a RCID frame for 8 since I can't use it". I don't believe that there is any CID-specific state required at all for this. You do need to store the current highest value that you've ever seen for RPT, which is a single integer, I'll call it . Beyond that, when you get a NCID frame, you check the sequence number. If it's less than , you should immediately enqueue (which I think might be a reasonable wording change to make, since immediately seems to have caused concern when the intent was that you put it on the tracks leaving the station, not that you force the train out the door before it's allowed) a RCID frame for that sequence number. Note that a RCID frame contains a single value, the sequence number of the connection ID being retired, which incidentally is contained by the NCID frame you're responding to. We can argue as to whether or not you should bother to send RCID again when the same frame has been acked, but (a) storing that is actually more state and (b) we're working pretty hard to avoid tracking ACKs of packets. I might be missing something here -- can you help me understand the concern about storing state in order to meet the requirements of this text?
Yes, I concede that the original email was garbled. I read the original text the same way you do. The issue is that if I decide to retire immediately without actually having the sequence number, that should be sufficient. Making me send it again after the NCID is gratuitous, and in at least one implementation creates state solely to track this corner case.
Ah cool, that's excellent then!
Code change:
An endpoint that receives a NEW_CONNECTION_ID frame with a sequence number smaller than the Retire Prior To field of a previously <del> received NEW_CONNECTION_ID frame MUST immediately send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID. </del> <ins> received NEW_CONNECTION_ID frame MUST send a corresponding RETIRE_CONNECTION_ID frame that retires the newly received connection ID, unless it has already done so for that sequence number. </ins> 19.16.

Related discussion:
text: :) What's the state that gets created to track that case? If you retired them all upon getting RPT without checking to see if you had them yet, don't you still have to keep track of the RPT value or which ones you've already retired? I'm probably missing some other piece of state in this case...
I think what an endpoint is required to track are: active connection IDs sequence number of connection IDs that are being retired (but are yet to be acknowledged) When receiving a NCID frame with RPT, an endpoint checks if there are any active CIDs below the RPT, and retires them. I do not think an endpoint has to track RPT, though admittedly, I haven't implement them (yet).
NAME what you suggest would certainly work. However, a malicious peer could send an infinite number of NCIDs as long as it kept advancing rpt and didn't ack RCIDs, spiraling the state upwards. To avoid this, we keep a window of unacked but retired sequence numbers and construct RCID from that. That's why having an NCID come in well below the window results in additional state for us.
NAME Exactly. We have an issue for that problem: . Agreeing on what to do to resolve the unbounded state problem might help resolving this issue too.
Taking this as editorial based on the proposal (and promised tweaks).
Looks fine to me, though I do think it's better with some kind of language to send it sooner rather than later.
Code change:
MUST be able to dereference or process the key information in order to be able to sign the request. <ins> OPTIONAL.  A set of flags that represent attributes or behaviors of the access token issued by the AS. The values of the "flags" field defined by this specification are as follows: This flag indicates whether the token is bound to the client instance's key.  If the "bearer" flag is present, the access token is a bearer token, and the "key" field in this response MUST be omitted.  If the "bearer" flag is omitted and the "key" field in this response is omitted, the token is bound the request-client in its request for access.  If the "bearer" flag is omitted, and the "key" field is present, the token is bound to the key and proofing mechanism indicated in the "key" field. </ins> OPTIONAL.  Flag indicating a hint of AS behavior on token <del> rotation.  If this flag is set to the value "true", then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is set to the boolean value "false" or is omitted, the client instance can </del> <ins> rotation.  If this flag is present, then the client instance can expect a previously-issued access token to continue to work after it has been rotate-access-token or the underlying grant request has been continue-modify, resulting in the issuance of new access tokens.  If this flag is omitted, the client instance can </ins> anticipate a given access token will stop working after token rotation or grant request modification.  Note that a token flagged as "durable" can still expire or be revoked through any normal

Related discussion:
text: URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.
Code change:
8. This document makes multiple registrations in the registries defined <del> by HTTP3.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </del> <ins> by RFC9114.  The allocations created by this document are all assigned permanent status and list a change controller of the IETF and a contact of the HTTP working group (ietf-http-wg@w3.org). </ins> 8.1. This document specifies two settings.  The entries in the following table are registered in the "HTTP/3 Settings" registry established in <del> HTTP3. </del> <ins> RFC9114. </ins> For formatting reasons, the setting names here are abbreviated by removing the 'SETTINGS_' prefix.

Related discussion:
text: These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.