jiebi/CodeConvo huggingface dataset:
Change:
round trip.  During recovery, the congestion window remains unchanged irrespective of new losses or increases in the ECN-CE counter. <ins> When entering recovery, a single packet MAY be sent even if bytes in flight now exceeds the recently reduced congestion window.  This speeds up loss recovery if the data in the lost packet is retransmitted and is similar to TCP as described in Section 5 of RFC6675.  If further packets are lost while the sender is in recovery, sending any packets in response MUST obey the congestion window limit. </ins> 6.6. During the handshake, some packet protection keys might not be

Discussion:
Similar to TCP as described in Section 5 of RFC 6675
Should we restrict this to retransmittable frames that were lost in the packet? If it was a small packet, can I pack to the MTU? What about pure ACKs that I've declared lost?
Those are great questions. There are two goals in my mind. The first is to ensure loss recovery is not unnecessarily slower than TCP. The second is to ensure this behavior isn't significantly more aggressive than TCP. But within those bounds, I'm inclined to not be too restrictive, if that makes sense? Suggestions welcome if you think they'd be an improvement.
Well the pedantic answer is that TCP would only detect a loss if there was something in the bytestream. the QUIC equivalents would then be any packet that contained STREAM, CRYPTO, MAXSTREAMDATA, etc, plus any packet that flipped the key update bit. But not ACK, MAX_DATA, and other things that are in the TCP header. That is obviously a dumb way to approach things. I don't actually have a strong opinion on this one way of the other, but if I read the draft correctly, the loss of an ACK-only packet will affect cwnd in QUIC but not TCP (granted, a cwnd-constrained endpoint sending pure ACKs is a corner case). So I guess I'd err on the side of permitting the packet in response to loss of an ACK, as we're already quite a bit less aggressive than TCP in that case. Anyway, do we want any normative language against, say, using this permission to send high-priority new data instead of the lost data?
Adding language against sending new data or data besides data that's been lost couples the "can I send" with "what should I send" questions more than I would like unless it's absolutely critical. FYI, to be declared lost, it must be in-flight: URL "A packet is declared lost if it meets all the following conditions: The packet is unacknowledged, in-flight, and was sent prior to an acknowledged packet."
Ah, I think we're fine then.

TCP recommends that a sender retransmit a packet immediately upon detecting the first loss in a recovery window (see Section 3.2, second para, of RFC 5681; Section 5 of RFC 6675 seems to follow the same idea). QUIC should at least allow the same. Not doing this can delay loss recovery by 0.5 RTT, which is not great. This replaces ; this is a more correct description of the problem, which is a design issue.
Discussed in ZRH. Proposed resolution is to get a PR done.
Change:
AES is defined in AES. This algorithm samples 16 bytes from the packet ciphertext.  This <del> value is used as the input to AES-ECB.  In pseudocode: </del> <ins> value is used as the input to AES-ECB.  In pseudocode, the header protection function is defined as: </ins> 5.4.4.

Discussion:
This could have been more explicit, so now it is. Doubly so.
Section 5.4.1, Figure 6: mask = headerprotection(hpkey, sample) I think it is a bit unclear that the headerprotection function is what is producing the stream cipher cipher text that will be masked and xored with the header bits. Especially as the instantiations of these functions for AESGCM (Section 5.4.3) and ChaCha20 (Section 5.4.4) is not defined as instantiation of that function, only as providing the same variable output. I think this could be clarified in both places so that the linkage between the general application and the stream cipher producing function is clear.
Looks good and resolve my issue.
indubitably
Change:
represent the concrete addresses, local and server reflexive, on which a Rendezvous() for the Preconnection will listen for incoming Connections.  This list can be passed to a peer via a signalling <del> protocol, such as SIP or WebRTC, to configure the remote. </del> <ins> protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the remote. </ins> 6.4.

Discussion:
quickly adding this to fix NAME nits before -01 submission
Text: Internally, the transport system will first exclude all protocols and paths that match a Prohibit, then only keep candidates that match a Require, then sort candidates according to Preferred properties, and then use Avoided properties as a tiebreaker. does not read correct for me... I understand excluding prohibit, but the action on require seems wrong. I expected to remove candidates with prohibit and remove candidates that do NOT have require. What is written is different. —- I would prefer a para break before: The Rendezvous() Action causes the to show the change of topic. — Refs needed: SIP or WebRTC — maximum Message size should this be capitalised? What is maxlen? The same value? Of different? —- I could not finally understand what is intended by this text; The exact disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection's Transport Properties.
Change:
same properties. Properties can be added to a MessageContext object only before the <del> context is used for sending.  Once a messageContext has been used with a Send call, it is invalid to modify any of its properties. </del> <ins> context is used for sending.  Once a MessageContext has been used with a Send call, further modifications to the MessageContext object do not have any effect on this Send call. </ins> The Message Properties could be inconsistent with the properties of the Protocol Stacks underlying the Connection on which a given

Discussion:
There are several places where the document says "Changes to a after func() has been called do not have any connection on existing s". This feels like an opportunity for more clarity about what a really is. The document uses the word Object, and maybe there's an assumption that there's a shared understanding of what the properties of an Object are. Being explicit with something like "An Object is a collection of properties that implementations of the API read and use..." to avoid the "here's a chunk of memory that can get passed into the API that it can operate on, and expect the caller to see the effects of the operation" interpretation. I think what the current text is trying to say is that the user of the API should assume the implementation of the API made its own private copy of the Object at the point of the given func() call and that it will not see any changes to the copy the user has at any later point. But then there's some text that looks like "Once a has been used with a func(), it is invalid to modify any of its properties." So...
Change:
Issuer name, identifying the Issuer.  This is typically a host name that can be used to construct HTTP requests to the Issuer. <del> Issuer Public Key pkI, with a key identifier "key_id" computed as described in public-issuer-configuration. </del> <ins> Issuer Public Key pkI, with a key identifier "token_key_id" computed as described in public-issuer-configuration. </ins> Challenge value "challenge", an opaque byte string.  For example, this might be provided by the redemption protocol in HTTP-

Discussion:
cc NAME NAME
Let's use different names to make this distinction clear.
This helps, thanks!
Change:
Readers are expected to be familiar with the terms and concepts described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE <del> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl, and constrained environments RFC7228. </del> <ins> RFC8152, CBOR RFC7049, CDDL I-D.ietf-cbor-cddl as summarized in cddl- sum, and constrained environments RFC7228. </ins> The term "hop" is used to denote a particular leg in the end-to-end path.  The concept "hop-by-hop" (as in "hop-by-hop encryption" or

Discussion:
I believe this is about the minimum change that we can make to avoid the need for a normative reference to draft-ietf-cbor-cddl, which might hold up the document in the RFC editor queue.
Thank you NAME the only thing I can think of is adding a reference to CBOR in the appendix too, but that's it.
Change:
abbreviations. The same CWT token as in ex2, using the value abbreviations defined <del> in I-D.ietf-ace-oauth-authz and I-D.ietf-ace-cwt-proof-of-possession and encoded in CBOR is shown in ex2-cbor. </del> <ins> in I-D.ietf-ace-oauth-authz and RFC8747 and encoded in CBOR is shown in ex2-cbor. </ins> NOTE TO THE RFC EDITOR: before publishing, it should be checked (and in case fixed) that the values used below (which are not yet

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)
Change:
the same 5-tuple {dest addr, source addr, protocol, dest port, source port}, will receive similar network treatment since feedback about loss or delay of each packet is used as input to the congestion <del> controller.  Therefore it is not recommended to use different </del> <ins> controller.  Therefore, it is not recommended to use different </ins> DiffServ Code Points (DSCPs) RFC2475 for packets belonging to the same connection.  If differential network treatment, e.g. by the use of different DSCPs, is desired, multiple QUIC connections to the same

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:
scheme defines one parameter, "token", which contains the base64url- encoded Token struct.  Since the length of the Token struct is not fixed, the base64url value MUST include padding.  As an <del> Authentication Parameter ("auth-param" from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. </del> <ins> Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. </ins> Clients present this Token structure to origins in a new HTTP request using the Authorization header field as follows:

Discussion:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.
Change:
ANSI X9.62 ANSI.X9-62.2005 and FIPS 186-4 FIPS.186-4.  The rest of this document refers to these three curves as the "NIST curves" because they were originally standardized by the National Institute <del> of Standards and Technology.  The curves ecdh_x25519 and ecdh_x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </del> <ins> of Standards and Technology.  The curves x25519 and x448 are defined in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The predecessor of this document also supported explicitly defined prime and char2 curves, but these are deprecated by this

Discussion:
ecdhx25519 and ecdhx448 no longer have an ecdh_ prefix (.Remove some remnants of EdDSA curves as NamedCurves.TLS 1.3 only uses the PureEdDSA algorithms. If we were to use Ed25519ph, we would want separate SignatureAlgorithm values so the receivers can indicate support.
(NAME suggested I file this here.) In TLS 1.3, we dropped the "ecdh" prefix on ecdhx25519 and ecdh_x448 when we split signatures from NamedCurve/Group. The documents should probably match in naming one way or another. I think plain x25519 and x448 is tidier. X25519 already denotes the ECDH function, as opposed to curve25519 which is the curve.
Looks fine to me
Change:
document.  This document provides a container format for carrying the capability and its context information. <del> 4.2. </del> <ins> 3.2. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
The Header Acknowledgement and Stream Cancellation instructions permit the encoder to remove references to entries in the dynamic <del> table.  When entries have zero references they are no longer considered blocking (see blocked-insertion). </del> <ins> table.  When an entry with absolute index lower than the Known Received Count has zero references, then it is no longer considered blocking (see blocked-insertion). </ins> 2.2.2.3.

Discussion:
The definition of a blocking entry has two parts: insertion not acknowledged, or not all references acknowledged. Update text in two places to include the part about acknowledging the insertion, lest a reader forget about it.
Change:
Therefore management and control plane design is an important aspect of scenarios, where mapping between DetNet and TSN is required. <ins> Note that, as the DetNet network is just a portion of the end to end TSN path (i.e., single hop from Ethernet perspective), some parameters (e.g., delay) may differ significantly.  Since there is no interworking function the bandwidth of DetNet network is assumed to be set large enough to handle all TSN Flows it will support.  At the egress of the Detnet Domain the MPLS headers are stripped and the TSN flow continues on as a normal TSN flow. </ins> In order to use a DetNet network to interconnect TSN segments, TSN specific information must be converted to DetNet domain specific ones.  TSN Stream ID(s) and stream(s) related parameters/requirements must be converted to a DetNet flow-ID and flow related parameters/ <del> requirements.  Note that, as the DetNet network is just a portion of the end2end TSN path (i.e., single hop from Ethernet perspective), some parameters (e.g., delay) may differ significantly.  Other parameters (like bandwidth) also may have to be tuned due to the MPLS encapsulation used within the DetNet network. </del> <ins> requirements. </ins> In some case it may be challenging to determine some egress node related information.  For example, it may be not trivial to locate

Discussion:
Work In progress - Wanted to get the figure changes out for review. Need to check if the overly wording is complete. There was a lot of inter working text - I have commented out.
Change:
The extension suffix is completely optional, making existing RFC3339 timestamps compatible with this format. <del> The format is compatible to the pre-existing popular syntax for </del> <ins> The format is compatible with the pre-existing popular syntax for </ins> attaching time zone names to timestamps (JAVAZDT). <del> The format provides generalized way to attach any additional </del> <ins> The format provides a generalized way to attach any additional </ins> information to the timestamp. 2.

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:
incorporating EPSKs described in I-D.ietf-tls-external-psk- importer. <del> Unless other accommodations are made, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role.  (The two logical nodes MAY be the same, in different roles.)  Two acceptable accommodations are described in I-D.ietf-tls-external- psk-importer: (1) exchanging client and server identifiers over the TLS connection after the handshake, and (2) incorporating identifiers for both the client and the server into the context string for an EPSK importer. </del> <ins> Unless other accommodations are made to mitigate the risks of PSKs know to a group, each PSK MUST be restricted in its use to at most two logical nodes: one logical node in a TLS client role and one logical node in a TLS server role.  (The two logical nodes MAY be the same, in different roles.)  Two acceptable accommodations are described in I-D.ietf-tls-external-psk-importer: (1) exchanging client and server identifiers over the TLS connection after the handshake, and (2) incorporating identifiers for both the client and the server into the context string for an EPSK importer. </ins> Nodes using TLS 1.3 SHOULD use external PSK importers I-D.ietf- tls-external-psk-importer when configuring PSKs for a client-

Discussion:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable
Change:
Validation responses need to be bound to an account key pair in order to avoid situations where a MitM on ACME HTTPS requests can switch <del> out a legitimate domain holder's account key for one of his choosing, e.g.: </del> <ins> out a legitimate domain holder's account key for one of his choosing. Such MitMs can arise, for example, if a CA uses a CDN or third-party reverse proxy in front of its ACME interface.  An attack by such an MitM could have the following form: </ins> Legitimate domain holder registers account key pair A

Discussion:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME
Change:
tickets, distinct tickets prevent premature ticket invalidation by racing. <del> Connection priming: In some systems, connections can be primed or bootstrapped by a centralized service or daemon for faster connection establishment.  Requesting tickets on demand allows such services to vend tickets to clients to use for accelerated handshakes with early data.  (Note that if early data is not needed by these connections, this method SHOULD NOT be used. Fresh handshakes SHOULD be performed instead.) </del> Less ticket waste: Currently, TLS servers use application- specific, and often implementation-specific, logic to determine how many tickets to issue.  By moving the burden of ticket count

Discussion:
I opted to go with "new connection" instead of "full handshake" (where appropriate), since that seemed to be the more natural phrase. Please let me know what you think! cc NAME (and thanks for the review!)
Change:
application <ins> private-token-request N/A None "binary" see N/A this specification N/A N/A see Authors' Addresses section COMMON N/A see Authors' Addresses section IESG 8.3.3. application </ins> private-token-response N/A

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the <del> initial registration, a default value of 86400 (24 hours) </del> <ins> initial registration, a default value of 90000 (25 hours) </ins> SHOULD be assumed. Context (optional).  This parameter sets the Default Base URI

Discussion:
This is easier to to satisfy with a "once per day" update, a nice round number, and still over 9000. Closes: URL
I think that the default value of lt should be modified so that it is slightly greater than one day. If it is one day then a cron job which starts at midnight everyday could potentially end up not acting in time to renew rather than re-register an item. Given that a post to the resource adds the value of lt to the current time, there would be no drift in the expiration time.
Change:
that the chosen version and ciphersuite is the best option supported by all members. <del> Initialize a one-member group with the following initial values (where "0" represents an all-zero vector of size KDF.Nh): </del> <ins> Initialize a one-member group with the following initial values: </ins> Ratchet tree: A tree with a single node, a leaf containing an HPKE public key and credential for the creator

Discussion:
While reviewing , I noticed that in one place, we define the initial to be the all-zero vector, and in another, we define it to be the empty octet string. In keeping with the idea of starting chained hashes with the empty octet string, this PR normalizes on the empty octet string for the transcript hashes as well.
Change:
for connections to time out.  However, this is acceptable only if the routing cannot be influenced by an attacker. <del> 21.9. </del> <ins> 21.10. </ins> This document defines QUIC Version Negotiation packets version- negotiation, which can be used to negotiate the QUIC version used

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)