jiebi/CodeConvo huggingface dataset:
Change:
A push message replacement request creates a new push message resource and simultaneously deletes any existing message resource <del> that has a matching topic.  Delivery receipts for the deleted message SHOULD be suppressed. </del> <ins> that has a matching topic.  If an attempt was made to deliver the deleted push message, an acknowledgment could arrive at the push service after the push message has been replaced.  Delivery receipts for such deleted messages SHOULD be suppressed. </ins> The replacement request also replaces the stored TTL, Urgency, and any receipt subscription associated with the previous message in the

Discussion:
This attempts to address all of the issues identified during AD review: URL I have reviewed this document in preparation for IETF last call. It is almost ready to go. I have a few comments below. Once these are resolved and a rev published, I will request publication. = Shepherd write-up = RFC 2818 is in the downref registry already. That is the only explanation necessary for the downref. = Section 5.3 = I'm assuming the application scenarios listed in the table are illustrative since they do not cover every possible application. It would be good to note that. = Section 5.4 = "Delivery receipts for the deleted message SHOULD be suppressed." Why is this a SHOULD rather than a MUST? It seems incorrect in all cases to send a delivery receipt for a message that never gets delivered. = Section 8 = I think the first paragraph should include a normative recommendation to follow the guidance in RFC 7525 for use of TLS. = Section 8.2 = I think it would be useful to acknowledge in this section that while correlation using push URIs can be limited in the various ways described, correlation based on other information exposed by user agents may still be possible. = Section 9.3 = The Contact should be IETF Chair (per RFC 6335).
Change:
profile, the client MUST wrap the token and N1 in a CBOR map.  The client MUST use the Content-Format "application/ace+cbor" defined in section 8.14 of I-D.ietf-ace-oauth-authz.  The client MUST include <del> the access token using the correct CBOR label (e.g., "cwt" for CWT, "jwt" for JWT) and N1 using the 'nonce1' parameter defined in nonce1. </del> <ins> the access token using the "access_token" parameter and N1 using the 'nonce1' parameter defined in nonce1. </ins> The authz-info endpoint is not protected, nor are the responses from this resource.

Discussion:
Not much here, though a couple points I'll leave some further comments on, as the proper disposition is not entirely clear.
If you agree NAME I would go ahead and merge this PR (excluding the "update of access rights" change at l.776).
Sorry, I missed this when it came in. Please go ahead.
Change:
QUIC version 2 is meant to mitigate ossification concerns and exercise the version negotiation mechanisms.  The only change is a <del> tweak to the inputs of some crypto derivation functions to enforce full key separation.  Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. </del> <ins> tweak to key derivation inputs to enforce full key separation.  Any endpoint that supports two versions needs to implement version negotiation to protect against downgrade attacks. </ins> 2.

Discussion:
Not only because crypto is short for cryptocurrency.
QUICv3, the web3 protocol, uses crypto the right way: the blockchain way.
You're only allowed to call it crypto in QUIC v3
Change:
The client then modifies the "encrypted_client_hello" extension in ClientHelloOuter as follows: <del> "config_id" is replaced with the empty string. </del> <ins> "config_id" is unchanged and contains the "config_id" corresponding to the client's chosen ECHConfig. </ins> "cipher_suite" is unchanged and contains the client's chosen HPKE cipher suite.

Discussion:
accidentally targeted an older branch that was since merged into master. This just takes the same change and redirects it to the main branch.
Change:
field.  This allows a client that has an account key but not the corresponding account URL to recover the account URL. <del> If a client wishes to recover an existing account and does not want a non existing account to be created, then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS whose payload is an empty object ({}). </del> <ins> If a client wishes to find the URL for an existing account and does not want an account to be created if one does not already exist, then it SHOULD do so by sending a POST request to the new-account URL with a JWS whose payload has an "only-return-existing" field set to "true" ({"only-return-existing": true}). </ins> 7.3.2.

Discussion:
Depends on
This allows us to address the account URL recovery use case in without having special handling for empty payloads.
Change:
[[OPEN ISSUE: An alternative to padding is to instead send a hash of the server name.  This would be fixed-length, but have the disadvantage that the server has to retain a table of all the server <del> names it supports.]] </del> <ins> names it supports, and will not work if the mapping between the fronting server and the hidden server uses wildcards.]] </ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in

