jiebi/CodeConvo huggingface dataset:
Change:
single connection, either immediately after each other or after specific events.  For instance, the server might send a new ticket after post-handshake authentication in order to encapsulate the <del> additional client authentication state.  Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </del> <ins> additional client authentication state.  Multiple tickets are useful for clients for a variety of purposes, including: Opening multiple parallel HTTP connections. Performing connection racing across interfaces and address families via, e.g., Happy Eyeballs RFC6555 or related techniques. Clients SHOULD attempt to use each ticket no more than once, with more recent tickets being used first. </ins> Any ticket MUST only be resumed on connections where the following values match the values negotiated in the connection during which the

Discussion:
Currently, the draft says that servers MAY send multiple tickets to clients without further discussion. It might help to be concrete and provide an example for when more than one ticket is useful. This PR provides one example.
Change:
3.25. The delegation chain offers enhanced authorization functionality via <del> authorization tokens.  Each token itself is protected and does not require another layer of protection.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. </del> <ins> authorization tokens, such as CBOR Web Tokens RFC8392 with Proof of Possession Key Semantics RFC8747.  Each token itself is protected and does not require another layer of protection.  Each authorization token typically includes a public key or a public key fingerprint, however this is dependent on the tokens used.  Each token MAY include additional metadata, such as key usage information.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. The first token in any delegation chain MUST be autheticated by the recipient's Trust Anchor.  Each subsequent token MUST be authenticated using the previous token.  This allows a recipient to discard each antecedent token after it has authenticated the subsequent token.  The final token MUST enable authentication of the manifest.  More than one delegation chain MAY be used if more than one signature is used.  Note that no restriction is placed on the encoding order of these tokens, the order of elements is logical only. </ins> This element is OPTIONAL.

Discussion:
Clarify that delegation chains are lists of authentication tokens where each token provides credentials for the next until the final token which provides the credentials for the manifest.
Ben Kaduk wrote:
Change:
protection of the Attesting Environment's signing key is vital so it cannot be misused to forge Evidence. <del> In many cases the user or owner of a device that takes on the role of Attester must not be able to modify or extract keys from its Attesting Environments.  For example, the owner or user of a mobile phone or FIDO authenticator might not be trusted to use the keys to report Evidence about the environment that protects the keys.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </del> <ins> In many cases the user or owner of a device that includes the role of Attester must not be able to modify or extract keys from the Attesting Environments, to prevent creating forged Evidence.  Some common examples include the user of a mobile phone or FIDO authenticator.  An essential value-add provided by RATS is for the Relying Party to be able to trust the Attester even if the user or owner is not trusted. </ins> Measures for a minimally protected system might include process or application isolation provided by a high-level operating system, and

Discussion:
What is that sentence trying to tell me? Control over which keys? Not the attestation keys, I think.
Change:
section. Clients MUST NOT assume that a positive "RateLimit-Remaining" value <del> is a guarantee of being served. </del> <ins> is a guarantee that further requests will be served. </ins> <del> A low "RateLimit-Remaining" value is like a yellow traffic-light: the red light may arrive suddenly. </del> <ins> A low "RateLimit-Remaining" value is like a yellow traffic-light for either the number of requests issued in the "time-window" or the request throughput: the red light may arrive suddenly (see providing- ratelimit-fields). </ins> One example of "RateLimit-Remaining" use is below.

