jiebi/CodeConvo huggingface dataset:
Change:
As the name implies, sometimes manpower is the easiest way to figure out which content to block.  Manual Filtering differs from the common <del> tactic of building up blacklists in that is doesn't necessarily </del> <ins> tactic of building up blacklists in that it doesn't necessarily </ins> target a specific IP or DNS, but instead removes or flags content. Given the imprecise nature of automatic filtering, manually sorting through content and flagging dissenting websites, blogs, articles and

Discussion:
A few more typos I found while I was reading this I-D.
Thanks again!
Change:
an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn. <del> 21.8. </del> <ins> 21.9. </ins> Stateless resets create a possible denial of service attack analogous to a TCP reset injection.  This attack is possible if an attacker is

Discussion:
Issue observes that this text mentions HTTP/2, which isn't necessary. In reviewing it, I noticed that this talks about messages that do nothing, but not really about messages that do little (or that can be reversed to have net zero effect). So I expanded the text a little.
Thanks for improving the section's clarity. As a follow up question, when implementations decide that excessive packets is an attack, is there a recommended actionable (eg. sending reset, dropping the connection, do nothing) or would that be up for implementer's discretion?
Maybe this needs to be stated explicitly, but there is no point in continuing discussion with an attacker. So while it might be considered polite to send a connection error, it is also acceptable to just drop any further incoming packets. I'll add that here.
Under the section Peer Denial of Service of TLS draft, a referenced was made to HTTP/2. URL I was wonder if this is in fact referring to HTTP/3 or HTTP/2. Also curious why the section is labelled
That mention of h2 was a mistake. I've made a few changes after reviewing this. (The thing is a joke.)
Change:
The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 6.5.2. </del> <ins> 6.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce"

Discussion:
Instead of defining a whole new key equivalence method just check the JWK verifies the inner JWS.
Change:
The Replay-Nonce header field SHOULD NOT be included in HTTP request messages. <del> 6.5.2. </del> <ins> 6.4.2. </ins> The "nonce" header parameter provides a unique value that enables the verifier of a JWS to recognize when replay has occurred.  The "nonce"

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
is no longer valid. The signature algorithm of the credential key pair, where the type <del> SignatureScheme is as defined in the TLS 1.3 standard. </del> <ins> SignatureScheme is as defined in the TLS 1.3 standard.  This is expected to be the same as CertificateVerify.algorithm sent by the server. </ins> The version of TLS in which the credential will be used, where the <del> type ProtocolVersion is as defined in TLS 1.3. </del> <ins> type ProtocolVersion is as defined in TLS 1.3.  This is expected to match the protocol version that is negotiated by the client and server. </ins> <del> The delegated credential's public key, which is an encoded SubjectPublicKeyInfo RFC5280. </del> <ins> The credential's public key, a DER-encoded SubjectPublicKeyInfo as defined in RFC5280. </ins> The delegated credential has the following structure: <del> The signature algorithm used to sign the delegated credential, where SignatureScheme is as defined in the TLS 1.3 standard. </del> <ins> The signature algorithm used to verify DelegatedCredential.signature. </ins> The signature over the credential with the end-entity certificate's public key, using the scheme.

Discussion:
Based on This adds a change log with changes from draft-01. It drops the proposed "must-use-DC" semantics from the X.509 extension. There doesn't seem to be a clean way to do this, and the complexity it adds seems to outweigh any potential benefit. The changes are as follows: Change DelegationUsage extension type to NULL. Drop support for TLS 1.2. Add the protocol version and credential signature algorithm to the Credential structure. () Specify undefined behavior in a few cases: when the client receives a DC without indicated support; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certificates other than the end-entity certificate.
Not sure why CI failed ... It's building fine on my end.
Back to you NAME :)
looks great to me
Change:
PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Enclose the regexp in "A" and "z". </del> <ins> Enclose the regexp in "A(?:" and ")z". </ins> 6.

