jiebi/CodeConvo huggingface dataset:
Change:
the client's pre-registered record.  See additional considerations regarding client instance impersonation in security-impersonation. <ins> A client instance that is capable of talking to multiple AS's SHOULD use a different key for each AS to prevent a class of mix-up attacks as described in security-cuckoo. </ins> 2.3.1. If the client instance has an instance identifier that the AS can use

Discussion:
Added security considerations for cuckoo token,
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 31f2c2dc7998639fe7801edeaa8334eef14d0963 Inspect the deploy log: Browse the preview:
Client instance uses different keys with each AS Stolen token bound to different keys, RS will reject Client has strong binding between RS and AS used Attacker can’t convince client to use “wrong” AS
Change:
An "a=msid" line, as specified in I-D.ietf-mmusic-msid, Section 2. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf- rtcweb-rtp-usage. If RTX has been negotiated for this m= section, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC has been negotiated for this m= section, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> Each m= section which is not bundled into another m= section, MUST contain the following attributes (which are of category IDENTICAL or TRANSPORT):

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
running over QUIC QUIC with a mechanism to send unreliable data while leveraging the security and congestion-control properties of QUIC. However, QUIC DATAGRAM frames do not provide a means to demultiplex <del> application contexts.  This document defines how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3 by adding an identifier at the start of the frame payload.  This allows HTTP messages to convey related information using unreliable DATAGRAM frames, ensuring those frames are properly associated with an HTTP message. </del> <ins> application contexts.  This document describes how to use QUIC DATAGRAM frames when the application protocol running over QUIC is HTTP/3 H3.  It defines logical flows identified by a non-negative integer that are present at the start of the DATAGRAM frame payload. Flows are associated with HTTP messages using the Datagram-Flow-Id header field, allowing endpoints to match unreliable DATAGRAMS frames to the HTTP messages that they are related to. </ins> This design mimics the use of Stream Types in HTTP/3, which provide a demultiplexing identifier at the start of each unidirectional stream.

Discussion:
This somewhat of an experiment. While trying to address I got distracted by the document's use of the "flow identifier" term. The document likes to compare "flow identifiers" with QUIC streams, which is fine. But QUIC makes the distinction between streams and stream IDs; the ID is a property of the stream but it isn't the only one, and sometimes it helps to talk about the stream in other contexts. This change tries to channel a similar editorial style. It replaces: "flow identifiers" with "flows" when talking about a logical entitiy "flow identifiers" with "flow IDs" when talking about the wire format, encoding, examples etc. This could be a change too far but I figured it would be a good discussion starter.
The draft doesn't do this. It relies on the QUIC varint encoding for non-negativity in DATAGRAM frames but could contain a negative value. Let's be clear in the spec.
Definitely agree, could you write a PR please?
I will.
fixed in URL
Thanks!
Change:
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the IANA <del> registry then allocate a new EXI schemaID.  Moving to the next letter in the alphabet is the suggested way to create the new EXI schemaID. Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaID value. </del> <ins> registry then allocate a new EXI schemaId value.  Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId.  Any labels with previously blank ID values SHOULD be updated in the IANA table to have their ID set to this new schemaId value. </ins> 11.3.

Discussion:
Make sure the way we use schemaID match how it is defined in EXI. ( See email from Christian G - Oct 10, 2016 )
Change:
use in TLS.  Only three have seen any use.  This specification is deprecating the rest (with numbers 1-22).  This specification also deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. <del> This leaves only the following: </del> <ins> It also adds the new curves defined in CFRG-Curves.  The end result is as follows: </ins> Note that other specification have since added other values to this enumeration. secp256r1, etc: Indicates support of the corresponding named curve or <del> class of explicitly defined curves.  The named curves defined here are those specified in SEC 2 SECG-SEC2.  Note that many of these </del> <ins> class of explicitly defined curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 SECG-SEC2.  These </ins> curves are also recommended in ANSI X9.62 ANSI.X9-62.2005 and FIPS <del> 186-4 FIPS.186-4.  Values 0xFE00 through 0xFEFF are reserved for private use. </del> <ins> 186-4 FIPS.186-4.  Curve25519 and Curve448 are defined in CFRG- Curves.  Values 0xFE00 through 0xFEFF are reserved for private use. </ins> The NamedCurve name space is maintained by IANA.  See iana for information on how new value assignments are added.