Discussion:
specific throttling behavior is out of scope FAQ 8 integrated in RateLimit-Remaining and Receiving Ratelimit fields
We used the Limit and Remain values in one of our client applications that was migrated from a legacy SOAP service to our REST based API in order to ensure we never get a 429 response (this is because the legacy code could not gracefully retry requests without major refactoring). When we get to 80% of quota (20% Remain) we start respecting the value in the Reset header. In section 7 you touched on a concept ‘A client SHOULD NOT exceed the "quota-units" expressed in "RateLimit-Remaining" before the "time-window" expressed in "RateLimit-Reset".’ We don't want to mandate a strict behavior on client, but we can surely add this sentence as an example behavior. The current spec allows comments, so you can already do it. The spec allows to address this use-case transparently, by artificially lowering the values provided in the fields.
We should probably integrate and remove since it's already in the spec.
This is something I quickly commented on URL but the alternative of dynamically modifying the values as the rate saturates is fairly reasonable, so those informational parameters might as well be part of an extension document.
Change:
learning instead of processing observed header information. However, it is questionable whether connection migrations must be <del> supported during a DDoS attack.  However, for unintentional mitigations, as is usually the case for NAT rebindings, the connection ID can be used to track connections (see sec-flow- association).  If the connection migration is not visible to the network that performs the DDoS detection, an active, migrated QUIC connection may be blocked by such a system under attack.  As soon as the connection blocking is detected by the client, the client may rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </del> <ins> supported during a DDoS attack.  While unintended migration without a connection ID change can be more easily supported, it might be acceptable to not support migrations of active QUIC connections that are not visible to the network functions performing the DDoS detection.  As soon as the connection blocking is detected by the client, the client may be able to rely on the fast resumption mechanism provided by QUIC.  When clients migrate to a new path, they should be prepared for the migration to fail and attempt to reconnect quickly. </ins> Beyond in-network DDoS protection mechanisms, TCP syncookies RFC4937 are a well-established method of mitigating some kinds of TCP DDoS

Discussion:
We recently added this sentence but the text two paragraphs up already says this. Here is my proposed change, however, maybe we can shorten this paragraph even further.
Change:
If the multipath option is enabled with a value of 2, each path has its own packet number space for transmitting 1-RTT packets and a new ACK frame format is used as specified in ack-mp-frame.  Compared to <del> the QUIC v1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used </del> <ins> the QUIC version 1 ACK frame, the ACK_MP frames additionally contains a Packet Number Space Identifier (PN Space ID).  The PN Space ID used </ins> to distinguish packet number spaces for different paths and is simply derived from the sequence number of Destination Connection ID. Therefore, the packet number space for 1-RTT packets can be

Discussion:
Be consistent with RFC9000
In order to be consistent with RFC9000, use "QUIC version 1" instead of "QUIC v1" through the document.
Change:
Examples of TLS 1.3 handshakes are shown.  Private keys and inputs are provided so that these handshakes might be reproduced. <del> Intermediate values, including secrets, traffic keys and ivs are </del> <ins> Intermediate values, including secrets, traffic keys and IVs are </ins> shown so that implementations might be checked incrementally against these values. 1. <del> TLS 1.3 TLS13 defines a new key schedule and a number new </del> <ins> TLS 1.3 TLS13 defines a new key schedule and a number of new </ins> cryptographic operations.  This document includes sample handshakes that show all intermediate values.  This allows an implementation to be verified incrementally, examining inputs and outputs of each

Discussion:
"IV" is usually capitalized, and a couple of grammar nits. I couldn't figure out what "PRK" meant in the (generated) output; should that be expanded?
I think Sean had tried to clue me in a while ago, but I only just now realized, that it would be nice if this one could be in the same cluster as the core spec, but doing that (basically) requires going through IETF LC/etc. while the test vectors are still for a draft version. So I'd like to kick things off soon and we can see how long it takes. Please do drop a new rev, though; no need to have genart pester us again.
Change:
WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del> <ins> replying with a 2xx series status code, as defined in Section 15.3 of SEMANTICS.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </ins> From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del> <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. 3.4.