Discussion:
The approach does not work if the mapping between the fronting server and the hidden server contains a wildcard.
LGTM!
Current text says: the "encryptedservername" extension. However, I am not sure if this is the desired behavior. I would rather suggest encrypting even when the hostname exceeds the padded_length. Having some protection is better than none. The issue is that in certain deployments it is impossible to guess what the maximum length of the hostname will be. Consider . It uses a wildcard certificate. Anybody can add a new hostname of any length by creating a new Github account (it might be true that Github some limitation on the length, but that does not necessarily mean that Github shares the maximum length information with the fronting CDN, assuming that it uses a CDN).
I have filed that fixes another issue (it's just a clarification of an open issue) related to wildcard delegation.
Technically, it is possible to guess the maximum length of the hostname, as that maximum textual representation length is defined as 253 bytes per RFC 1034.
Yes. So the question is if a CDN that has a wildcard mapping needs to set to 253 (since current text is a MUST NOT for sending a server name longer than the paddedlength), or if we should introduce a different rule.
How about something like: padded_length : The length to pad the ServerNameList value to prior to encryption. This value SHOULD be set to the largest ServerNameList the fronting server expects to support rounded up the nearest multiple of 16. If the fronting server supports wildcard names, it SHOULD set this value to 256.
NAME Thank you for the suggestion. I was feeling uneasy (and am still feeling a bit) about requiring the client to send an ESNI extension as large as ~300 bytes, assuming that CDN's would have at least one wildcard mappings. But it's about the first packet sent from the client, and we typically have enough room even when 0-RTT data is involved. So I think that we can live with that.
To be
Change:
Archives of the list can be found at: https://www.ietf.org/mail- archive/web/suit/current/index.html [3] <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] mailto:suit@ietf.org

Discussion:
Added David Brown as co-author Added further terms Updated text about permissions Re-wrote text about operating modes Editorial changes (including formatting) Revised section about claims Added new architecture figure Reworked security description Included device firmware update examples provided by David. Updated example flow (and included bootloader)
Change:
them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such bursts to the initial congestion window, which is recommended to be <del> the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)). </del> <ins> the minimum of 10 * max_datagram_size and max(2* max_datagram_size, 14720)), where max_datagram_size is the current maximum size of a datagram for the connection, not including UDP or IP overhead. </ins> As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet

Discussion:
Clarifies that this is the maximum datagram size currently in use on the connection.
kMaxDatagramSize is currently set to the minimum packet size of 1200 bytes. It should be set instead to the max packet size used by the connection, which is discussed in Section 14.1 of the transport draft. (Issue raised by Timo Völker on the mailing list.)
My reading is that this value is the actual max packet size used in the connection, it's just not clear from the explanation. kInitialWindow and kMinimumWindow are also per-connection fields defined directly below. URL There is one potential detail, which is if the MTU increases after the handshake, do the min CWND and Reno behavior change accordingly? I think it's simpler to reason about them not changing, but I can see both arguments and in the end I don't think it'll matter that much.
WinQuic uses the currently calculated path MTU instead a constant kMaxDatagramSize.
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> This specification uses the Augmented Backus-Naur Form (ABNF) notation of RFC5234 and includes, by reference, the IMF-fixdate rule <del> as defined in Section 7.1.1.1 of HTTP. </del> <ins> as defined in HTTP. </ins> <del> The term "resource" is to be interpreted as defined in Section 2 of HTTP. </del> <ins> The term "resource" is to be interpreted as defined in HTTP. </ins> 2.

Discussion:
This repo wasn't set up with the automated tooling; this PR corrects that, and fixes up a few other small things.
it seems like there's some problem with this update, NAME URL
Fixed.
Change:
Names are formed using Port-Prefix Naming (SVCB Section 2.3).  For example, a DNS service identified by the name "dns1.example.com" and (unusually) the non-default port number 5353 would be represented as <del> "_5353._dns.dns1.example.com.". </del> <ins> "_5353._dns.dns1.example.com.".  A DNS service using the default port number of 53 would be represented as "_dns.dns1.example.com.". </ins> 4.

Discussion:
Hey Ben, I know the SVCB spec defines this clearly, but I hope you'll feel that this additional sentence strikes a nice balance that can help future readers that, like me, had to dig a bit to un-confuse themselves. Regards, Peter van Dijk
Thanks for the clarification!
Change:
cases, the value of the RtpTransceiver's mid attribute MUST be set to null.  RtpTransceivers that were created by applying a remote offer that was subsequently rolled back MUST be removed.  However, a <del> RtpTransceiver MUST NOT be removed if the RtpTransceiver's RtpSender was activated by the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </del> <ins> RtpTransceiver MUST NOT be removed if a track was attached to the RtpTransceiver via the addTrack method.  This is so that an application may call addTrack, then call setRemoteDescription with an offer, then roll back that offer, then call createOffer and have a m= section for the added track appear in the generated offer. </ins> A rollback is performed by supplying a session description of type "rollback" with empty contents to either setLocalDescription or

