jiebi/CodeConvo huggingface dataset:
Change:
"ECHConfig.cipher_suites" list. The configuration identifier, equal to "Expand(Extract("", <del> config), "tls ech config id", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) The length of this value SHOULD NOT be less than 16 bytes unless it is optional for an application; see optional-configs. </del> <ins> config), "tls ech config id", 8)", unless it is optional for an application; see optional-configs. "config" is the "ECHConfig" structure.  "Extract" and "Expand" are as specified by the cipher suite KDF.  (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "payload" field.

Discussion:
This doesn't bind anything, so no sense wasting bytes. (Note: this is orthogonal to , but it makes more sense with that PR.)
I guess this makes the text in a little odd because "Compare ClientECH.config_id against identifiers of known ECHConfigs and select the one that matches, if any, as a candidate.", is a little less clear. If we want to do this, it maybe should say "and select any that match", even though there'll really just be one match.
(Rebased and made the text talk about multiple potential matches.)
This matches the acceptance signal length, and we've already accepted that probability of collision.
I agree this is fine.
Change:
This event is emitted when a packet is buffered because it cannot be processed yet.  Typically, this is because the packet cannot be <del> parsed yet, and thus we only log the full packet contents when it was parsed in a packet_received event. </del> <ins> parsed yet, and thus only the full packet contents can be logged when it was parsed in a packet_received event. </ins> Definition:

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
for flow control purposes and MUST generate and send appropriate flow control signals for their limits. <del> 6. </del> <ins> 5.11. </ins> WebTransport over HTTP/2 uses the DATAGRAM capsule defined in Section 3.5 of HTTP-DATAGRAM to carry datagram traffic.

Discussion:
Moved the later section up, fixed up some sections, and consolidated some of the text.
When I did , I hadn't read Section 8. My suggestion is that this be merged into the material from the (current) Sections 4 and 5. Also, this is the first use of Http2Transport. I think that we should remove that. It's a fine class name for a C++ implementation, but we don't use it elsewhere.
Just to make sure I understand, the idea is for this "what properties do we provide and how do they satisfy the WT requirements" part to be up front with 4/5? Seems good to me. Yeah, that's mostly leftover from previous versions where we had a more defined name. Can clean up and not lose anything of value, I think.
Change:
the main Connection implementation that delivers events to the custom framer implementation whenever data is ready to be parsed or framed. <ins> The API examples in this section use the notation conventions for the Transport Services API defined in Section 1.1 of I-D.ietf-taps- interface. </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

Discussion:
Framers: The paragraphs in Defining Message Framers and later might be formal language or pseudocode, I can't tell. It might help if the introduction stated something around names and signatures of signals and functions being expressed in pseudocode, and that identifiers in implementations are expected to be similar to those but following the conventions of the language
We should reference section 1.1 of the API document which defines the notation used.
Change:
this may be revisited in future revisions. The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. <del> This is derived from the fact that permitting I servers lead to 2^I </del> <ins> This is derived from the fact that permitting I Issuers lead to 2^I </ins> segregations of the total user-base U.  Moreover, if we permit M = 1, <del> then this effectively halves the anonymity set for each server, and </del> <ins> then this effectively halves the anonymity set for each Issuer, and </ins> thus we incur a factor of 2I in the exponent.  By reducing I, we limit the possibility of performing the attacks mentioned in privacy. We must also account for each user holding issued data for more then one possible active keys.  While this may also be a vector for <del> monitoring the access patterns of clients, it is likely to unavoidable that clients hold valid issuance data for the previous key epoch.  This also means that the server can continue to verify </del> <ins> monitoring the access patterns of Clients, it is likely to unavoidable that Clients hold valid issuance data for the previous key epoch.  This also means that the Issuer can continue to verify </ins> redemption data for a previously used key.  This makes the rotation <del> period much smoother for clients. </del> <ins> period much smoother for Clients. </ins> For privacy reasons, it is recommended that key epochs are chosen <del> that limit clients to holding issuance data for a maximum of two </del> <ins> that limit Clients to holding issuance data for a maximum of two </ins> keys.  By choosing F = L/2 then the minimum value of F is a week, since the minimum recommended value of L is 2 weeks.  Therefore, by the initial assumption, then all users should only have access to

Discussion:
This reshuffles quite a bit to frame Privacy Pass as two protocols -- issuance and redemption -- run between Clients, Mediators, Issuers, and Origins. First draft, so there may be things we want to rephrase or reflow. Rendered view of this PR .
Whitespace errors?
NAME fixed!
Merging this per the discussion during the interim meeting today.
A few comments; thanks for the quick turnaround!
Change:
If a server has not received a valid QUIC-LB configuration, and believes that low-state, Connection-ID aware load balancers are in the path, it SHOULD generate connection IDs with the config rotation <del> bits set to '11' and SHOULD use the "disable_active_migration" </del> <ins> bits set to 0b11 and SHOULD use the "disable_active_migration" </ins> transport parameter in all new QUIC connections.  It SHOULD NOT send NEW_CONNECTION_ID frames with new values. A load balancer that sees a connection ID with config rotation bits <del> set to '11' MUST revert to 5-tuple routing.  These connection IDs may be of any length; however, see cid-entropy for limits on this length. </del> <ins> set to 0b11 MUST route using an algorithm based solely on the address/port 4-tuple, which is consistent well beyond the QUIC handshake.  However, a load balancer MAY observe the connection IDs used during the handshake and populate a connection ID table that allows the connection to survive a NAT rebinding, and reduces the probability of connection failure due to a change in the number of servers. When using codepoint 0b11, all bytes but the first SHOULD have no larger of a chance of collision as random bytes.  The connection ID SHOULD be of at least length 8 to provide 7 bytes of entropy after the first octet with a low chance of collision.  Furthermore, servers in a pool SHOULD also use a consistent connection ID length to simplify the load balancer's extraction of a connection ID from short headers. </ins> 2.3.

Discussion:
The '11' codepoint might be better defined. It would be good, for instance, if a stateful load balancer actually stored the observed CID so that the connection can survive a NAT rebinding.
Actually this is a bit harder than we'd like. If the load balancer is stateless, then the short-header processing would have to be based on the destination connection ID to be robust to NAT rebinding. But then, as the connection ID will change mid-handshake, long-header processing needs a different approach. I don't see how, logically, a stateless LB can maintain consistency between these two results unless we force the unconfigured server to retain most of the client-generated CID.
Having reflected on this a bit more, this is what I think we should do: Keep 0b11 as 4-tuple routing. However Load Balancers MAY observe destination connection IDs and keep state on them, to later survive a NAT rebinding. I see two use cases for 0b11: (1) a general purpose server that always uses QUIC-LB, whether or not it's behind an LB, for simplicity. So when it's not behind a Layer 4 LB it just generates random CIDs except for the first byte. As an added bonus, if there is an unknown L4 LB in front of it the behavior will not be pathological, at least until there's a migration. But in general, the rebinding performance is not all that important. (2) As a panic mode when things are misconfigured or the server has run out of nonces. Again, I'm not sure rebinding performance is super-critical. In other words, if a server is behind an L4 load balancer is and is using 0b11, something has gone very wrong.
Change:
Recently, a number of Web-based identity technologies (OAuth, Facebook Connect etc.) have been developed.  While the details vary, what these technologies share is that they have a Web-based (i.e., <del> HTTP/HTTPS) identity provider which attests to your identity.  For instance, if I have an account at example.org, I could use the example.org identity provider to prove to others that I was </del> <ins> HTTP/HTTPS) identity provider which attests to Alice's identity.  For instance, if Alice has an account at example.org, Alice could use the example.org identity provider to prove to others that Alice is </ins> alice@example.org.  The development of these technologies allows us <del> to separate calling from identity provision: I could call you on </del> <ins> to separate calling from identity provision: Alice could call you on </ins> Poker Galaxy but identify myself as alice@example.org. Whatever the underlying technology, the general principle is that the

