jiebi/CodeConvo huggingface dataset:
Code change:
Before a new entry is added to the dynamic table, entries are evicted from the end of the dynamic table until the size of the dynamic table is less than or equal to (table capacity - size of new entry) or <del> until the table is empty.  The encoder MUST NOT evict a dynamic table entry unless it has first been acknowledged by the decoder. </del> <ins> until the table is empty.  The encoder MUST NOT evict a blocking dynamic table entry (see blocked-insertion). </ins> If the size of the new entry is less than or equal to the dynamic table capacity, then that entry is added to the table.  It is an

Related discussion:
text: NAME Thank you for your feedback.
Thanks for this. I don't have a better name for blocking entries right now, but I will keep thinking on it as I agree it could confuse people even more.
This looks reasonable.
Code change:
constructing and processing an . The Nn and Nk values correspond to parameters of the AEAD used in <del> HPKE, which is defined in HPKE.  Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </del> <ins> HPKE, which is defined in HPKE or the HPKE AEAD IANA registry [2]. Nn and Nk refer to the size of the AEAD nonce and key respectively, in bytes.  The nonce length is set to the larger of these two lengths, i.e., max(Nn, Nk). </ins> 4.3.

Related discussion:
text: From NAME Can we (additionally or in replacement) point to the "HPKE KEM Identifiers" IANA registry created from this table instead? Same for this and "HPKE AEAD Identifiers" registry.
Code change:
This interaction is often limited to signaling between the record layer and the handshake layer. <del> ESP </del> <ins> IPsec </ins> Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to

Related discussion:
text: Completes
We collapsed IKEv2 and ESP into IPsec. Should we remove ESP from feature lists, e.g., the list of protocols that support PSK import?
Agreed, we should make sure this is consistent. One of our features, Key Expiration, currently only mentions ESP though. Is this actually an IPsec feature now, do we remove the feature, or is there another solution?
Code change:
above), then it MUST be populated.  Otherwise, the sender MAY omit the "path" field at its discretion. <del> If populating the "path" field: Create a DirectPath using the new </del> <ins> If populating the "path" field: Create a UpdatePath using the new </ins> tree (which includes any new members).  The GroupContext for this operation uses the "group_id", "epoch", "tree_hash", and "confirmed_transcript_hash" values in the initial GroupContext object. <del> Assign this DirectPath to the "path" field in the Commit. </del> <ins> Assign this UpdatePath to the "path" field in the Commit. </ins> <del> Apply the DirectPath to the tree, as described in </del> <ins> Apply the UpdatePath to the tree, as described in </ins> synchronizing-views-of-the-tree.  Define "commit_secret" as the value "path_secret[n+1]" derived from the "path_secret[n]" value assigned to the root node.

Related discussion:
text: This is a simple rename of to to be more descriptive of the action being performed by the message. I'll open a separate PR after this PIR is merged with updates to the spec where it uses when instead it should say (since not every actually ratchets forward key material, as I understand). Some examples of where these clarifications should happen are: Line 1203 should instead say "each MLS UpdatePath message" The sections "Ratchet Tree Evolution" and "Sychronizing Views of the Tree" should describe the process of generating the key material for an message cc NAME
DirectPath corresponds to the graph theory term "direct path" of a leaf with the root
"Direct path" is still a thing, and the object in question here operates along a direct path, but I think "UpdatePath" indicates more clearly what it's doing.
Code change:
network elements such as firewalls that use the port number for application identification. <ins> Applications could define an alternate endpoint discovery mechanism to allow the usage of ports other than the default.  For example, HTTP/3 (Sections 3.2 and 3.3 of QUIC-HTTP) specifies the use of HTTP Alternative Services RFC7838 for an HTTP origin to advertise the availability of an equivalent HTTP/3 endpoint on a certain UDP port by using the "h3" Application-Layer Protocol Negotiation (ALPN) RFC7301 token. ALPN permits the client and server to negotiate which of several protocols will be used on a given connection.  Therefore, multiple applications might be supported on a single UDP port based on the ALPN token offered.  Applications using QUIC are required to register an ALPN token for use in the TLS handshake. As QUIC version 1 deferred defining a complete version negotiation mechanism, HTTP/3 requires QUIC version 1 and defines the ALPN token ("h3") to only apply to that version.  So far no single approach has been selected for managing the use of different QUIC versions, neither in HTTP/3 nor in general.  Application protocols that use QUIC need to consider how the protocol will manage different QUIC versions.  Decisions for those protocols might be informed by choices made by other protocols, like HTTP/3. </ins> 9. QUIC supports connection migration by the client.  If an IP address

Related discussion:
text: This solves a versioning problem at the cost of future flexibility. Application protocol mappings written for QUIC v1 or other QUIC versions may be able to benefit from version negotiation mechanisms that did not exist during the development of HTTP/3 (RFC-to-be-whatever). Coupling QUIC version to ALPN tokens is one approach but not the only approach.
I believe the text already says that this doesn't have to be applied by other application. The cited text is really only meant to described what was decided from h3 as an example. We can definitely reword this for reflect the consensus more clearly as proposed by Lucas.
Lucas, I would welcome your proposal as kicking the can down the road and not enshrining an approach that I think is bad. I would also like to continue the ALPN/versioning discussion, but it doesn't have to block the applicability draft.
I can make it shorter. Maybe not as short as NAME would have it, but still shorter :)
Code change:
The last input comprises the randomness consumed by the sharding algorithm.  The sharding randomness is a random byte string of length specified by the VDAF.  The Client MUST generate this using a <del> cryptographicallly secure random number generator. </del> <ins> cryptographically secure random number generator. </ins> The Client then wraps each input share in the following structure:

Related discussion:
text: As of draft-irtf-cfrg-vdaf-05 (not yet published), the random coins used for sharding are an explicit parameter of . Add this parameter and explasin how it is generated.
NAME I believe this is the only API change we need to account for, correct?
Code change:
When a client wants to establish a TLS session with the backend server, it constructs its ClientHello as usual (we will refer to this as the ClientHelloInner message) and then encrypts this message using <del> the ECH public key.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an </del> <ins> the public key of the ECH configuration.  It then constructs a new ClientHello (ClientHelloOuter) with innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and with an </ins> "encrypted_client_hello" extension, which this document defines <del> (encrypted-client-hello).  Finally, it sends ClientHelloOuter to the server. </del> <ins> (encrypted-client-hello).  The extension's payload carries the encrypted ClientHelloInner and specifies the ECH configuration used for encryption.  Finally, it sends ClientHelloOuter to the server. </ins> Upon receiving the ClientHelloOuter, the client-facing server takes one of the following actions:

Related discussion:
text: In places, the current draft doesn't make a clear distinction between rejection and decryption failure. In particular "cannot decrypt" can be interpreted either: "the client-facing server doesn't recognize the configuration specified by the client"; or "the client-facing server recognizes the configuration but decryption fails". This change resolves this ambiguity. Addresses issue .
Two sections suggest to ignore the extension on decryption failure, but one suggests to send an alert. What should happen? Ignoring the extension on unrecognized failures sounds reasonable in order to "not stick out". However, it is not entirely unambiguous what to do if a valid ECHConfig is found but decryption fails. says: says: says:
I think the first two statements apply when the config_digest doesn't correspond to a known ECHConfig (i.e., "I can't decrypt this"); the last is when the ECHConfig is known, but decryption fails ("I should be able to decrypt this, but the ciphertext is invalid"). The text could be a lot clearer here.
NAME Yes, your interpretation is correct. I think this is the result of a number of uncoordinated changes.
Closing as resolved.
Code change:
4.5.6. <del> Before an Aggregator responds to a CollectReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </del> <ins> Before an Aggregator responds to a CollectionReq or AggregateShareReq, it must first check that the request does not violate the parameters associated with the DAP task.  It does so as described here. </ins> First the Aggregator checks that the batch respects any "boundaries" determined by the query type.  These are described in the subsections

Related discussion:
text: All references to "metadata" are now to "report_metadata". References to "CollectReq" are now "CollectionReq". References to "CollectResp" are now "Collection".
The current version of the draft renames field "metadata" to "report_metadata" in the Report structure, but does not do the same renaming in the ReportShare and InputShareAad structures. I think this naming should be consistent, though I don't have a preference between the alternatives.
Thanks for pointing this out! Can you send prepare a PR?
Fixed in
Thanks a bunch NAME
Code change:
value to distinguish cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <ins> The "profile_id" field MUST identify the profile that is in use.  A zero-length ID corresponds to the cTLS default protocol.  The server's reply does not include the "profile_id", because the server must be using the same profile indicated by the client. </ins> Encrypted records use DTLS 1.3 RFC9147 record framing, comprising a configuration octet followed by optional connection ID, sequence number, and length fields.  The encryption process and additional

Related discussion:
text: FYI, this PR now moves out of the ClientHello back into (now called ). This avoids confusing questions about how to demultiplex profiles that use different modes.
LGTM.
This would allow recipients to detect the end of a handshake message from the CTLSPlaintext header alone, allowing the recipient to reconstruct the entire handshake message before parsing it. Currently, a streaming parser is required in order to detect the end. Suggested implementation: Senders set contenttype = ctlshandshake_end for a message’s final fragment.
I can see why you want that, but it's not generally a TLS property, and I'm reluctant to change things.
AFAIK, TLS does not require a streaming ClientHello parser. The recipient can read (uint24) and then buffer the remainder before parsing. cTLS, as currently specified, does not have . This means that the recipient has to cross all the way down into the extension parsing code before it finds out that the ClientHello is still incomplete. Given the complex template-driven handshake parsing code, I think making a streaming parser required is ill-advised. Given the desire for compactness, I think a flag of some kind on the final handshake message record seems like a reasonable solution, replacing the uint24 length. It would also simplify Pseudorandom cTLS. However, if that's not appealing, you could simply reintroduce .
NAME proposed a solution on slide 5 : I'm fine with that, so long as it doesn't end up requiring recipients to do something heroic to reconstruct the ClientHello. Thus, "framing = none" should imply that messages cannot be fragmented at all (max size limited to 2^14-1). I'm not sure I see the utility of the explicit distinction between "length" and "full". Surely "length" is not usable with DTLS due to reordering, and "full" is redundant in TLS/TCP. Perhaps we only need a single bit to enable/disable framing, and length-vs-full can be implicit from the transport.
I could live with this. Objections?
Solved by
The current text doesn’t mention this, although it seems relatively clear how it’s expected to work (using the DTLS Handshake struct).
Code change:
2.5.5.2.1. <del> A path by itself in a Logical context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. </del> <ins> A query by itself in a Logical context is an existence test which yields true if the query selects at least one node and yields false if the query does not select any nodes. </ins> Existence tests differ from comparisons in that: <del> they work with arbitrary relative or absolute paths (not just Singular Paths). </del> <ins> they work with arbitrary relative or absolute queries (not just Singular Queries). </ins> <del> they work with paths that select structured values. </del> <ins> they work with queries that select structured values. </ins> <del> To examine the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a query, an explicit </ins> comparison is necessary.  For example, to test whether the node <del> selected by the path "@.foo" has the value "null", use "@.foo == </del> <ins> selected by the query "@.foo" has the value "null", use "@.foo == </ins> null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).

Related discussion:
text: XPath terminology is a bit weird, because XPath has a somewhat competing standard XQuery... XPath is based on DSSSL, which had a complex expression language for building paths in the XML trees that was based on the Scheme language. (Which is the experience that makes me hesitant just jumping headlong into another expression language...)
LGTM with that change. Thanks!
Code change:
the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The Transport Services implementation needs to ensure that all of the events and actions taken on a Message Framer are synchronized to ensure consistent behavior.  For example, some of the actions defined below (such as PrependFramer and StartPassthrough) modify how data flows in a protocol stack, and require synchronization with sending and parsing data in the Message Framer. </ins> When a Connection establishment attempt begins, an event can be delivered to notify the framer implementation that a new Connection is being created.  Similarly, a stop event can be delivered when a

Related discussion:
text: It seems blindingly obvious to me that an implementation would need to take care of this... and this note of caution seems quite appropriate (if unnecessary... but surely it doesn't hurt).
Dynamic framer add and passthrough (last two paragraphs of section 6.1) assume synchronous operation; what happens to bytes in the send/receive buffers when the framer stack changes? There either needs to be an explicit mutex here (allowing the framer/implementation to lock the buffers at the exact point the framer change happens, not allowing any bytes to be processed while the dynamic framer decision is made), or some way to annotate in a buffer the replay point after which a dynamic reframing is necessary. Are we going to leave this up to implementors to figure out, or should we point out that here be dragons?
We should clarify that these operations within the data path of the stack should be synchronized.
Code change:
JSEP's handling of session descriptions is simple and straightforward.  Whenever an offer/answer exchange is needed, the initiating side creates an offer by calling a createOffer() API.  The <del> application optionally modifies that offer, and then uses it to set up its local config via the setLocalDescription() API.  The offer is then sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </del> <ins> application then uses that offer to set up its local config via the setLocalDescription() API.  The offer is finally sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. </ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it

Related discussion:
text: Did we not decide that modifying that offer (or an answer created by createAnswer()) is not allowed?
Agreed. This text should be culled.