Discussion:
This makes our behavior consistent with the regular CONNECT method.
The spec currently explicitly requires . suggests that any 2xx code should work. Should we change the text accordingly?
I'd suggest server MUST send 200 and client MUST accept any 2XX. That way future extensions can apply meaning to other 2XX codes.
What would happen if we require client to reject 2xx other than 200?
Change:
of a Fetch or Patch Record and hence is a target for a Fetch or Patch operation. <ins> A term that refers to both CoAP "PATCH" and "iPATCH" methods when there is no difference in this specification in which one is used. </ins> 3. <del> The FETCH/iPATCH media types for SenML are modeled as extensions to </del> <ins> The FETCH/(i)PATCH media types for SenML are modeled as extensions to </ins> the SenML media type to enable re-use of existing SenML parsers and generators, in particular on constrained devices.  Unless mentioned otherwise, FETCH and PATCH Packs are constructed with the same rules <del> and constraints as SenML Packs.  The only difference to SenML media type is allowing the use of "null" value for removing records with the iPATCH method. </del> <ins> and constraints as SenML Packs. The key difference to the SenML media type is allowing the use of a "null" value for removing records with the (i)PATCH method.  Also the Fetch and Patch Records do not have default time or base version when the fields are omitted. </ins> 3.1. <del> The FETCH method can be used to select and return parts of one or more SenML Packs.  The SenML Records are selected by giving the name(s) of the resources using the SenML "name" and/or "base name" Fields. </del> <ins> The FETCH method can be used to select and return a subset of records, in sequence, of one or more SenML Packs.  The SenML Records are selected by giving a set of names that, when resolved, match resolved names in a SenML Pack.  The names for a Fetch Pack are given using the SenML "name" and/or "base name" Fields.  The names are resolved by concatenating the base name with the name field as defined in RFC8428. </ins> <del> For example, to select resources "5850" and "5851" from the example in intro, the following Fetch Pack can be used: </del> <ins> For example, to select the IPSO resources "5850" and "5851" from the example in intro, the following Fetch Pack can be used: </ins> The result to a FETCH request with the example above would be: When SenML Records contain also time values, a name may no longer uniquely identify a single Record.  When no time is given in a Fetch <del> Record, all SenML Records with the given name are matched.  When time is given in the Fetch Record, only a SenML Record (if any) with equal time value and name is matched. </del> <ins> Record, all SenML Records with the given name are matched (i.e., unlike with SenML Records, lack of time field in a Fetch Record does not imply time value zero).  When time is given in the Fetch Record, only a SenML Record (if any) with equal resolved time value and name is matched. </ins> The resolved form of records (Section 4.6 of RFC8428) is used when comparing the names and times of the Target and Fetch Records to

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
5. During the handshake, endpoints will exchange Version Information, <del> which is a blob of data that is defined below.  In QUIC version 1, the Version Information is transmitted using a new transport parameter, version_information.  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </del> <ins> which consists of a chosen version and a list of other versions.  Any version of QUIC that supports this mechanism MUST provide a mechanism to exchange Version Information in both directions during the handshake, such that this data is authenticated. In QUIC version 1, the Version Information is transmitted using a new transport parameter, version_information.  The contents of Version Information are shown below (using the notation from the "Notational Conventions" section of QUIC): </ins> The content of each field is described below:

Discussion:
I think that the answer is "no" (see also Betteridge's Law) in that the format is version-specific, but is pretty obtuse about this: The first sentence reads as an absolute; the second is clearly narrowly scoped. But then nothing is said about other versions. As I mentioned with error codes in , I think that the way this needs to be phrased is as a requirement on QUIC versions that support version negotiation. The requirement is that those protocols need to define a way to carry certain information. You can then define that information in the abstract when articulating that requirement; again see . The concrete form you choose for v1 then only needs to apply to v1.
The intention was for the handshake version information to be invariant, and for how it is conveyed to be version-specific. But I agree that we should state that versions need an authenticated way to exchange handshake version information.
It needs to go further than that. I think that you need to list, concretely, what information is being authenticated. And you need to explain the consequences, namely: And then in Section 4, say precisely what information needs to be authenticated in order to achieve this goal, with a concrete definition for how the information is carried in QUIC version 1 transport parameters.
That works for me.
Change:
The first octet has the following fields: <del> CR: Config Rotation bits. </del> <ins> Config Rotation: Indicates the configuration used to interpret the CID. </ins> <del> CID Len: Length Self-Description (if applicable).  Encodes the length of the Connection ID following the First Octet. </del> <ins> CID Len or Random Bits: Length Self-Description (if applicable), or random bits otherwise.  Encodes the length of the Connection ID following the First Octet. </ins> 4.

Discussion:
There are so many variable length fields that the ASCII art doesn't serve much of a purpose. Just switch to the notation used in quic-transport for the various CID and token formats.
Change:
is TLS over TCP. The IETF TAPS specifications I-D.ietf-taps-arch describe a system <del> with a common API for multiple protocols and some of the implications of fallback between these different protocols, specifically precluding fallback to insecure protocols or to weaker versions of secure protocols. An application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network. Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> with a common API for multiple protocols.  This is particularly relevant for QUIC as it addresses the implications of fallback among multiple protocols. Specifically, fallback to insecure protocols or to weaker versions of secure protocols needs to be avoided.  In general, a application that implements fallback needs to consider the security consequences.  A fallback to TCP and TLS exposes control information to modification and manipulation in the network.  Further, downgrades to older TLS versions than 1.3, which is used in QUIC version 1, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the

Discussion:
This is a good piece of information. However, I could not put it into the context of this document. Please clarity how this TAPS arch matters here. URL
looks good to me. Now it is more clear that the following paragraph is actually about giving more context to fallback mechanism.
Change:
generate other profile strings even when they mean to support one of these profiles.  For instance, an endpoint might generate "RTP/AVP" but supply "a=fingerprint" and "a=rtcp-fb" attributes, indicating its <del> willingness to support "(UDP,TCP)/TLS/RTP/SAVPF".  In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </del> <ins> willingness to support "UDP/TLS/RTP/SAVPF" or "TCP/TLS/RTP/SAVPF". In order to simplify compatibility with such endpoints, JSEP implementations MUST follow the following rules when processing the media m= sections in a received offer: </ins> <del> Any profile in the offer matching the following patterns MUST be accepted: "RTP/[S]AVP[F]" and "(UDP|TCP)/TLS/RTP/SAVP[F]". </del> <ins> Any profile in the offer matching one of the following MUST be accepted: "RTP/AVP" "RTP/AVPF" "RTP/SAVP" "RTP/SAVPF" "UDP/TLS/RTP/AVP" "UDP/TLS/RTP/AVPF" "UDP/TLS/RTP/SAVP" "UDP/TLS/RTP/SAVPF" "TCP/TLS/RTP/SAVP" "TCP/TLS/RTP/SAVPF" </ins> The profile in any "m=" line in any generated answer MUST exactly match the profile provided in the offer.

Discussion:
BLOCKER: The first bullet on page 35 has a normative statement about the AVT profile strings that must be accepted, but uses an unspecified grammar to actually specify the string. If this is normative, it needs to be formal. Either specify the string using a formal and cited grammar, or provide an exhaustive list.
Proposal on editor's call is to use POSIX extended regular expressions. URL I believe this would give us the expressions. (UDP|TCP)/TLS/RTP/SAVPF? and: RTP/S?AVPF?
You're sure you want to pull in another reference for regexes instead of just listing all eight valid values?
Change:
This is equivalent to a placing a literal "signature_algorithms" extension consisting solely of this group in every extensions field <del> where it is permitted to appear. </del> <ins> where it is permitted to appear.  When this element is included, "CertificateVerify.algorithm" is omitted. Static vectors (see static-vectors): * "CertificateVerify.signature", if the "SignatureScheme" output is self-delimiting. </ins> In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256).

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
Any functionality that is common across multiple transport protocols SHOULD be made accessible through a unified set of Transport Services <del> API calls.  As a baseline, any Transport Services API MUST allow </del> <ins> API calls.  As a baseline, any Transport Services API SHOULD allow </ins> access to the minimal set of features offered by transport protocols RFC8923.

Discussion:
Quote from the API draft: "The present API covers all elements of this section except Notification of Excessive Retransmissions (early warning below abortion threshold)." So... shouldn't this MUST be a SHOULD?
Michael will merge this after finishing the PR that updates -interface minset appendix.
Change:
Two phases can be discerned for a network servicing the system: (1) installation and (2) operation.  During the operational phase, the <del> network is connected to the Internet with a Border router (6LBR) and the nodes connected to the network can use the Internet services that are provided by the Internet Provider or the network administrator. During the installation phase, the network is completely stand-alone, no 6LBR is connected, and the network only supports the IP </del> <ins> network is connected to the Internet with a Border Router (e.g. a 6LoWPAN Border Router (6LBR), see RFC6775) and the nodes connected to the network can use the Internet services that are provided by the Internet Provider or the network administrator.  During the installation phase, the network is completely stand-alone, no Border Router is connected, and the network only supports the IP </ins> communication between the connected nodes.  The installation phase is usually followed by the operational phase.  As an RD's operations work without hard dependencies on names or addresses, it can be used

Discussion:
Use case HA/BA: Expand and reference term "6LBR" Use case HA/BA: Use term 'IoT' that's more common in that area these days