Discussion:
In Section 7 I would suggest using Alice and Bob (or some other name) rather than "I" and "you/your." EMAIL is used there so the pronouns are mixed. Same comment for 9.1 -- I would suggest replacing "your" with "the user's."
Change:
As recommended in Section 5.8 of I-D.ietf-ace-oauth-authz, this specification uses CBOR web tokens to convey claims within an access token issued by the server.  While other formats could be used as <del> well these are out of scope for this document. </del> <ins> well, those are out of scope for this document. </ins> 1.1.

Discussion:
Change last sentence of Introduction from: While other formats could be used as well these are out of scope for this document. to: While other formats could be used as well, those are out of scope for this document.
Good point, thank you!
Change:
%%% Authentication Messages struct { digitally-signed struct { opaque handshake_hash[hash_length]; }; } CertificateVerify; <del> Where session_hash is as described in the-handshake-hash and </del> <ins> Where handshake_hash is as described in the-handshake-hash and </ins> includes the messages sent or received, starting at ClientHello and up to, but not including, this message, including the type and length fields of the handshake messages.  This is a digest of the

Discussion:
The struct contains a value named handshakehash, not sessionhash. I apparently had fixed this in PR . Pulling it out separately to get it in now, as it hasn't even been decided for sure if we're doing that.
Change:
SIGMA (SIGn-and-MAc) is a family of theoretical protocols with a large number of variants SIGMA.  Like in IKEv2 RFC7296 and (D)TLS 1.3 RFC9147, EDHOC authenticated with signature keys is built on a <del> variant of the SIGMA protocol which provides identity protection of the Initiator (SIGMA-I) against active attackers, and like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. </del> <ins> variant of the SIGMA protocol, SIGMA-I, which provides identity protection against active attacks on the party initiating the protocol.  Also like IKEv2, EDHOC implements the MAC-then-Sign variant of the SIGMA-I protocol shown in fig-sigma. </ins> The parties exchanging messages in an EDHOC session are called <del> Initiator (I) and Responder (R).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </del> <ins> Initiator (I) and Responder (R), where the Initiator sends message_1 (see overview).  They exchange ephemeral public keys, compute a shared secret session key PRK_out, and derive symmetric application keys used to protect application data. </ins> G_X and G_Y are the ECDH ephemeral public keys of I and R, respectively.

