jiebi/CodeConvo huggingface dataset:
Change:
individual applications.  Note that this field can be empty. Endpoints MUST treat receipt of a DATAGRAM frame whose payload is too <del> short to parse the flow identifier as a connection error of type PROTOCOL_VIOLATION. </del> <ins> short to parse the flow identifier as an HTTP/3 connection error of type H3_GENERAL_PROTOCOL_ERROR. </ins> 5.

Discussion:
There's some good guidance about parsing the Flow ID out of the HTTP/3 Datagram with respect to datagram payload length. But I'm not sure if the recommend error code of PROTOCOLVIOLATION is the most appropriate. This implies that the error is a Transport Error but I'd argue that at this point (parsing of the frame payload) that its an HTTP/3 Application error. Since we're not actually parsing a true HTTP/3 frame, just a view over a transport frame, H3FRAMEERROR seems too specific. So I think H3GENERALPROTOCOLERROR is the most straightforward. I wonder what others think.
I honestly am fine with any error for this, though I'd prefer to reuse an existing one to reduce complexity.
Change:
_RFC Editor: Please fill in this value with the RFC number for this document_ <del> 6.2. </del> <ins> 7.2. </ins> The following entry is added to the "HTTP/2 Settings" registry that was established by Section 11.3 of RFC7540.

Discussion:
Add brief section describing Http2Transport's stance on the properties enumerated in the WebTransport Overview. We can move this around later as necessary, but wanted to get the text in to document which optional properties are supported and which are not.
From the : We should enumerate the position that Http2Transport takes on each of these items. Specifically: No stream independenceNo partial reliabilityYes pooling supportNo connection mobility
Change:
11.6. <ins> If a server ever reuses a nonce in generating a CID for a given configuration, it risks exposing sensitive information.  Given the same server ID, the CID will be identical (aside from a possible difference in the first octet).  This can risk exposure of the QUIC- LB key.  If two clients receive the same connection ID, they also have each other's stateless reset token unless that key has changed in the interim. </ins> The Stream Cipher and Block Cipher algorithms need to generate different cipher text for each generated Connection ID instance to protect the Server ID.  To do so, at least four octets of the CID are

Discussion:
the server no longer has discretion to lengthen the CID. Also, the algorithms are more aligned so there has to be less unique text associated with each algorithm.
In any given deployment, the server use length should be consistent. The load balancer doesn't strictly need to know what it is, but obviously not doing this will lead to observable correlations.
As we've generalized the concept of a nonce, we should abolish the concept of "server use" and make it all a nonce. If the servers need to use the same length to prevent linkability, best to make it part of the configuration.
Change:
6. <del> An Attester consists of at least one Attesting Environment and Attested Environment.  In some implementations, the Attesting and Attested Environments might be combined.  Other implementations might have multiple Attesting and Attested Environments. </del> <ins> An Attester consists of at least one Attesting Environment and at least one Target Environment.  In some implementations, the Attesting and Target Environments might be combined.  Other implementations might have multiple Attesting and Target Environments.  One example is a set of components in a boot sequence (e.g., ROM, firmware, OS, and application) where a Target Environment is the Attesting Environment for the next environment in the boot sequence. Target Environments are measured.  They provide the raw values and the information to be represented in claims and ultimately expressed as Evidence. Attesting Environments conduct the measuring.  They collect the claims, format them appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </ins> 7.

Discussion:
Incorporating text from draft-birkholz-rats-architecture and from my reading of the "bike shed" mailing list thread Signed-off-by: Dave Thaler
Change:
URLs is correct and meaningful to the User Equipment, even when accessed from a network other than the one that contains the captive portal.  One consequence of this is that URLs provided in the API are <del> expected to be resolved using public DNS. </del> <ins> expected to be resolved using public global DNS (as defined in Section 2 of RFC8499). </ins> Though a URL might still correctly resolve when the UE makes the request from a different network, it is possible that some functions

