jiebi/CodeConvo huggingface dataset:
Change:
fields, "Retry-After" MUST take precedence and "RateLimit-Reset" MAY be ignored. <ins> This specification does not mandate a specific throttling behavior and implementers can adopt their preferred policies, including: slowing down or preemptively backoff their request rate when approaching quota limits; consuming all the quota according to the exposed limits and then wait. </ins> 8. 8.1.

Discussion:
specific throttling behavior is out of scope FAQ 8 integrated in RateLimit-Remaining and Receiving Ratelimit fields
We used the Limit and Remain values in one of our client applications that was migrated from a legacy SOAP service to our REST based API in order to ensure we never get a 429 response (this is because the legacy code could not gracefully retry requests without major refactoring). When we get to 80% of quota (20% Remain) we start respecting the value in the Reset header. In section 7 you touched on a concept ‘A client SHOULD NOT exceed the "quota-units" expressed in "RateLimit-Remaining" before the "time-window" expressed in "RateLimit-Reset".’ We don't want to mandate a strict behavior on client, but we can surely add this sentence as an example behavior. The current spec allows comments, so you can already do it. The spec allows to address this use-case transparently, by artificially lowering the values provided in the fields.
We should probably integrate and remove since it's already in the spec.
This is something I quickly commented on URL but the alternative of dynamically modifying the values as the rate saturates is fairly reasonable, so those informational parameters might as well be part of an extension document.
Change:
client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. <ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. </ins> A server MAY send a CONNECTION_CLOSE frame with error code PROTOCOL_VIOLATION in response to an Initial packet it receives from a client if the UDP datagram is smaller than 1200 bytes.  It MUST NOT

Discussion:
This won't necessarily prevent fragmentation from happening, but it's the best we can do. I didn't REQUIRE dropping of fragments, because some systems do that for you, but a SHOULD seems appropriate.
Gorry notes correctly that fragmentation can play poorly with using IW10. If a sender uses a large maxdatagramsize, and if the network fragments, then IW10 can result in substantially larger amplification than 10x. A simple fix here is to say that if the endpoint uses maxdatagramsize larger than 1280 bytes (this is what the transport spec limits it to in the absence of DPLPMTUD), then the endpoint MUST set DF on outgoing packets. This is a problem with RFC 6928 as well, but we should be clear about it for QUIC.
Shouldn't endpoint always set DF for all QUIC packets? TCP does so.
I tend to agree with Praveen here. I think this is something that's under-specified in transport? I believe it should be in section 14: URL
Yeah, this is probably an issue in transport. DF seems like the obvious answer.
That was my first answer, but I thought that might be too intrusive. If we all agree that is a fine response, I'm happy with that. I can write up a PR.
From memory, I think there was once a discussion on DF bit not being accessible in some language interfaces. As such, the formulation should perhaps be that the DF bit SHOULD be set whenever possible. Having a MUST whenever possible could be problematic because possible could involve a lot of complexity.
-- URL
NAME yes, that is exactly the text I am referring to. I'm questioning if that requirement is practically enforceable.
Change:
2.3.2. <del> An SRP Update MUST include zero or more Service Discovery Instructions.  For each Service Discovery Instruction, there MUST be at least one Service Description Instruction.  Note that in the case of SRP subtypes (RFC6763), it's quite possible that two Service Discovery Instructions might reference the same Service Description Instruction.  For each Service Description Instruction there MUST be at least one Service Discovery Instruction with its service instance name as the target of its PTR record.  There MUST be exactly one Host Description Instruction.  Every Service Description Instruction must have that Host Description Instruction as the target of its SRV record.  A DNS Update that does not meet these constraints is not an SRP Update. A DNS Update that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description or Host Description Instructions is not an SRP Update.  A DNS update that contains any prerequisites is not an SRP Update.  Such messages should either be processed as regular RFC2136 updates, including access control checks and constraint checks, if supported, or else rejected with RCODE=REFUSED. In addition, in order for an update to be a valid SRP Update, the target of every Service Discovery Instruction MUST be a Service Description Instruction that is present in the SRP Update.  There MUST NOT be any Service Description Instruction to which no Service Discovery Instruction points.  The target of the SRV record in every Service Description Instruction MUST be the single Host Description Instruction. </del> <ins> An SRP Update MUST contain exactly one Host Description Instruction. In addition, there MUST NOT be any Service Description Instruction to which no Service Discovery Instruction points.  A DNS Update that contains any additional adds or deletes that cannot be identified as Service Discovery, Service Description or Host Description Instructions is not an SRP Update.  A DNS update that contains any prerequisites is not an SRP Update.  An SRP registrar MAY either process such messages are either processed as regular RFC2136 updates, including access control checks and constraint checks, if supported, or MAY reject them with RCODE=REFUSED. </ins> If the definitions of each of these instructions are followed carefully and the update requirements are validated correctly, many