Discussion:
Clarifications in conversion to platform regexps.
Looks plausible but I don't know these regexps well enough to approve.
Change:
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 <del> is, the complete length of TLSInnerPlaintext).  Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </del> <ins> is, the complete length of TLSInnerPlaintext).  In TLS 1.2 and earlier, the limit covers all input to compression and encryption, that is the data that ultimately produces TLSCiphertext.fragment. Padding added as part of encryption, such as that added by a block cipher, is not included in this count (see expansion). </ins> An endpoint that supports all record sizes can include any limit up to the protocol-defined limit for maximum record size.  For TLS 1.3

Discussion:
This isn't as easy as in TLS 1.3, which has a clearly defined structure for what is fed into the AEAD. I've done my best. NAME this is the only change from your email that you might disagree with. Can you have a look please?
Change:
with a timer; at this point, the application could reapply the pending remote description as a final answer. <del> 3.7.2. </del> <ins> 3.8.2. </ins> Parallel forking involves a call being dispatched to multiple remote callees, where each callee can accept the call, and multiple

Discussion:
Fixes URL
LGTM
Updated to incorporate feedback from comments. Some more detail needed in the last para, but the narrative should be complete.
PTAL
LGTM
In WebRTC section 5.1, addTransceiver(), it says 'When setRemoteDescription is called with a corresponding remote description that is able to receive multiple RTP encodings as defined in [JSEP], the RTCRtpSender may send multiple RTP encodings and the parameters retrieved via the transceiver’s sender.getParameters() will reflect the encodings negotiated.' It is not obvious what to use as the JSEP reference because there does not seem to be a single place that talks about receipt of multiple encodings.
The specification of signalling that you can recevie multiple encodings seems to belong in either the RID spec or the JSEP spec. A decision was made some time back that WebRTC entities are only required to support receiving one incoming stream, but all the specs need to be clear on what that means in practice.
I think it makes sense for us to add some text in JSEP for this and create a link
The plan is to add a new section in JSEP section 3 that would give an overview of simulcast, perhaps a summary of URL, section 6.2.
Change:
transfer.  During the process of establishment (conn-establish), the Connection will be unbound to a specific transport flow, since there may be multiple candidate Protocol Stacks being raced.  Once the <del> Connection is established, the object should be considered mapped to a specific Protocol Stack.  The notion of a Connection maps to many different protocols, depending on the Protocol Stack.  For example, the Connection may ultimately represent the interface into a TCP </del> <ins> Connection is established, its interface maps actions and events to the details of the chosen Protocol Stack.  For example, the same Connection object may ultimately represent the interface into a TCP </ins> connection, a TLS session over TCP, a UDP flow with fully-specified local and remote endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2 stream.

Discussion:
These are mostly wording changes for clarification. Feel free to cherry pick.
Can't find any problems here - this looks good.
This LGTM, many thanks!
Change:
A RUL is a special case of external target when the target is actually a host and it is known to support a consumed Routing Header and to ignore a HbH header as prescribed by RFC8200.  The target may <del> have been learned through as a host route or may have been registered to the 6LR using RFC8505. </del> <ins> have been learned through an external routing protocol or may have been registered to the 6LR using RFC8505. </ins> In order to enable IP-in-IP all the way to a 6LN, it is beneficial that the 6LN supports decapsulating IP-in-IP, but that is not assumed

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
2.3. EKT uses an authenticated cipher to encrypt and authenticate the <del> EKTPlaintext.  We first specify the interface to the cipher, in order to abstract the interface away from the details of that function.  We then define the cipher that is used in EKT by default.  The default cipher described in DefaultCipher MUST be implemented, but another cipher that conforms to this interface MAY be used, in which case its use MUST be coordinated by external means (e.g., key management). </del> <ins> EKTPlaintext.  This specification defines the interface to the cipher, in order to abstract the interface away from the details of that function.  This specification also defines the default cipher that is used in EKT.  The default cipher described in DefaultCipher MUST be implemented, but another cipher that conforms to this interface MAY be used. </ins> An EKTCipher consists of an encryption function and a decryption function.  The encryption function E(K, P) takes the following