Discussion:
Added new curves and new authors. Partial merge of draft-ietf-tls-curve25519
Change:
QUIC <del> ESP IPsec OpenVPN </del> tcpcrypt MinimaLT <ins> IPsec ESP </ins> WireGuard <ins> OpenVPN </ins> 5.2. Identity Validation (IV): During a handshake, the security

Discussion:
Read through the Opsdir review we recently got. Not sure we want to add anything to that BGP questions, but there was also a minor editorial nit, which this PR fixes. Now the order of these protocols is the same as in the table.
Change:
DeriveKeyPair. The constants "Ne" and "Ns" are as defined in OPRF, Section 4 for <del> OPRF(P-384, SHA-384). </del> <ins> OPRF(P-384, SHA-384).  The constant "Nk" is defined by private-token- type. </ins> 5.1.

Discussion:
doesn't define . The preceding text to the example says that Nk is 512, but AFAICT the value of Nk is not relevant to the example.
Section 8.2 defines Nk=256 for type 0x0002. Section 6.1 should still apply for any value Nk if another type is added for a different size key. My two suggestions would be: (1) mention in Section 6.1 that Nk is fixed according to the token type definition and (2) use Nk=256 for the example so it matches the only currently defined blind token type (0x0002).
Change:
4.1.1. The configuration agent selects a number of bytes of the server <del> connection ID (SCID) to encode individual server IDs, called the "routing bytes".  The number of bytes MUST have enough entropy to have a different code point for each server. </del> <ins> connection ID to encode individual server IDs, called the "routing bytes".  The number of bytes MUST have enough entropy to have a different code point for each server. </ins> It also assigns a server ID to each server.

Discussion:
Server CID will collide with Source CID.
This is often used to mean Source Connection ID in other contexts. A collision here is likely to cause confusion.
Recommended name? SCCID?
I think it might just be best to call it the "Server CID" any other abbreviated term will get confused IMO.
"Server CID" doesn't seem to fit well with "Stream Cipher Connection ID"
So SCID didn't mean "Server Connection ID"? There is definitely confusion here. I'd just recommend not abbreviating anything more than CID.
I guess this proves MT's point. "STream Cipher Connection ID" (just like PCID, OCID, BCID)
Looking again, the document never uses any acronym for 'stream cipher connection ID', so there's no issue there. This is just about 'S' meaning "source" or "server".
Change:
Removing header protection only differs in the order in which the packet number length (pn_length) is determined. <ins> Specific header protection functions are defined based on the selected cipher suite; see hp-aes and hp-chacha. </ins> fig-sample shows an example long header packet (Initial) and a short header packet. fig-sample shows the fields in each header that are covered by header protection and the portion of the protected packet

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:
The setLocalDescription method instructs the PeerConnection to apply the supplied session description as its local configuration.  The type field indicates whether the description should be processed as <del> an offer, provisional answer, or final answer; offers and answers are checked differently, using the various rules that exist for each SDP line. </del> <ins> an offer, provisional answer, final answer, or rollback; offers and answers are checked differently, using the various rules that exist for each SDP line. </ins> This API changes the local media state; among other things, it sets up local resources for receiving and decoding media.  In order to

Discussion:
This addresses Adam's actual comment - and adds the first references to rollback in the processing section - but leaves the details to be filled in by a future PR.
LGTM
Change:
3. <del> The grease_quic_bit transport parameter (0x2ab2) can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </del> <ins> The grease_quic_bit transport parameter (0x2ab2) is defined for QUIC version 1 QUIC.  This transport parameter can be sent by both client and server.  The transport parameter is sent with an empty value; an endpoint that understands this transport parameter MUST treat receipt of a non-empty value of the transport parameter as a connection error of type TRANSPORT_PARAMETER_ERROR. </ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC <del> Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del> <ins> Bit is defined as the second-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> 3.1.

Discussion:
These are all the changes I found from the text diff, plus some extra changes about versions.
I have reviewed the changes, and I agree that they are editorial in nature.
Change:
first request occurs on QUIC stream 0, with subsequent requests on stream 4, 8, and so on.  In order to permit these streams to open, an HTTP/3 server SHOULD configure non-zero minimum values for the number <del> of permitted streams and the initial stream flow control window.  It is RECOMMENDED that at least 100 requests be permitted at a time, so as to not unnecessarily limit parallelism. </del> <ins> of permitted streams and the initial stream flow control window.  So as to not unnecessarily limit parallelism, at least 100 requests SHOULD be permitted at a time. </ins> HTTP/3 does not use server-initiated bidirectional streams, though an extension could define a use for these streams.  Clients MUST treat

Discussion:
At the interim, we talked about this not being an interop requirement, but "a really good idea" which still warrants RFC2119 language. So, keeping the all-caps, but taking the suggestion to make it active voice.

That was never an interoperability requirement, just a suggestion. So I think that this should be reverted. Originally posted by NAME in URL Look at a better way to phrase this guidance, while still retaining the guidance. (Note this text has also been touched by other PRs in the meantime.)
Change:
Home and building automation use case: Tie in with RD <ins> Simple registration: Rather than coopting POSTs to /.well-known/ core, a new resource /.well-known/rd is registered.  A historical note in the text documents the change. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)

Discussion:
No deployed implementations of simple registration are known that can't switch over easily. As per URL
Change:
to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. <ins> In some scenarios, an endpoint might want to send a CLOSE_WEBTRANSPORT_SESSION with detailed close information and then immediately close the underlying QUIC connection.  If the endpoint were to do both of those simultaneously, the peer could potentially receive the CONNECTION_CLOSE before receiving the CLOSE_WEBTRANSPORT_SESSION, thus never receiving the application error data contained in the latter.  To avoid this, the endpoint SHOULD wait until all of the data on the CONNECT stream is acknowledged before sending the CONNECTION_CLOSE; this gives CLOSE_WEBTRANSPORT_SESSION properties similar to that of the QUIC CONNECTION_CLOSE mechanism as a best-effort mechanism of delivering application close metadata. </ins> 6. [[RFC editor: please remove this section before publication.]]

Discussion:
This is mostly based on what Chrome currently does in production.
Chair: discussed during editor's meeting, plan is to remove text about 3 PTO and note that delivering other open streams is best-effort. Also add rationale and mention that this aligns with what QUIC does - this message has similar delivery guarantees as the close_connection in QUIC
A common use (at least for non-pooled WebTransport connections) will be to close the underlying QUIC connection when closing the WebTransport session. This is inherently racy: The sender will send both a CLOSEWEBTRANSPORTSESSION capsule and a QUIC CONNECTIONCLOSE frame (unless you wait for the peer's FIN on the request stream, but why would you?). It's undetermined which one of the two will be received / processed first by the receiver. This is not a problem if the sender uses the same error code and error message for the CONNECTIONCLOSE frame and for the CLOSEWEBTRANSPORTSESSION capsule. Assuming the QUIC stack properly exposes these values on its API, the receiver will be able to learn error code and error message. Should we add that as a recommendation, or even a requirement?
Chair: discussed during editor's meeting, see URL
Change:
descriptions, instead offering APIs that would control each component directly.  This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer <del> would not be beneficial; it would result in an API where even a </del> <ins> would not be beneficial; it would (1) result in an API where even a </ins> simple example would require a significant amount of code to <del> orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented.  In </del> <ins> orchestrate all the needed interactions and (2) create a large API surface that would need to be agreed upon and documented.  In </ins> addition, these API points could be called in any order, resulting in a more complex set of interactions with the media subsystem than the JSEP approach, which specifies how session descriptions are to be

Discussion:
Updated a few sentences in Section 1 regarding XMPP and SIP libraries and the API surface. Removed comments. issue 5 and issue 6.
6) [rfced] Section 1.2: We had trouble parsing this sentence. If the suggested text is not correct, please clarify "as well as creating ..." Original (the previous sentence is included for context): A second approach that was considered but not chosen was to decouple the management of the media control objects from session descriptions, instead offering APIs that would control each component directly. This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions, as well as creating a large API surface that needed to be agreed upon and documented. Suggested: This was rejected based on the argument that requiring exposure of this level of complexity to the application programmer would not be beneficial; it would (1) result in an API where even a simple example would require a significant amount of code to orchestrate all the needed interactions and (2) create a large API surface that needed to be agreed upon and documented.
This mostly LGTM, but the final sentence reads a bit oddly now - perhaps
Change:
The semantics for starting and ending a batch can be implementation- specific, but need to allow multiple Send Actions to be enqueued. <del> 8.2.6. </del> <ins> 8.2.5. </ins> For application-layer protocols where the Connection initiator also sends the first message, the InitiateWithSend() action combines