Discussion:
This update removes the constraint in the section titled "Host Description Instruction" that the Host Description instruction must be pointed to by at least one Service Description instruction. It also removes some duplicate constraints from the section titled "Valid SRP Update requirements" and moves the mention of subtypes to the "Service Discovery Instruction" section.
Change:
If separate entities provide the Oblivious Gateway Resource and Target Resource, these entities might need an arrangement similar to that between server and relay for managing denial of service; see <del> dos.  It is also necessary to provide confidentiality protection for the unprotected requests and responses, plus protections for traffic analysis; see ta. </del> <ins> dos. </ins> Nonsecure requests - such those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway and

Discussion:
Especially when we already address this point a few paragraphs above and we then directly contradict it in the next one.
Currently, these normative references are to old document versions. We should link to RFC 9113 and 9114, and probably use the Use [HTTP/2] and [HTTP/3] labels for consistency with the HTTP style guide.
Change:
are limited to the syntax-based normalized form of RFC3986 Section 6.2.2. <del> Blank nodes are unnamed entities.  Literals are non-null CBOR objects that may have a set of properties (e.g. a language tag) attached to them; properties have a (not necessarily unique) URI as their name and a URI or literal as their value. </del> <ins> Blank nodes are unnamed entities.  Literals are CBOR objects. </ins> These triples form a directed multigraph with the subject and object being source and destination, and the predicate a description on the

Discussion:
With direction on its way into a tag (discussion pending -- will it be a dedicated one or inside 38), the only use case we had for properties on literals is gone. I think the whole model is better if we remove them -- anything that can be expressed with properties can also be expressed with tags, but the latter are well defined and understood whereas the former are not. (What does it mean if two properties are on a literal and both are defined but their interaction is not? Tags are clearer there). PR is incomplete, needs a few more alterations.
Change:
exposing information about the target domain to the entire network; or <del> tenants can use 4-tuple routing in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. </del> <ins> tenants can use the 0b11 codepoint in their CIDs (in which case they SHOULD disable migration in their connections), which neutralizes the value of QUIC-LB but preserves privacy. </ins> When configuring QUIC-LB, administrators must evaluate the privacy tradeoff considering the relative value of each of these properties,

Discussion:
The '11' codepoint might be better defined. It would be good, for instance, if a stateful load balancer actually stored the observed CID so that the connection can survive a NAT rebinding.
Actually this is a bit harder than we'd like. If the load balancer is stateless, then the short-header processing would have to be based on the destination connection ID to be robust to NAT rebinding. But then, as the connection ID will change mid-handshake, long-header processing needs a different approach. I don't see how, logically, a stateless LB can maintain consistency between these two results unless we force the unconfigured server to retain most of the client-generated CID.
Having reflected on this a bit more, this is what I think we should do: Keep 0b11 as 4-tuple routing. However Load Balancers MAY observe destination connection IDs and keep state on them, to later survive a NAT rebinding. I see two use cases for 0b11: (1) a general purpose server that always uses QUIC-LB, whether or not it's behind an LB, for simplicity. So when it's not behind a Layer 4 LB it just generates random CIDs except for the first byte. As an added bonus, if there is an unknown L4 LB in front of it the behavior will not be pathological, at least until there's a migration. But in general, the rebinding performance is not all that important. (2) As a panic mode when things are misconfigured or the server has run out of nonces. Again, I'm not sure rebinding performance is super-critical. In other words, if a server is behind an L4 load balancer is and is using 0b11, something has gone very wrong.
Change:
1.2. <ins> draft-09 The maximum permittion record expansion for AEAD has been reduced from 2048 to 256 octets. </ins> draft-08 Remove support for weak and lesser used named curves.