Discussion:
This still refers to RtpSenders being "activated", a concept that isn't defined anywhere. I replaced this with "track attached to the transceiver" since that's the terminology that's used elsewhere.
Change:
1.2. <del> GitHub is a service operated at https://github.com/ [5].  GitHub </del> <ins> GitHub is a service operated at <https://github.com/>.  GitHub </ins> provides centralized storage for git repositories.  GitHub is freely accessible on the open Internet.

Discussion:
From Adam's AD review
Note that the URL fixes here are ineffective. The source is: The resulting XML is: The HTML shows a nice clickable link. xml2rfc produces text output of "URL (URL)". Perhaps this is a case where a small tweak to xml2rfc is in order.
Nice relaxation of the text.
Change:
methods.  Packets for the same QUIC connection might use different connection ID values. <del> 4.4. </del> <ins> 5.4. </ins> QUIC versions are identified with a 32-bit integer, encoded in network byte order.  Version 0 is reserved for version negotiation

Discussion:
Remove the normative reference to -transport in -invariants. This is an editorial change, but I'll pass it to the list. Includes some consistency updates.
Yes, but I think that - at least in principle - each should be as independent of the other as possible. Sure, -transport is a concrete instantiation of -invariants, but you can implement it without -invariants. Similarly, -invariants exists to support -transport, but it describes something bigger than it. So while we might have some pointers, you can read each without the other, which is nice.
introduced a new bespoke packet format. I don't have issues with the format itself, but as I reviewed I was surprised to see it used there without any explanation as to how to decipher it. I think it would be nicer if each document that uses this format either: References the "Notational Conventions" section from draft-ietf-quic-transport Has a "Notational Conventions" section of its own explaining this format
-- URL There is a lot more that the document leans on than the packet format grammar, so any expansion of this might explode. I tend to think that this is adequate.
I agree that the reference is sufficient, except for one aspect: We do want the invariants drafts to be readable without needing to get into the v1 spec, because the target audience is people who need to handle QUIC without regard to versions. I think it's wrong that the reference to QUIC-TRANSPORT is normative instead of informative, and this reference for conventions and definitions is the only reference in the doc that actually needs to be normative. I'm almost be more inclined to move the notation definition across, just as we ultimately did for the definition of VN, and let -transport refer to -invariants for it.
Looks good. Technically, we could reference this draft for the notation, but we don't need to if it makes transport easier to read.
Change:
does not discuss when a client decides to initiate a new path.  We delegate such discussion in separate documents. <del> This proposal adds one multi-path control frame for path management: </del> <ins> This proposal adds one multipath control frame for path management: </ins> PATH_ABANDON frame for the receiver side to abandon the path

Discussion:
Be consistent with title.
NAME flagged in his PRs that there are many places using hyphenated "multi-path" and many using "multipath". We need to fix that.
This is due to the merge of the different drafts. I thought I fixed most of them, but I guess I could have done a search :-) Will do
Change:
key schedule also defines a collection of secrets that are derived from the epoch secret.  For example: <del> An _encryption secret_ that is used to initialize a _secret tree_, which provides keys for encrypting handshake and application messages and providing forward secrecy for these messages within an epoch. </del> <ins> An _encryption secret_ that is used to initialize the secret tree for the epoch. </ins> A _confirmation key_ that is used to confirm that all members agree on the shared state of the group.

Discussion:
In the Protocol Overview, Figure 1 shows a ratchet tree, commitsecret, epochsecret, encryptionsecret, and a secret tree, while the text discusses the epochsecret and encryption_secret. Then the next section, Cryptographic State and Evolution states that "There are two types of cryptographic state at the core of MLS:" a key schedule, and a ratchet tree. The Secret Tree isn't mentioned there. Then we have a Key Schedule section which then includes a Secret Tree sub-section. Readers are left wondering what the relationship is between the the Key Schedule and Secret Tree.
Change:
The pledge SHOULD restart the process using a new voucher request using the location provided in the HTTP redirect.  Note if the pledge is able to validate the new server using a trust anchor found in its <del> Implicit Trust Anchor database, then it MAY accept another 307 redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </del> <ins> Implicit Trust Anchor database, then it MAY accept additional 307 redirects.redirect.  The pledge MUST never visit a location that it has already been to.  If that happens then the pledge MUST fail the onboarding attempt and go back to the beginning, which includes listening to other sources of onboarding information as specified in BRSKI section 4.1 and 5.0. </ins> The pledge SHOULD establish a provisional TLS connection with specified local domain registrar.  The pledge SHOULD NOT use its

Discussion:
I find this section too telegraphic. Needs a bit more grammar...
Maybe we just delete this section completely NAME ?
I think we should eliminate the heading, but expand the content to better match the diagram.
I'm not convinced. In the rest of the doc, we never mention OEM or Network integrator. And Network operator is only mentioned again in secetion "Issues with Security of HTTP Redirect" I lean to delete completely, unless you have some explicit ideas and concepts you need to get across. FIne if you do - maybe include that in your abstract rewrite PR?
This is a bit short. I think it should provide a little context for a casual reader (what is BRSKI, what is a pledge, what is a registrar).
No, this is a runon sentence. It is worth. Let me work on something for Friday.
Change:
The Service Proxy function maps between App-flows and DetNet flows. The DetNet Edge Node TSN entity MUST support the TSN Stream identification functions and the related managed objects as defined <del> in IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </del> <ins> in Clause 6. and Clause 9. of IEEE8021CB and IEEEP8021CBdb to recognize the App-flow related packets.  The Service Proxy presents TSN Streams as an App-flow to a DetNet Flow. </ins> When a DetNet Service Proxy receives a packet from the TSN Entity it MUST check whether such an App-flow is present in its mapping table.

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
ACME Resource Types (iana-resource) <ins> ACME Directory Metadata Fields (iana-meta) </ins> ACME Identifier Types (iana-identifier) ACME Validation Methods (iana-validation)

Discussion:
Also, add some more "replace RFC XXXX with this document" notes, for clarity. Thanks to NAME for noticing that this was missing.
Merging based on r+ from NAME
The new registry looks good :+1: - no changes to request there. The existing directory registry () should probably have a "meta" entry:
Change:
hash ratcheting for the join case, so no need to send a new key to the clients who are already on the call.  SFrame supports both modes <del> 3.2.6.1. </del> <ins> 3.3.5.1. </ins> When SFrame decryptor fails to decrypt one of the frames, it automatically ratchets the key forward and retries again until one

Discussion:
Add SFrame payload format including the signature block Move Ciphersuites at the end Refer to the KeyId field in the decryption section
Change:
7. <ins> Thanks to Martin Thomson and Martin Duke for contributing by reviewing and providing text proposals. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI), and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement. <ins> 8. This appendix uses the following conventions: array[i] - one byte at index i of array array[i:j] - subset of array starting with index i (inclusive) up to j-1 (inclusive) array[i:] - subset of array starting with index i (inclusive) up to the end of the array 8.1. This section contains algorithms that allows parsing versions from both Google QUIC and IETF QUIC.  These mechanisms will become irrelevant when IETF QUIC is fully deployed and Google QUIC is deprecated. Note that other than this appendix, nothing in this document applies to Google QUIC.  And the purpose of this appendix is merely to distinguish IETF QUIC from any versions of Google QUIC. Conceptually, a Google QUIC version is an opaque 32bit field.  When we refer to a version with four printable characters, we use its ASCII representation: for example, Q050 refers to {'Q', '0', '5', '0'} which is equal to {0x51, 0x30, 0x35, 0x30}. Otherwise, we use its hexadecimal representation: for example, 0xff00001d refers to {0xff, 0x00, 0x00, 0x1d}. QUIC versions that start with 'Q' or 'T' followed by three digits are Google QUIC versions.  Versions up to and including 43 are documented by <https://docs.google.com/document/d/ 1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/preview>.  Versions Q046, Q050, T050, and T051 are not fully documented, but this appendix should contain enough information to allow parsing Client Hellos for those versions. To extract the version number itself, one needs to look at the first byte of the QUIC packet, in other words the first byte of the UDP payload. 8.2. </ins>

Discussion:
This PR adds a new section on extracting the SNI. I also copied (most of) the pseudo code from Davids document into the appendix. We need to decide if we want to keep this and if so, potentially add some more explanation there. Also we could further strengthen the point out that both the 5-tuple and conn ID can change (as in David's doc). There is already text directly following the new SNI section on "flow association". If we want stronger text there, maybe we can capture that in a separate issue though.
I don't think that you should include the entirety of David's code. There are ways in which that will contribute to ossification. Indeed, I don't think that it is helpful to list draft versions here either.