Discussion:
Section 2.3 Ciphers EKT uses an authenticated cipher to encrypt and authenticate the EKTPlaintext. We first specify the interface to the cipher, in order to abstract the interface away from the details of that function. We then define the cipher that is used in EKT by default. The default cipher described in Section 2.3.1 MUST be implemented, but another cipher that conforms to this interface MAY be used, in which case its use MUST be coordinated by external means (e.g., key management).
Fixed by
Change:
introduces a length field with variable size. fig-frame shows the adjusted CoAP message format with a modified structure for the fixed header (first 4 bytes of the CoAP over UDP header), which <del> includes the length information of variable size, shown here as an 8-bit length. </del> <ins> includes the length information of variable size. </ins> 4-bit unsigned integer.  A value between 0 and 12 directly indicates the length of the message in bytes starting with the

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests.  Endpoints that register with a <del> con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links </del> <ins> con that contains a path component can not meaningfully use RFC6690 Link Format due to its prevalence of the Origin concept in relative reference resolution; they can submit payloads for interpretation as Modernized Link Format.  Typically, links </ins> submitted by such an endpoint are of the "path-noscheme" (starts with a a path not preceded by a slash, precisely defined in RFC3986 Section 3.3) form.

Discussion:
This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.
Change:
Unlike the AP, the RP need not have any particular relationship with the IdP.  Rather, it needs to be able to process whatever assertion <del> is provided by the AP.  As the assertion contains the IdP's identity, the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </del> <ins> is provided by the AP.  As the assertion contains the IdP's identity in the "idp" field of the JSON-encoded object (see sec.request- assert), the URI can be constructed directly from the assertion, and thus the RP can directly verify the technical validity of the assertion with no user interaction.  Authoritative assertions need only be verifiable.  Third-party assertions also MUST be verified against local policy, as described in sec.id-format. </ins> 7.6.

Discussion:
The description of how an assertion is constructed seemed to imply that the object with the fingerprints was what went in a=identity. You had to read much further down to learn that this wasn't right and that it was really the assertion. This just moves some of the critical text up, duplicating it really, so that this confusion is less likely.
Change:
DetNet Flow. <del> DetNet Inter-Working Function. </del> <ins> Frame Replication and Elimination for Redundancy (TSN function). </ins> Layer 2.

Discussion:
Major clean up and simplification as data plane drafts can be referred for MPLS related details. TSN over DetNet MPLS follows the concept of RFC3985. Description focus on Edge Nodes procedures and functions. Text covers the Edge Nodes components: (1) TSN functions (in NSP block); (2) DetNet Service Proxy; and (3) DetNet sub-layers.
Approving from teelcon review
Change:
An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. <del> [TODO: rtcp-fb?] </del> Lastly, if a data channel has been created, a m= section MUST be generated for data.  The <media> field MUST be set to "application" and the <proto> field MUST be set to "UDP/DTLS/SCTP" if the default

Discussion:
IDENTICAL-PT or SPECIAL which means that they should be in all the m= sections.
NAME can you look into this? Should be straightforward to resolve.
Change:
escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. <del> The syntax of Normalized Paths is restricted so that there is one and only one way of identifying a given node.  Putting this another way, two distinct Normalized Paths are never equivalent to each other: there will always be at least one JSON value that yields distinct results when those paths are applied to it. </del> Certain characters are escaped, in one and only one way; all other characters are unescaped.

Discussion:
The one to one correspondence sentence gives us most of the desired properties. The fact that for distinct Normalized Paths there will always be at least one JSON value which can distinguish the paths is interesting but not crucial. If it's confusing to some people, then it's probably a distraction.
yes ... this is a good minimalistic solution ... thanks
Change:
A literal header field with post-base name reference representation encodes a header field where the header field name matches the header field name of a dynamic table entry with an absolute index greater <del> than or equal to the Base. </del> <ins> than or equal to the value of the Base. </ins> This representation starts with the '0000' four-bit pattern.  The fifth bit is the 'N' bit as described in literal-name-reference.