Discussion:
As discussed on list.
Minor suggestions: 1) Explicitly specify the expectation of a "record_overflow" alert after the two "MUST NOT"s. 2) Also drop the issue "OPEN ISSUE" note that's on line 1087-1088. 3) Amend the changelog to mention this. 4) Add a sentence noting the overhead cap has changed to the "Note: In versions of TLS prior to 1.3" paragraph, or elsewhere.
As NAME suggests, I've updated the PR. I have not added the Note. I don't like those. The change log is enough.
Why was the changelog amended as for draft-09? The draft-08 hasn't been published yet. Is it in the progress of being released? (not shown on DataTracker and releases haven't been tagged on GitHub since draft-05)
Pilot error. Please feel free to submit a PR. , Dave Garrett EMAIL wrote:
This is currently 2^{14} + 2048 (in TLSCiphertexT) and then 2^{14} + 1024 later. This is introduced by leaving room for compression. Should we just reduce this entirely across the board. Certainly we don't need to leave room for compression.
Proposal at interim: 256 octets total.
Change:
and try to validate the Certificate message exchanged during a TLS handshake.  This means that middleboxes that don't understand the CompressedCertificate message might misbehave and drop connections <del> that adopt certificate compression. However this is not a problem when using TLS version 1.3 I-D.ietf- tls-tls13 and higher, due to the fact that the Certificate (and thus the CompressedCertificate) message is encrypted, preventing middleboxes from intercepting it. </del> <ins> that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </ins> 7.

Discussion:
We already had the understanding that no one will attempt to deploy the extension for TLS 1.2 and earlier, since it would be plagued with middlebox compatibility issues that TLS 1.3 already faces. However, it was left as supported because there was no cost to supporting it. On the list, David Benjamin has pointed out that: clients have no way to ask for "compress only in TLS 1.3" policy, meaning that they have to assume that a TLS 1.2 connection could attempt to use this extension; clients have to support certificate compression in TLS 1.2 as a result. This adds complexity for no reason, and the problem is easily solved by restricting the extension to 1.3 or higher.
:+1: LGTM
Change:
(IP address, UDP port, client-generated destination Connection ID) remain constant for all packets sent on the same connection. <ins> The Low-Config CID algorithm is dependent on client-generated Destination CIDs in Initial Packets being at least 8 octets in length.  If they are not, the load balancer may not be able to extract a valid server ID to add to its table.  Configuring a shorter server ID length can increase robustness to a change. </ins> While this document does not update the commitments in QUIC- INVARIANTS, the additional assumptions are minimal and narrowly scoped, and provide a likely set of constants that load balancers can

Discussion:
follow-on to , also fixing
NAME asks if there is added value in expressing server ID lengths in bits instead octets. This is a bit of implementation complexity and a lot of churn in the spec and the handful of implementations that exist, but it does give the configuration agent a little more granularity. Does anyone find the value of this granularity to be compelling?
My thinking is that increasing/decreasing the server ID space by 256 is quite a large jump and could make config rotation a bit more complex. Adding an extra bit to the server ID doubles the number of IDs, which is a fairly widely used increase in data structures and algorithms.
While having such fine control would optimize for efficiency, splitting up bytes like this would complicate implementation. I'm also doubt that 1B of overhead is really going to affect anything. Closing this issue due to old age; can reopen if anyone wants to fight it out.
NAME proposed a PCID design that assigns SIDs on the fly instead of having to pre-configure them. There are drawbacks but it has some nice properties.
This is merged, but I'm going to take the question of what we can do with these dueling plaintext designs to the list.
List discussion was not helpful; closing this with the dynamic method still in the draft.
Change:
precompute these obfuscated identities to ease the burden of trial decryption. <del> 10. </del> <ins> 11. </ins> This document makes no IANA requests.

Discussion:
Discussed in Singapore; will merge and add security considerations motivation in a followup to .
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
This seems harmless, but it is predicated on a need to separate keys that I don't understand. Is there more rationale somewhere?
Change:
black-holing an active connection when the address changes. Note that some source ports are assumed to be reflection attack <del> vectors by some servers; see Section 8.1 of I-D.ietf-quic- applicability.  As a result, NAT binding to these source ports can result in that traffic being blocked. </del> <ins> vectors by some servers; see Section 8.1 of QUIC-APPLICABILITY.  As a result, NAT binding to these source ports can result in that traffic being blocked. </ins> 4.7.

Discussion:
as well
There are some outdated references those I goes will go away with further revisions. However, there are duplicate references those I believe need to be fixed manually. -- Duplicate reference: draft-ietf-quic-applicability, mentioned in 'QUIC-APPLICABILITY', was also mentioned in 'I-D.ietf-quic-applicability'. -- Duplicate reference: RFC8899, mentioned in 'RFC8899', was also mentioned in 'DPLPMTUD'.
I noticed that there are references to QUIC I-Ds. Applicability even references both -34 and RFC9000 :smile:
Change:
create a new stream on the given Connection, then attempts to clone a Connection will result in a CloneError: <del> The Protocol Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </del> <ins> The Connection Property "Priority" operates on entangled Connections as in msg-priority: when allocating available network capacity among </ins> Connections in a Connection Group, sends on Connections with higher Priority values will be prioritized over sends on Connections with lower Priority values.  An ideal transport system implementation