Discussion:
says: But it appears the Connection object is still required to call Send, so what value does this provide? I.e., how are you supposed to use replyMessageContext from the example?
I agree - it seems to me now that this really adds no value. What am I missing? I'm assigning NAME because he was among the first to propose this... maybe he can explain
Ping :)
Interim: We will remove all "reply/replies" from the API doc.
Change:
User Equipment may send traffic to hosts blocked by the captive network prior to the Enforcement device granting it access.  The Enforcement Device rightly blocks or resets these requests.  However, <del> lacking a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </del> <ins> in the absence of a signal from the Enforcement Device or interaction with the API server, the User Equipment can only guess at whether it is captive.  Consequently, allowing the Enforcement Device to explicitly signal to the User Equipment that the traffic is being blocked may improve the user's experience. </ins> <del> An Enforcement Device may also want to inform the User Equipment of a </del> <ins> An Enforcement Device may also want to notify the User Equipment of a </ins> pending expiry of its access to the external network, so providing the Enforcement Device the ability to preemptively signal may be desirable.

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
The actual content type of the record. <ins> An arbitrary-length run of null bytes (uint8 with value 0) may appear in the cleartext after the type field.  This provides an opportunity for senders to pad any TLS record by a chosen amount as long as the total stays within record size limits.  See record- padding for more details. </ins> The AEAD encrypted form of TLSPlaintext.fragment + <del> TLSPlaintext.type, where "+" denotes concatenation. </del> <ins> TLSPlaintext.type + zeros, where "+" denotes concatenation. </ins> The length of the per-record nonce (iv_length) is set to max(8 bytes, N_MIN) for the AEAD algorithm (see RFC5116 Section 4).  An AEAD

Discussion:
This is a big improvement over the previous proposed methods, by the way. NAME I suggest filing a followup PR for your comments, as it looks like this has already merged.
Change:
4.2. <ins> When an error occurs processing the capsule protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed messages is described in section 4.1.3 of H3.  For HTTP/2, the handling of malformed messages is described in section 8.1.2.6 of H2. For HTTP/1.1, the handling of incomplete messages is described in section 8 of CORE-MESSAGING. Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes after the identified fields or a capsule payload that terminates before the end of the identified fields MUST be treated as a malformed or incomplete message.  In particular, redundant length encodings MUST be verified to be self-consistent. When a stream carrying capsules terminates cleanly, if the last capsule on the stream was truncated, this MUST be treated as a malformed or incomplete message. 4.3. </ins> Definitions of new HTTP Upgrade Tokens that use the Capsule Protocol MAY use the Capsule-Protocol header field to simplify intermediary processing.

Discussion:
Borrowing text from H3. Also I don't think there is a 'FRAMEENCODINGERROR' defined anywhere.
Thanks! Approved pending some minor tweaks