jiebi/CodeConvo huggingface dataset:
Change:
in TLS normally. In order for certificate compression to function correctly, the <del> underlying compression algorithm MUST be deterministic and it MUST output the same data that was provided as input by the peer. </del> <ins> underlying compression algorithm MUST output the same data that was provided as input by the peer. </ins> Since certificate chains are typically presented on a per-server name <del> or per-user basis, the attacker does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </del> <ins> or per-user basis, a malicious application does not have control over any individual fragments in the Certificate message, meaning that they cannot leak information about the certificate by modifying the </ins> plaintext. <del> The implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </del> <ins> Implementations SHOULD bound the memory usage when decompressing the CompressedCertificate message. </ins> <del> The implementations MUST limit the size of the resulting decompressed </del> <ins> Implementations MUST limit the size of the resulting decompressed </ins> chain to the specified uncompressed length, and they MUST abort the <del> connection if the size exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </del> <ins> connection if the size of the output of the decompression function exceeds that limit.  TLS framing imposes 16777216 byte limit on the certificate message size, and the implementations MAY impose a limit that is lower than that; in both cases, they MUST apply the same limit as if no compression were used. </ins> 6.

Discussion:
Update reference.
Almost, but I think I can accept my own suggestions so I'll just do that and merge.
Change:
possible from previous connections that are not entangled with it. Any state generated by this Connection will only be shared with entangled connections.  Cloned Connections will use saved state from <del> within the Connection Group. </del> <ins> within the Connection Group.  This is used for separating Connection Contexts as specified in I-D.ietf-taps-arch. </ins> Note that this does not guarantee no leakage of information, as implementations may not be able to fully isolate all caches (e.g.

Discussion:
Fix terminology in -arch Add minimal connection contexts in -interface
We had not decided that yet: We agreed that the property was sufficient as portable interface for the purpose We did not yet because did nit fix the inconsistencies between Connection Groups in -architecture and -interface So what we could do (als an alternative to this PR) to - Drop the stuff this PR renamed to "Connection Context" from -arch all-together Merge the changes in -arch, but do not include the minimal Connection Context into -interface an try to squish question about the context missing in -interface in later reviews
Connection Groups used to be about state and context sharing as well as entanglement. Now it's about entanglement. We need to rename Connection Groups ("connection contexts"?) in the architecture to replace the existing "group" concept, and to retain "connection group" in the API for entanglement.
Seems like this could be 360 degrees of rotation in our thinking? (which could be OK, NEAT was written to specify both contexts and flow groups). Let's try some definitions here and see if we converge...
I think brings this back in synch again so no need to rename, possibly the last part of this section in architecture should be removed though as we do not have fine-grained control
Did we decide to explicitly introduce this new connection context?
Change:
fails.  For example, if the input is meant to be a bit vectors, then "[2, 1, 0]" is invalid. <ins> Measurement: A single value (e.g., a count) being reported by a client.  Multiple measurements may be grouped into a single protocol input. </ins> Leader: A distinguished aggregator that coordinates input validation and data collection.

Discussion:
The design document discusses "reports" which are a group of measurements being submitted to a DPA instantiation. There should be an entry in the "Terminology" section that explicitly defines a report and how it relates to "measurements" and "inputs".
Thanks for putting the list back in alphabetical order, too!
Change:
policies.  Permanent registrations in this registry are assigned using the Specification Required policy (RFC8126), except for values between 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned <del> using Standards Action or IESG Approval as defined in Section 4.9 and 4.10 of RFC8126. </del> <ins> using Standards Action or IESG Approval as defined in Sections 4.9 and 4.10 of RFC8126. </ins> In addition to the fields in iana-provisional, permanent registrations in this registry MUST include the following fields:

Discussion:
to make RFC Editor diffs smaller
These are manual; if only there were a tool... Diffs in the are all very small, and in each case reflects correction of an existing error or slight adjustment to accommodate limitations in XML (in one case); happy to suppy (CI is broken because of URL).
I just uploaded this to a branch on this repository so that a diff is generated in CI (assuming that I have a little more luck in getting a build to stick). The changes should be visible at URL if CI ever passes. Which of course it has not at this point...
Seems to be working occasionally; I fixed a lint problem, and diffs are now at URL
NAME I'd strongly prefer to keep this PR focused on behind-the-scenes tidying, rather than making an editorial wording choice. Beyond keeping the PR focused, doing this piecemeal is going to miss a large number of instances of "see..." because the changes represented here are only where a specific section is called out; you'd do much better to adjust that language consistently after this PR is applied (when you can do a search for and it should consistently show all instances, whether or not there's a section being referenced). If that's sensible to everyone, I think this is ready; tell me if I missed one of the comments.
NAME Fair enough. This LGTM.
Here are the diffs, since tools is failing so badly (I plan to work around that, but that will take some time). URL I've spotted one problem there already, but it does look good so far.
NAME and NAME I have learned something new about kramdown-rfc2629. Cheers.
NAME
NAME and NAME should approveThanks for doing this, recovery LGTM
Change:
6.4. <ins> DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under resolver.arpa with NODATA. 6.5. </ins> Discovery of network-designated resolvers (DNR, I-D.ietf-add-dnr) allows a network to provide designation of resolvers directly through DHCP RFC2132 RFC8415 and IPv6 Router Advertisement (RA) RFC4861

Discussion:
Addressing
NAME I've bravely stolen some text to meet the additional IANA request.
Resolvers will normally return NXDOMAIN for queries that don't exist, and caches are permitted to treat this as an indication that no records of any type exist at the zone (RFC 8020). That means that it isn't enough for resolvers to synthesize a SVCB response for URL they also have to synthesize a NOERROR response for any other QTYPE on that name. The draft should probably mention that. Credit to NAME for noticing this.
NAME agreed that we could note this, but it's also expected that a client wouldn't be sending out queries for other types on URL, right? In practice, I'm not sure how this would happen.
Yes, but if a cache is shared by multiple clients (be they distinct devices on a network or even distinct apps on a device), a single client could issue a query that causes the shared cache to remember the NXDOMAIN answer. That's a problem whether the source of the query is malicious or just weird.
Fair, so this could be accidental or malicious fallout, not a normal occurrence.
I'd suggest that there should also be a reference to RFC 6303 section 3 - should be considered a "locally resolved domain".
Closed with
Change:
Load balancers SHOULD drop packets with non-compliant DCIDs in a short header. <ins> A QUIC-LB configuration MAY significantly over-provision the server ID space (i.e., provide far more codepoints than there are servers) to increase the probability that a randomly generated Destination Connection ID is non- compliant. </ins> Load balancers MUST forward packets with compliant DCIDs to a server in accordance with the chosen routing algorithm.

Discussion:
Although more complex, the three-pass algorithm seems strictly better.
I like it, but there is some imprecision in the text. I would like to see something about detecting corruption, probably in the load balancer actions.
Change:
correspond to ECH PSKs.  ECH PSKs offered by the client are associated with the ECH name.  The server was unable to decrypt then ECH name, so it should not resume them when using the <del> cleartext SNI name.  This restriction allows a client to reject </del> <ins> plaintext SNI name.  This restriction allows a client to reject </ins> resumptions in auth-public-name. Note that an unrecognized ClientEncryptedCH.record_digest value may

Discussion:
Use the term "plaintext" consistently. Be consistent about the number of spaces following a period. (We'll go with one.) Editorial changes to Sec.1-3.
Change:
The "w" parameter specifies a time window.  Its syntax is a "time- window" defined in time-window. <del> Other parameters are allowed and can be regarded as comments. </del> <ins> Other parameters are allowed and can be regarded as comments.  They ought to be registered within the "Hypertext Transfer Protocol (HTTP) RateLimit Parameters Registry", as described in iana-ratelimit- parameters. </ins> An example policy of 100 quota-units per minute.

Discussion:
Merge three "add to table" into one request to "add these to the table" Create a new registry for quota fields.
looks good!
NAME NAME I made some edits: ad an addressable subsection for iana-ratelimit-parameters add , to iana table reference specification sections in IANA registries removed normative parts from IANA mention IANA table in {{quota-policy}} Could you please PTAL?
ooops I missed your comment :) Ok, let's merge.
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
4.3. <del> QUIC starts a loss epoch when a packet is lost and ends one when any packet sent after the epoch starts is acknowledged.  TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </del> <ins> QUIC starts a loss epoch when a packet is lost.  The loss epoch ends when any packet sent after the start of the epoch is acknowledged. TCP waits for the gap in the sequence number space to be filled, and so if a segment is lost multiple times in a row, the loss epoch may not end for several round trips.  Because both should reduce their congestion windows only once per epoch, QUIC will do it once for every round trip that experiences loss, while TCP may only do it once across multiple round trips. </ins> 4.4.

Discussion:
This isn't critical, but it's clearer and easier to parse. All to the good.
Derrell Piper writes:
The one nit here regards this sentence: This seems right to me. You might rewrite this as: But I don't think that is appreciably better. I think we can close this with no action unless we get some enthusiasm for rewording.
I think the issue is that "epoch starts is" looks like either an extra word or subject/verb agreement error. It's not actually; if you diagram the sentence out, "after the epoch starts" is in a dependent clause and "any packet ... is acknowledged" is correct agreement. That said, the rewording is easier to read because it doesn't look wrong and you don't have to try different possible parsings in your head before you find the one which works. We've tried to avoid trial decryption; let's avoid it in grammar, too.
Thanks, this seems like an improvement to me.
Change:
(possibly updated) lifetime of the registration, independent of whether a "lt" parameter was given. <ins> If the context of the registration is changed in an update explicitly or implicitly, relative references submitted in the original registration or later updates are resolved anew against the new context (like in the original registration). </ins> The update registration request interface is specified as follows: EP -> RD

Discussion:
The first commit tries to get across the difference between the relative references in the serialization and the URIs in the model more clearly. The second commit adds paragraphs to the descriptions of various operations about how and by whom URIs are resolved in those steps.
Change:
when it was able to find an acceptable set of algorithms and groups that are mutually supported, but the client's KeyShare did not contain an acceptable offer.  If it cannot find such a match, <del> it will respond with a "handshake_failure" alert. </del> <ins> it will respond with a fatal "handshake_failure" alert. </ins> Structure of this message:

Discussion:
NAME You addressed the main ambiguity in URL . This fixes a few remaining issues. An itemized list: "handshakefailure" alert is fatal note it must be appended, not just "used", in the selectedgroup description (just using instead of appending creates a downgrade attack due to lack of authentication for this message, as discussed previously) clean up styling of variable names; the dominant style uses no quotes around variable names, but quotes around enum values (granted, this may not be the ideal style, but it is more or less consistently the case elsewhere in the document) note that the same rule as ServerHello applies: no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if "MUST" fails (could be a "SHOULD" error, here)
NAME Repushed commit with changes for comments. Changed description to not say used/amended, but rather describe what it actually represents directly: the group the server intends to negotiate and is requesting a retry for. (we don't need duplicated MUSTs here, and stating its actual meaning more explicitly is preferable) Changed text wrt selected group as suggested.
Rebased on top of PR (which still merges cleanly onto master, as of this moment; this does too) to avoid flip-flopping again on the omit vs. empty KeyShare for retry request.
Change:
signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_algorithms. <del> For historical reasons, the names of some client certificate types include the algorithm used to sign the certificate.  For example, in earlier versions of TLS, rsa_fixed_dh meant a certificate signed with RSA and containing a static DH key.  In TLS 1.2, this functionality has been obsoleted by the supported_signature_algorithms, and the certificate type no longer restricts the algorithm used to sign the certificate.  For example, if the server sends rsa_fixed_dh certificate type and {{sha256, ecdsa}, {sha1, rsa}} signature types, the client MAY reply with a certificate signed with ECDSA-SHA256. </del> New ClientCertificateType values are assigned by IANA as described in iana-considerations. <del> Note: Values listed as RESERVED MUST NOT be used.  They were used in SSL 3.0. </del> Note: It is a fatal "handshake_failure" alert for an anonymous server to request client authentication.

Discussion:
Note: unRESERVEDing SHA-1 and DSA is intentional. The point is that that things which are RESERVED are totally forbidden. Because you can offer SHA-1, we need the code point. If we decide to make DSA MUSTNOT, then I'll mark it reserved and update the text.
On Saturday, October 03, 2015 04:42:44 pm ekr wrote: Agreed. Using the "RESERVED" notation before was a bit iffy and with this new refactoring it has to be changed now. Just need to make sure it's mentioned explicitly that it's restricted.
Change:
fields defined in the table are transported and thus why they have labels. <del> [CREF13] Ilari: Check to see what the curves are renamed to during final publishing.  It appears to be X25519 now. [CREF14] JLS: Do we create a registry for curves?  Is is the same registry for both EC1 and EC2? [CREF15] JLS: Should we use the bignum encoding for x, y and d instead </del> <ins> [CREF13] JLS: Should we use the bignum encoding for x, y and d instead </ins> of bstr? <del> [CREF16] JLS: Looking at the CBOR specification, the bstr that we are </del> <ins> [CREF14] JLS: Looking at the CBOR specification, the bstr that we are </ins> looking in our table below should most likely be specified as big numbers rather than as binary strings.  This means that we would use the tag 6.2 instead.  From my reading of the

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
responds with an error status code and a problem document describing the error. <del> 6.3.2. </del> <ins> 6.3.3. </ins> A client may deactivate an account by posting a signed update to the server with a status field of "deactivated."  Clients may wish to do

Discussion:
Right now, it's not clear when the client needs to agree to the server's terms, and what the server should do if it needs the client to re-agree. This PR addresses both with a dedicated error code and some related behaviors.
Change:
10.1.  URIs <del> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-kem-ids </del> <ins> [1] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </ins> <del> [2] https://www.iana.org/assignments/hpke/hpke.xhtml#hpke-aead-ids </del> <ins> [2] https://iana.org/assignments/media-types </ins> <del> [3] https://iana.org/assignments/media-types [4] https://iana.org/assignments/http-problem-types </del> <ins> [3] https://iana.org/assignments/http-problem-types </ins> Index

Discussion:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...
Change:
endpoint does not support connection migration (migration).  Peers of an endpoint that sets this transport parameter MUST NOT send any packets, including probing packets (probing), from a local <del> address other than that used to perform the handshake.  This parameter is a zero-length value. </del> <ins> address or port other than that used to perform the handshake. This parameter is a zero-length value. </ins> The server's preferred address is used to effect a change in server address at the end of the handshake, as described in

Discussion:
Some infrastructures are likely to load balance on port as well as address.
"Address" has been taken to mean IP and port in other contexts, but no harm in being extra precise here.
Change:
TODO: Refactor this document into "HTTP Datagrams" with definitions for HTTP/1.x, HTTP/2, and HTTP/3. <del> 8. </del> <ins> 9. </ins> Since this feature requires sending an HTTP/3 Settings parameter, it "sticks out".  In other words, probing clients can learn whether a

Discussion:
This PR adds a new concept of context close codes which will allow applications that use contexts to indicate the reason for closing a context. This PR also makes the extensibility mechanism binary as that is easier to implement.
In , we introduce the CLOSEDATAGRAMCONTEXT capsule which allows endpoints to close a context. That message currently only contains the context ID to close. NAME suggests that we may want to add more information there. Should we differentiate between "context close" and "context registration rejected"? Should we add an error code? In particular, do folks have use cases for these features?
My first concern is with infinite loops. If the context was "garbage collected" by the recipient, the sender can simply re-create it if they still want it. However, if it was closed due to incompatibility (i.e. rejected) or hitting a resource limit (e.g. max # of contexts), reopening it in response will produce a tight infinite loop. This could be maybe be avoided by some kind of heuristic, but an explicit indication of what's going on seems better.
LGTM thanks