Discussion:
When reading the API draft, I noticed that in some places it was still using the outdated term "Protocol Properties" where it actually means Connection Properties or Message Properties. I replaced the terms in this PR. We do still define "Specific Protocol Properties", so I kept these.
Change:
In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This should be the only URL needed to configure clients.  It is a JSON <del> dictionary, whose keys are drawn from the following table and whose </del> <ins> object, whose keys are drawn from the following table and whose </ins> values are the corresponding URLs. There is no constraint on the actual URI of the directory except that

Discussion:
Follow-up to , catches a few more references I initially missed.
I think 'field name' makes more sense... but I'm not really wed to either.
Change:
A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. <del> Relative tradeoffs between the cost of closing and reopening a </del> <ins> Relative trade-offs between the cost of closing and reopening a </ins> connection and trying to keep it open are different; see resumption- v-keepalive.

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the <del> application layer if needed.  Further, TCP without the TCP Fast Open extension does not support 0-RTT session resumption.  TCP Fast Open can be requested by the connection initiator but might no be supported by the far end or could be blocked on the network path. </del> <ins> application layer if needed. Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption. Even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </ins> Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).

Discussion:
Intended to , ,
The draft says section 8 of quic-transport; it's section 13.
It is odd that this section doesn't mention QUIC's robustness to NAT rebinding at all. While this won't work behind 4-tuple load balancers, middlebox timers may be irrelevant depending on the conesequences of the timeout.
While TFO has some 0RTT-like properties, it does not fully replace it, not only because the SYN or option gets scrubbed, but also because you're limited to one packet payload. Also, this ought to mention TLS stacks that offer replay protection. I would think a modern QUIC interface would offer a signal to separate 0RTT from 1RTT data, so that both senders and receivers can manage their application data appropriately.
will be
This is editorial, but the whole introduction is written as if the quic drafts are some early concept kicking around in the working group. This will not age well, and the intro should be worded as if it were already a published RFC. The intro still talks about "HTTP/2 over QUIC" when it's now HTTP/3.
Change:
6.1.3.1. If the STUN transaction generates a 487 (Role Conflict) error <del> response, the agent checks whether it included the ICE-CONTROLLED or ICE-CONTROLLING attribute in the Binding request.  If the request contained the ICE-CONTROLLED attribute, the agent MUST switch to the controlling role if it has not already done so.  If the request contained the ICE-CONTROLLING attribute, the agent MUST switch to the controlled role if it has not already done so.  Once it has switched, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE- CONTROLLING or ICE-CONTROLLED attribute reflecting its new role. Note, however, that the tie-breaker value MUST NOT be reselected. </del> <ins> response, the agent checks whether it included an ICE-CONTROLLED or ICE-CONTROLLING attribute in the associated Binding request.  If the request contained an ICE-CONTROLLED attribute, the agent MUST switch to the controlling role.  If the request contained an ICE-CONTROLLING attribute, the agent MUST switch to the controlled role. Once the agent has switched its role, the agent MUST enqueue the candidate pair whose check generated the 487 into the triggered check queue.  The state of that pair is set to Waiting.  When the triggered check is sent, it will contain an ICE-CONTROLLING or ICE-CONTROLLED attribute reflecting its new role.  The agent MUST NOT change the tie-breaker value. </ins> A change in roles will require an agent to recompute pair priorities (sec-comp-pair-prio), since those priorities are a function of

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
[THIS SECTION TO BE REMOVED BY THE RFC EDITOR.] <ins> Changes in version 12: Addressed a bunch of minor editorial issues based on WGLC feedback. Added text about the use of UTF-8 in CoSWID. Adjusted tag-id to allow for a UUID to be provided as a bstr. Cleaned up descriptions of index ranges throughout the document, removing discussion of 8 biut, 16 bit, etc. Adjusted discussion of private use ranges to use negative integer values and to be more clear throughout the document. Added discussion around resolving overlapping value spaces for version schemes. Added a set of expert review guidelines for new IANA registries created by this document. Added new registrations for the "swid" and "swidpath" URI schemes, and for using CoSWID with SWIMA. </ins> Changes from version 03 to version 11: Reduced representation complexity of the media-entry type and

Discussion:
Fixed typo identified by Alex Nelson. Also removed some extra working text that was accidentally left in an IANA section. This PR will be kept open until the WGLC concludes.