Discussion:
URL provides a definition of "Global DNS" to which we might want to link.
Thanks!
Change:
The client verifies the validity of a LeafNode using the following steps: <del> Verify that the credential in the KeyPackage is valid according to </del> <ins> Verify that the credential in the LeafNode is valid according to </ins> the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the <del> protocol the KeyPackage is being verified with the following exception: If the KeyPackage is an update to another KeyPackage, the authentication service MUST additionally validate that the set of identities attested by the credential in the new KeyPackage is </del> <ins> protocol the LeafNode is being verified with the following exception: If the LeafNode is an update to another LeafNode, the authentication service MUST additionally validate that the set of identities attested by the credential in the new LeafNode is </ins> acceptable relative to the identities attested by the old credential.

Discussion:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.
Change:
The EncryptedSNI.encrypted_sni value is then computed using the usual TLS 1.3 AEAD: <ins> Including ClientHello.KeyShareClientHello in the AAD of AEAD-Encrypt binds the EncryptedSNI value to the ClientHello and prevents cut-and- paste attacks. </ins> Note: future extensions may end up reusing the server's ESNIKeyShareEntry for other purposes within the same message (e.g., encrypting other values).  Those usages MUST have their own HKDF

Discussion:
Replace "It only affects connection routing, server certificate selection, and client certificate verification." with "It may affect connection routing, server certificate selection, and client certificate verification."
URL It is relative to "This design has no impact on application layer protocol negotiation.", so "only" is more explicit.
This was fixed in and I forgot to close.
Change:
0-RTT, that document MUST address the scenario where there are 0-RTT packets in the client's first flight.  For example, this could be accomplished by defining which transformations are applied to 0-RTT <del> packets.  Alternatively, that document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </del> <ins> packets.  That document could specify that compatible version negotiation causes 0-RTT data to be rejected by the server. </ins> 7.

Discussion:
s/and therefore/, thereby/
s/rightly/tightly s/across version/across multiple versions
s/Alternatively, t/T/
Change:
Ciphersuite names follow the naming convention: <del> Where VALUE is represented as two 8bit octets: </del> <ins> Where VALUE is represented as a sixteen-bit integer: The columns in the registry are as follows: Value: The numeric value of the ciphersuite Name: The name of the ciphersuite </ins> <del> This specification defines the following ciphersuites for use with MLS 1.0. </del> <ins> Recommended: Whether support for this extension is recommended by the IETF MLS WG.  Valid values are "Y" and "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N transition. </ins> <del> The KEM/DEM constructions used for HPKE are defined by I-D.irtf-cfrg- hpke.  The corresponding AEAD algorithms AEAD_AES_128_GCM and AEAD_AES_256_GCM, are defined in RFC5116.  AEAD_CHACHA20_POLY1305 is defined in RFC7539.  The corresponding hash algorithms are defined in SHS. </del> <ins> Reference: The document where this ciphersuite is defined Initial contents: These ciphersuites map to HPKE primitives and TLS signature schemes as follows I-D.irtf-cfrg-hpke RFC8446: The hash used for HKDF computations in MLS is the same hash used in the HPKE KDF for the ciphersuite. </ins> It is advisable to keep the number of ciphersuites low to increase the chances clients can interoperate in a federated environment,

Discussion:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space
Change:
When receiving a datagram with the tls12_cid content type, the new MAC computation defined in mac MUST be used.  When receiving a datagram with the RFC 6347-defined record format the MAC calculation <del> defined in Section 4.1.2 of RFC6347 (and Section 4.1.2.4 of RFC6347 for use with AEAD ciphers) MUST be used. </del> <ins> defined in Section 4.1.2 of RFC6347 MUST be used. </ins> 4.

Discussion:
As discussed with Hannes, this PR replaces
We currently only describe CID processing with AEAD ciphersuites, which seems to imply that the CID extension effectively influences ciphersuite negotiation. The draft should explain how the two - ciphersuite negotiation and CID ext - interact.
I'm not sure, what the scope of this explanation should be? For the MAC, it seems to be obvious, that the block cipher (URL ) extend the data for the MAC accordingly. URL will get That was already discussed in URL So, I'm not sure, if you are the intended "Thomas", which may write that :-)
The question is whether we should define the CID-enhanced MAC calculation for non-AEAD ciphers. The current draft only supports AEAD ciphers. If that's OK then we could just tell implementers that the ciphersuite selection should be influenced by this. Alternatively, we could define the MAC calculation also for non-AEAD ciphers. What would you prefer, Achim?
The latter, I think...
Though Leshan (LWM2M, also supporting CBC) is one of the major using and contributing projects, I would also prefer to have the MAC defined for the none-AEAD.
Here is the PR: URL
Change:
Once a Preconnection has been used to create an outbound Connection or a Listener, the implementation should ensure that the copy of the <del> properties held by the Connection or Listener is not affected when the application makes changes to a Preconnection object.  This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </del> <ins> properties held by the Connection or Listener cannot be mutated by the application making changes to the original Preconnection object. This may involve the implementation performing a deep-copy, copying the object with all the objects that it references. </ins> Once the Connection is established, Transport Services implementation maps actions and events to the details of the chosen Protocol Stack.

Discussion:
Preconnections are mutable, until they are not. The second paragraph of section 2 states "bundles of properties an application can both read and write", which seems to conflict with this. Para should lead with the fact of mutable mutability over the preconnection lifecycle, not "is mutable".
The Connection/Listener makes a deep copy that is now immutable, but the original object is still mutable.
Change:
the remote VAD algorithm. If the "VoiceActivityDetection" option is specified, with a value of <del> "false", the browser MUST NOT omit "CN" codecs.  For codecs that have </del> <ins> "false", the browser MUST NOT emit "CN" codecs.  For codecs that have </ins> their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when

Discussion:
Seems like an important distinction. I went with "MUST NOT emit", though "MUST omit" could work too.
wow lgtm
Change:
unwanted constraint on the interactions between user agents and application servers, who are the ultimate users of a push service. That constraint would also degrade the privacy-preserving properties <del> the protocol provides.  For these reasons, I-D.ietf-webpush-protocol does not define a mandatory system for authentication of application servers. </del> <ins> the protocol provides.  For these reasons, RFC8030 does not define a mandatory system for authentication of application servers. </ins> An unfortunate consequence of this design is that a push service is exposed to a greater risk of denial of service attack.  While

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
A decoder can limit the amount of state memory used for blocked streams by setting an appropriate value for the maximum number of blocked streams.  In HTTP/3, this is realized by setting an <del> appropriate value for the QPACK_BLOCKED_STREAMS parameter.  An encoder can limit the amount of state memory by only using as many blocked streams as it wishes to support; no signaling to the decoder is required. </del> <ins> appropriate value for the QPACK_BLOCKED_STREAMS parameter.  Streams which risk becoming blocked consume no additional state memory on the encoder. An encoder allocates memory to track all dynamic table references in unacknowledged field sections.  An implementation can directly limit the amount of state memory by only using as many references to the dynamic table as it wishes to track; no signaling to the decoder is required.  However, limiting references to the dynamic table will reduce compression effectiveness. </ins> The amount of temporary memory consumed by an encoder or decoder can be limited by processing header fields sequentially.  A decoder

Discussion:
Per discussion on Slack, expanding this discussion in the Security Considerations to be more accurate. Editorial, since these are purely statements about the properties of the design.
This is true, but this is also obvious, at least once you start implementing the encoder. Too, there is the natural limit on dynamic references: it is the function of the product of the number of allowed streams and the number of entries in the dynamic table (which itself is a function of the table size). I am concerned that this new verbiage puts the wrong thought into the head of the implementer; we should not encourage this. Limiting the number of dynamic table references (done out of memory conservation zeal) affects compression performance directly -- it worsens it. Perhaps we can tack on the following sentence to the end of the paragraph:
I'm OK with that, though I would qualify with "compression performance", as performance has other dimensions that the extra state might impinge upon.
Another thing to note is that sometimes dynamic table references do not have to have their own objects in the encoder. For examples, they are in ls-qpack. (Everyone reading this in 2022: you're welcome)
Yeah, compression performance qualification is a good suggestion.
Change:
this property. Note that a Final Message must always be sorted to the end of a list <del> of Messages.  The Final property overrides Niceness and any other </del> <ins> of Messages.  The Final property overrides Priority and any other </ins> property that would re-order Messages.  If another Message is sent after a Message marked as Final has already been sent on a Connection, the Send Action for the new Message will cause a

Discussion:
Not many text fixes needed - quite a bit of text reflected the old choice of Priority anyway and wasn't correctly updated for Niceness :-)
At 8.1.2 you say lower values have higher priorities for connPrio. But later, at msgPrio, higher values have higher priority, and in the examples where you speak of the interaction of connPrio and msgPrio, you imply that higher means higher for both properties. Please check for consistency and clarify.
Lower values having higher priorities for connPrio is a remnant that we must have missed when we flipped this, e.g. PR which I don't know... too many iterations have mangled the text.
Aha, now I see what happened: following some more PRs, also , in PR , NAME re-introduced some text saying that sends on Connections with lower-priority values will be prioritized over sends on Connections with a higher-priority value. This reverses the logic for some part of the text - I suspect that NAME (very understandably!) forgot what happened and this created this mix. We have been editing these documents for way too long!
Fine with me. The max_prio problem can be addressed separately.
Change:
do not elicit an immediate ACKs. ACK_FREQUENCY frames are ack-eliciting.  When an ACK_FREQUENCY frame <del> is lost, it is encouraged to send another ACK_FREQUENCY frame, unless an ACK_FREQUENCY frame with a larger Sequence Number value has already been sent.  However, it is not forbidden to retransmit the lost frame (see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence Number. </del> <ins> is lost, the sender is encouraged to send another ACK_FREQUENCY frame, unless an ACK_FREQUENCY frame with a larger Sequence Number value has already been sent.  However, it is not forbidden to retransmit the lost frame (see Section 13.3 of QUIC-TRANSPORT), as the receiver will ignore duplicate or out-of-order ACK_FREQUENCY frames based on the Sequence Number. </ins> An endpoint can send multiple ACK_FREQUENCY frames with different values within a connection.  A sending endpoint MUST send

Discussion:
This adds a SHOULD, but it seems sensible given the implications on PTO.
I thought we purposefully decided to not use normative language here.
I think we were trying to avoid normative language, though I can't remember why? But in practice, it probably doesn't matter, so I can remove the SHOULD.
ACKFREQUENCY frames are ack-eliciting. When an ACKFREQUENCY frame is lost, it is encouraged to send another ACKFREQUENCY frame, unless an ACKFREQUENCY frame with a larger Sequence Number value has already been sent. Is /it/ the sender?
Change:
initiated, or one of the child nodes successfully completes its negotiation. <del> Delayed racing attempts occur in parallel.  Implementations should </del> <ins> Staggered racing attempts occur in parallel.  Implementations should </ins> not terminate an earlier child connection attempt upon starting a secondary child.

Discussion:
Opening this to follow up on a comment by NAME on that is now closed. "Simultaneous" and "Staggered" would be better names than "Immediate" and "Delayed". Just from these terms, I would normally think that "Immediate" means to start racing right away, whereas "Delayed" means that nothing would happen for some time. So these two terms are slightly misleading in my opinion.)
I agree this would be an improvement.
LGTM (of course :-) )Thanks, looks good!
Change:
A Trusted Application Manager (TAM) server is responsible for managing the applications running in a Trusted Execution Environment <del> (TEE) of a client device.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </del> <ins> (TEE) of a client device, as described in TEEParch.  To achieve its purpose, the TAM needs to assess the state of a TEE, or of applications in the TEE, of a client device.  The TEE conducts Remote Attestation Procedures with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy.  If not, the TAM has to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </ins> A device with a TEE capable of running trusted applications that can be updated.

Discussion:
added reference to TEEP, cited TPM reference in section 3.3.
First mentioning of TEE, eSE, and TPM need reference in section Two Types of Environments of an Attester.
These terms need to have references: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules (TPMs), or BIOS firmware.
We don't think we need to expand BIOS, and that it should be on the RFC editor Acronym list.