Discussion:
Addresses
Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. URL
Yes, we will add that
Closing this as PR is merged. Reviewer: Christer Holmberg Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lake-edhoc-18 Reviewer: Christer Holmberg Review Date: 2022-12-20 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, and easy to read. I do have one minor issue that I would like the authors to address. Major issues: N/A Minor issues: Q1: The document talks about the Initiator and Responder roles, what messages they send etc. But I can't find a definition of what the roles. I assume the Initiator initiates something, but unless I have missed it it would be good to have a few word of role definitions. Nits/editorial comments: N/A
Change:
(respectively _right subtree_). All trees used in this protocol are left-balanced binary trees.  A <del> binary tree is _full_ (and _balanced_) if it its size is a power of two and for any parent node in the tree, its left and right subtrees have the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </del> <ins> binary tree is _full_ (and _balanced_) if its size is a power of two and for any parent node in the tree, its left and right subtrees have the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </ins> A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest

Discussion:
The very first commit from PR (6ba86ff561484a9eb96012e3b55b49f23cb8f9e9) was removed and a separate Issue is filled for unifying the use of "`" and "_".
We inconsistently use the backtick, the underscore or nothing for messages fields or specific operations in the draft. This needs a fix, currently the opinion is to use the TLS style (aka remove everything)
Change:
if it was the last status sent for that path - as indicated by the sequence number. <del> 8.3. The ACK_MP frame (types TBD-00 and TBD-01; experiments use 0xbaba00..0xbaba01) is an extension of the ACK frame defined by QUIC- TRANSPORT.  It is used to acknowledge packets that were sent on different paths using multiple packet number spaces.  If the frame type is TBD-01, ACK_MP frames also contain the sum of QUIC packets with associated ECN marks received on the connection up to this point. ACK_MP frame is formatted as shown in fig-ack-mp-format. Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added. The sequence number of the Connection ID identifying the packet number space of the 1-RTT packets which are acknowledged by the ACK_MP frame. </del> 9. Multipath QUIC transport error codes are 62-bit unsigned integers

Discussion:
The ACKMP text does not change, it just comes before PATHABANDON and PATHSTATUS. The rationale is that 1) the new order follows the encoding numbering (lowest to highest), and 2) the ACKMP is a critical frame, the PATHABANDON is an important one yet still "indicative" (it suggests the peer to abandon this path) and the PATHSTATUS frame is an indicative one.
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
OK. It's reasonable.
Change:
that a new incoming stream should be represented as a new Connection Object by the Transport Services system.  A new SCTP stream is created by sending an SCTP message with a new stream id.  Thus, to <del> implement stream mapping, the Transport Services API MUST provide a </del> <ins> implement stream mapping, the Transport Services API must provide a </ins> newly created Connection Object to the application upon the reception of such a message.  The necessary semantics to implement a Transport Services system Close and Abort primitives are provided by the stream reconfiguration (reset) procedure described in RFC6525.  This also allows to re-use a stream id after resetting ("closing") the stream. To implement this functionality, SCTP stream reconfiguration RFC6525 <del> MUST be supported by both the client and the server side. </del> <ins> must be supported by both the client and the server side. </ins> <del> To avoid head-of-line blocking, stream mapping SHOULD only be </del> <ins> To avoid head-of-line blocking, stream mapping should only be </ins> implemented when both sides support message interleaving RFC8260. This allows a sender to schedule transmissions between multiple streams without risking that transmission of a large message on one