Discussion:
This change has been suggested by afrind at URL on the basis that the Base is a count, and comparing an index to a count feels awkward.
Change:
successful UDP proxying responses also do not carry any message content. <del> Responses to UDP proxying requests are not cacheable. </del> 3.1. Upon receiving a UDP proxying request, the recipient UDP proxy

Discussion:
Try as we might, we can't retroactively place this requirement on the countless deployed caches on the Internet. Given that at least over HTTP/1.1 this mechanism uses GET, it might be better to specify that the GET response needs the appropriate caching metadata.
Good catch. That particular text came from back when we only used CONNECT, as that's defined as non-cacheable. Since defining how to cache Upgrade sounds like dragons holding footguns, I'm just going to remove this text via . That way we rely on existing HTTP documents to properly define how caching works.
Change:
throughout.  This string format includes optional Huffman encoding. HPACK defines string literals to begin on a byte boundary.  They <del> begin with a single flag (indicating whether the string is Huffman- coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from Appendix B of RFC7541 is used without modification. </del> <ins> begin with a single bit flag, denoted as 'H' in this document (indicating whether the string is Huffman-coded), followed by the Length encoded as a 7-bit prefix integer, and finally Length bytes of data.  When Huffman encoding is enabled, the Huffman table from Appendix B of RFC7541 is used without modification. </ins> This document expands the definition of string literals and permits them to begin other than on a byte boundary.  An "N-bit prefix string

Discussion:
Renamed S bit for static vs dynamic table to T bit (for Table) Replaced backticks with single quotes around individual bits (previously, about half used single, half used double) Added explicit references to bit letter indicators where they were missing (e.g., for 'H') Fixed broken reference to "blocked-decoding" section
As for 'B' vs , transport doc just uses (B). Maybe we should follow suit, bui I can do in a separate pass.
Change:
Select the origin information to include in the TokenChallenge. This can be empty to allow fully cross-origin tokens, a single origin name that matches the origin itself, or a list of origin <del> names containing the origin. </del> <ins> names containing the origin itself. </ins> The TokenChallenge message has the following structure:

Discussion:
Spec says: and and also The sender requirements are implicit. I'm guessing that the sender also MUST include it's own origin name in the non-empty case. Should the spec just state that?
Change:
can thus be inferred rather than made explicit.  If identity information is carried in the message, applications SHOULD have a way of validating the supplied identity information.  The <del> identity information does not need to be specified and can be left as absent. </del> <ins> identity information does not need to be specified and is set to nil in that case. </ins> This contains a nonce value.  The nonce can either be implicit from the protocol or carried as a value in the unprotected

Discussion:
We change the title of the document Implement the suggested change from Carsten that we put nils in to unused elements in the ParytInfo structure. I was a bit more complete than the original suggestion but it is probably simpler to get right that way.
It may be better to use the CBOR tag 24 rather than a bstr wrapper for the protected attributes field. The major question that needs to be addressed is how this is treated by existing parsers - will they try and decode it anyway or will the wait to decode them later. It is going to be required that they are both decode later and immutable to changes if they run through an intermediary which will decode, modify and re-encode any of the top level information. I don't believe that there is any benefits to using this rather than bstr for the payload field on signatures and macs since they could be any data type inside rather than a fixed one.
Did not correctly read the spec.
Change:
this specification. New entries to this table can be added via "Specification Required" <del> as defined in RFC8126.  When requesting a new value, the requestor needs to indicate if it is mandatory to understand or not.  If it is mandatory to understand, IANA needs to allocate a value less than 64, if it is not mandatory to understand, a value greater than or equal to 64 needs to be allocated.  IANA SHOULD prefer allocation of even values over odd ones until the even code points are consumed to avoid </del> <ins> as defined in RFC8126.  IANA SHOULD prefer allocation of even values over odd ones until the even code points are consumed to avoid </ins> conflicts with pre standard versions of EKT that have been deployed. <ins> Allocated values MUST be in the range of 0 to 254. </ins> All new EKT messages MUST be defined to have a length as second from <del> the last element. </del> <ins> the last element, as specified. </ins> 7.2.

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM