jiebi/CodeConvo huggingface dataset:
Change:
5.6. Creation of resources can be rate limited to ensure fair usage and <del> prevent abuse.  If rate limits are in place, the server SHOULD send the following three headers fields: Once the rate limit is exceeded, the server responds with an error with the code "rateLimited". </del> <ins> prevent abuse.  Once the rate limit is exceeded, the server MUST respond with an error with the code "rateLimited".  Additionally, the server SHOULD send a "Retry-After" header indicating when the current request may succeed again.  If multiple rate limits are in place, that is the time where all rate limits allow access again for the current request with exactly the same parameters. In addition to the human readable "detail" field of the error response, the server MAY send one or multiple tokens in the "Link" header pointing to documentation about the specific hit rate limits using the "rate-limit" relation. </ins> 5.7.

Discussion:
Rate limits can be used to show warnings to the user, e.g. when certificate issuance is limited to 5 certificates per 7 days and you already issued 3. A single client can't count these, because they may be on different servers using different clients.
Change:
transported without changes. is either a single signature or an array of signature values. <del> It is legal to use the array of signature values for a single signature. Implementations MUST be able to parse both layouts. </del> <ins> A single signature value can be represented using either data type.  Implementations MUST be able to parse both data types. The CDDL grammar structure for a signature is: </ins> The fields is the structure have the following semantics:

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
11.1. <ins> ACME relies on two different classes of key pair: Account key pairs, which are used to authenticate account holders Certificate key pairs, which are used to sign and verify CSRs (and whose public keys are included in certificates) Compromise of the private key of an account key pair has more serious consequences than compromise of a private key corresponding to a certificate.  While the compromise of a certificate key pair allows the attacker to impersonate the entities named in the certificate for the lifetime of the certificate, the compromise of an account key pair allows the attacker to take full control of the victim's ACME account, and take any action that the legitimate account holder could take within the scope of ACME: Issuing certificates using existing authorizations Revoking existing certificates Accessing and changing account information (e.g., contacts) Changing the account key pair for the account, locking out the legitimate account holder For this reason, it is RECOMMENDED that account key pairs be used for no other purpose besides ACME authentication.  For example, the public key of an account key pair SHOULD NOT be included in a certificate.  ACME clients and servers SHOULD verify that a CSR submitted in a finalize request does not contain a public key for any known account key pair.  In particular, when a server receives a finalize request, it MUST verify that the public key in a CSR is not the same as the public key of the account key pair used to authenticate that request. 11.2. </ins> As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates.  Servers SHOULD perform DNS

Discussion:
Thanks for the comments NAME I've updated the PR to address.
There has been list discussion on this PR and consensus is positive. I'm going to merge this now that NAME has addressed the feedback provided.
LGTM :rocket:
Change:
5. <del> RTT is calculated when an ACK frame arrives by computing the difference between the current time and the time the largest acked packet was sent.  An RTT sample MUST NOT be taken for a packet that is not newly acknowledged or not ack-eliciting. </del> <ins> Round-trip time (RTT) is calculated when an ACK frame arrives by computing the difference between the current time and the time the largest acked packet was sent.  An RTT sample MUST NOT be taken for a packet that is not newly acknowledged or not ack-eliciting. </ins> When RTT is calculated, the ack delay field from the ACK frame SHOULD be limited to the max_ack_delay specified by the peer.  Limiting

Discussion:
Explicitly state that round trip time is abbreviated as RTT
In the recovery draft, RTT is briefly spelled out in section 5 but is used in several earlier sections. SRTT and PTO are not explained at all, it seems. TLP is spelled out. RTO has a section of its own but it referenced before that. The recovery doc cannot be a tutorial on transmission theory, but it would be helpful to list the key acronyms and possibly reference an RFC with more details. There are already sections summarising key variables in pseudocode. There are references at the end, but the reader would have to go through them all.
Yes, thanks for the note. I'm planning to do a cleanup of that doc soon.
I fixed defined RTT earlier in .
Change:
point.  HTTP/3 provides such a mechanism using the GOAWAY frame.  In HTTP/3, when the GOAWAY frame is received by a client, it stops opening new streams even if the cumulative stream limit would allow. <del> Instead the client would create a new connection on which to open </del> <ins> Instead, the client would create a new connection on which to open </ins> further streams.  Once all streams are closed on the old connection, it can be terminated safely by a connection close or after expiration of the idle time out (see also sec-termination).

Discussion:
All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via URL), so there will likely be some false positives. There is no need to let me know what you did with these suggestions.
Change:
11. The security of this version negotiation mechanism relies on the <del> authenticity of the handshake version information exchanged during the handshake.  In QUIC version 1, transport parameters are authenticated ensuring the security of this mechanism.  Negotiation between compatible versions will have the security of the weakest common version. </del> <ins> authenticity of the Version Information exchanged during the handshake.  In QUIC version 1, transport parameters are authenticated ensuring the security of this mechanism.  Negotiation between compatible versions will have the security of the weakest common version. </ins> The requirement that versions not be assumed compatible mitigates the possibility of cross-protocol attacks, but more analysis is still needed here. <del> The presence of the "Attempted Version" and "Negotiated Version" fields mitigates an attacker's ability to forge packets by altering the version. </del> 12. 12.1.

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
The SDP returned from createOffer or createAnswer MUST NOT be changed before passing it to setLocalDescription.  If precise control over <del> the SDP is needed, the aformentioned createOffer/createAnswer options or RTPSender APIs MUST be used. </del> <ins> the SDP is needed, the aforementioned createOffer/createAnswer options or RTPSender APIs MUST be used. </ins> Note that the application MAY modify the SDP to reduce the capabilities in the offer it sends to the far side (post-

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm
Change:
is derived from the PPM parameters as: <del> Where param is just the serialization of Param. </del> <ins> Where param is the serialization of Param. </ins> 4.2.

Discussion:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.
Change:
5.4. <del> The Hidden Server ignores both the "encrypted_server_name" and the </del> <ins> The backend Server ignores both the "encrypted_server_name" and the </ins> "server_name" (if any) and completes the handshake as usual.  If in Shared Mode, the server will still know the true SNI, and can use it for certificate selection.  In Split Mode, it may not know the true SNI and so will generally be configured to use a single certificate. communicating-sni describes a mechanism for communicating the true <del> SNI to the hidden server. </del> <ins> SNI to the backend server. </ins> <del> Similar to the Shared Mode behavior, the hidden server in Split Mode </del> <ins> Similar to the Shared Mode behavior, the backend server in Split Mode </ins> SHOULD pad the Certificate message, via padding at the record layer such that its length equals the size of the largest possible Certificate (message) covered by the same ESNI key. [[OPEN ISSUE: Do we want "encrypted_server_name" in EE?  It's clearer communication, but would make it so you could not operate a current <del> TLS 1.3 server as a hidden server.]] </del> <ins> TLS 1.3 server as a backend server.]] </ins> 6.

Discussion:
I decided "hidden" was bad. NAME
+1 to the change. I think that this is the right direction.
Change:
security. Interaction between the Key Distributor and the call processing <del> function may be necessary to for proper conference-to-endpoint mappings, which may or may not be satisfied by getting information directly from the endpoints or via some other means.  See dolist for a related item in the To Do list. </del> <ins> function is necessary to for proper conference-to-endpoint mappings. This is described in identity. </ins> The Key Distributor needs to be secured and managed in a way to prevent exploitation by an adversary, as any kind of compromise of

Discussion:
This is related to text that was in framework that said Investigate adding ability to enable the transmission of one-way media from a non-trusted device (e.g., announcements). One possible solution is to have the Key Distributor send an "ekt_key" message that is explicitly labeled for receive-only and giving that to announcement servers. A possible approach would be to define EKT Keys with a SPI > 32000, for example, for this purpose and endpoints should only use those EKT Keys to decrypt Full EKT Fields received from such transmitters. Endpoints would never send media with EKT Keys with those SPI values.
The other solution was to have an explicit indication in the message that delivers the EKT Key to the endpoint of announcement server. The EKT Key contains the key, cipher, MKI, etc. The KMF could add "direction" as a new field, which would be "send-only" (sent to announcement servers), "receive-only" (sent to endpoints), or "send-receive" for all the "normal" EKT Keys used in the conference between endpoints. Using SPI values to have certain meaning would work, but the device would have to know its role. That might lead to some confusion. So, I'd prefer an explicit indication to the device. Also, we might want to use this to admit certain endpoints into the conference (e.g., large-scale "webinars" or similar) where endpoints participating should be in listen-only mode. (Of course, any media they transmit could be discarded, but having a receive-only key makes that more explicit, too.)
Note that at IETF 96, there was no interest in working on this requirement, in part indicating that announcements, etc would come out-of-band and likely not involve media. The general sentiment was to remove this from the to do list.
We can close this open issue till there is energy to work on in the WG
Change:
The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive <del> extensions are not offered in the ClientHelloOuter.  [[OPEN ISSUE: We should provide guidance on what extensions are sensitive and suggest suitable substitutes.]] </del> <ins> extensions are not offered in the ClientHelloOuter.  See outer- clienthello for additional guidance. </ins> To encrypt EncodedClientHelloInner, the client first needs to generate the HPKE encryption context.  It computes the encapsulated

Discussion:
I noticed there's an OPEN ISSUE to add ClientHelloOuter guidance, but there's already a section for it. Link to it and flesh it out a little more. Sadly, in doing so, I've traded one OPEN ISSUE for another OPEN ISSUE, but hopefully that'll be closed shortly.
Change:
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length integer.  The Push ID identifies the server push that is being <del> cancelled (see frame-push-promise). </del> <ins> cancelled (see frame-push-promise).  If a CANCEL_PUSH frame is received which references a Push ID greater than currently allowed on the connection, this MUST be treated as a connection error of type HTTP_ID_ERROR. </ins> If the client receives a CANCEL_PUSH frame, that frame might identify <del> a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. </del> <ins> a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due to reordering.  If a server receives a CANCEL_PUSH frame for a Push ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST be treated as a connection error of type HTTP_ID_ERROR. </ins> 7.2.4.

Discussion:
Open to discussion about whether all of these are ID_ERROR or not.
I've tried to improve the readability of this section a bit; I turned Ian's suggested parallel paragraphs around to talk about why client and server would send the frame (and the corresponding responses) instead of talking about behavior on receipt. Please take a fresh look, NAME and NAME
I think there are some edge cases with the CANCELPUSH frame that we don't explain: reception of a CANCELPUSH frame with ID greater than the current push limit reception of CANCEL_PUSH with ID that has already been used
I'd also add a CANCELPUSH from the client for a PUSHID that has not been promised.
CANCEL_PUSH with a reused ID is probably indistinguishable from receiving one for a stream that's already open; you SHOULD reset the stream (which is a no-op if the stream is already full transferred).
Change:
client believes that the network path and peer both support the size that it chooses. <del> 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. </del> A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately

Discussion:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)
Change:
IANA will maintain a registry of allocated multi-character namespaces.  This registry MUST use the record-jar format described <del> by the ABNF in RFC5646.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </del> <ins> by the ABNF in BCP47.  Upon publication of a namespace as an RFC, the maintaining authority defined in the RFC MUST forward this </ins> registration form to <<mailto:iesg@ietf.org>>, who MUST forward the request to <<mailto:iana@iana.org>>.  The maintaining authority of the namespace MUST maintain the accuracy of the record by sending an

Discussion:
I looked through the inline comments as well. Should we file issues for all of these?
I think we should have a quick check if we can resolve any of these between us, and then make issues. Grüße, Carsten
(Many of the comments are really editorial. E.g., if you have a “BCP47 extensions registry” in mind, we can simply point to that; I just couldn’t find that.) I think I’ll submit the -01 now anyway, so we do have a new version to look at for the interim. Grüße, Carsten
Perfect, thanks. I'll try to see how many of the comments can be trivially resolved.
Please confirm -01; we can submit a -02 quickly after that (I-D deadline 2021-10-25!).
-01 is published o/
Perfect, thanks for the changes! They look great, and I apologize for the issues especially with the references, Metanorma was not making my life any easier.
Change:
(RA) options RFC8106, as well as manual configuration. This document defines two mechanisms for clients to discover <del> designated resolvers using DNS server Service Binding (SVCB, I- D.ietf-dnsop-svcb-https) records: </del> <ins> designated resolvers that support these encrypted protocols using DNS server Service Binding (SVCB, I-D.ietf-dnsop-svcb-https) records: </ins> When only an IP address of an Unencrypted DNS Resolver is known, the client queries a special use domain name (SUDN) RFC6761 to

Discussion:
From Section 1 Introduction, it is not obvious if the two mechanisms mentioned in the section are alternative or complementary, and how they relate to the DoT, DoQ and DoH requirements introduced in the same section. Section 4 gets into details about DoT and DoQ using IP addresses - it would be good to explain a little more about it in the Intro section. In Section 5, the requirements seem to overlap with draft-ietf-add-svcb-dns. It would be good to further clarify the relationship between the two specifications. Finally, since multiple solutions are presented, some recommendations about when, how and why one mechanism should be used vs the other would be useful to the reader.
LGTM
Change:
The following is an example of a handshake with lost packets and retransmissions.  Note that the client sends an empty ACK message <del> because it can only acknowledge Record 1 sent by the server once it </del> <ins> because it can only acknowledge Record 2 sent by the server once it </ins> has processed messages in Record 0 needed to establish epoch 2 keys, <del> which are needed to encrypt or decrypt messages found in Record 1. </del> <ins> which are needed to encrypt or decrypt messages found in Record 2. </ins> ack-msg provides the necessary background details for this interaction.  Note: for simplicity we are not re-setting record numbers in this diagram, so "Record 1" is really "Epoch 2, Record 0,

Discussion:
The middle two commits should be looked at individually. Optional-ACK can be used (as in Figure 12) to short-circuit the retransmit timer in addition to selective acknowledgment.
(Looks like I still don't understand the kramdown reference behavior.)
Change:
3.4.7.2.4. The logical AND, OR, and NOT operators have the normal semantics of <del> Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any expression that yields true, such as "1 == 1", and "F" is any expression that yields false, such as "1 == 0"): </del> <ins> Boolean algebra and obey its laws (see, for example, BOOLEAN-LAWS). </ins> 3.4.7.3.

Discussion:
There were picked up by NAME Improve table 1 Improve comparison examples Link to Boolean laws Make some examples shorter More list selector examples Compress two examples into one Clarify description of Normalized Paths
NAME The section concerning you needs more work, but I'm going to merge this PR with what we have and start a new one to improve that section.
NAME This should do it: URL
Change:
candidates, as described in Section 5.7 of RFC5245 and start connectivity checks with the appropriate credentials. <ins> If an "a=end-of-candidates" attribute is present, process the end- of-candidates indication as described in I-D.ietf-ice-trickle Section 11. </ins> If the media section proto value indicates use of RTP: [TODO: header extensions]

Discussion:
Specifically, "addIceCandidate" and "Applying a Remote Description".
I'm fine this however it ends up. I will r+ this and people can merge it once it is done. Thanks
Just adding a still LGTM
lgtm once my comment from today is addressed