Discussion:
Two items here: Normative MUST? I guess this is just a guidance document so doesn't need anything normative. There's some later "should" as well which I would generally ask the same question for. but... here we have some NORMATIVE language. That SHOULD should probably be non-capitalised to align with earlier usage. (and so on later in the document, e.g. in the SCTP description)
The first one can just be "uses the default values", without normative text. Second one can be lowercase as well. SCTP has normative SHOULDs and MUSTs that can be removed.
Change:
RecordSizeLimit: The value of RecordSizeLimit is the maximum size of record in octets <del> that the endpoint is willing to receive.  When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer.  Unprotected messages - handshake messages in particular - are not subject to this limit. </del> <ins> that the endpoint is willing to receive.  This value is used to limit the size of records that are created when encoding application data and handshake message into records. When the "record_size_limit" extension is negotiated, an endpoint MUST NOT generate a protected record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. Unprotected messages - handshake messages in particular - are not subject to this limit. </ins> This value is the length of the plaintext of a protected record.  The value includes the content type and padding added in TLS 1.3 (that

Discussion:
NAME requests: I believe we should re-word the text in the draft in such a way that it does not say record with plaintext that is larger than the RecordSizeLimit value it receives from its peer. but instead says what you explained below. In essence, the RecordSizeLimit value can then be used by the TLS stack to determine the size of the fragments. "below" being that when writing, the limit determines when to create new records. It shouldn't prohibit writes that exceed the limit.
Change:
Abstract <del> The Real-Time Communications on the Web (RTCWEB) working group is tasked with standardizing protocols for real-time communications between Web browsers, generally called "WebRTC".  The major use cases for WebRTC technology are real-time audio and/or video calls, Web conferencing, and direct data transfer.  Unlike most conventional real-time systems (e.g., SIP-based soft phones) WebRTC communications are directly controlled by a Web server, which poses new security challenges.  For instance, a Web browser might expose a JavaScript API which allows a server to place a video call.  Unrestricted access to such an API would allow any site which a user visited to "bug" a user's computer, capturing any activity which passed in front of their camera.  This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </del> <ins> WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. </ins> 1.

Discussion:
I suspect we'll get dinged here for referring to the RTCWEB WG by name. I'm thinking we can just trim it down to be a one sentence blurb (stolen from overview) and then say this is the threat model/analysis.
Change:
The DATAGRAM capsule (see iana-types for the value of the capsule type) allows an endpoint to send a datagram frame over an HTTP stream.  This is particularly useful when using a version of HTTP <del> that does not support QUIC DATAGRAM frames.  Its Capsule Data field consists of: </del> <ins> that does not support QUIC DATAGRAM frames. </ins> A variable-length integer indicating the context ID of the datagram (see datagram-contexts).  Whether or not this field is

Discussion:
The thing that sucks here is that the diagram won't auto expand , so we can't easily ref the section. Manually referring to the section is a maintenance pain. So instead just state the actual type in the text an the diagram. I have a feeling you were linking to the section to avoid the maintenance hassle of updating type codes in multiple place. But I'm quite happy to take that burden because I find it more pleasant to read this way.
Perfectly reasonable
QUIC and HTTP/3 style is to define the general format and then in each instance define the object including all of its fields. This would look like This can later be updated with the actual type value once things settle down
Fine by me.
There's a disparity between the largest flow ID that can be carried in the DATAGRAM frame and the largest that we can express in Datagram-Flow-Id. Draft 00 prevents a flow ID allocation of >= 10^15-1 but doesn't seem to address the case where a DATAGRAM frame contains that value. This is clearly an error, and I'd suggest that it is a connection error; probably or some new codepoint if we really wanted.
I don't think that needs to be an error, we can simply treat this like any other unknown flow ID?
IMO this is clearly a situation that shouldn't happen and indicates the sending endpoint probably has some bug. I'm not sure on what being silent on the matter helps.
This issue is no longer relevant now that we have merged , closing.
Change:
than 7 days. Verify that the certificate has the DelegationUsage extension, <del> which permits the use of Delegated credentials. </del> <ins> which permits the use of delegated credentials. </ins> Use the public key in the server's end-entity certificate to verify the signature on the credential.

Discussion:
These came up when I implemented the extension in Go (URL) and I think would be useful to add to the standard.
looks good to me