jiebi/CodeConvo huggingface dataset:
Change:
Nonsecure requests - such as those with the "http" scheme as opposed to the "https" scheme - SHOULD NOT be used if the Oblivious Gateway <del> and Target Resources are operated by different entities as that would expose both requests and response to modification or inspection by a network attacker. </del> <ins> and Target Resources are not on the same origin.  If messages are forwarded between these resources without the protections afforded by HTTPS, they could be inspected or modified by a network attacker. Note that two resources that share an origin do not guarantee that requests are not forwarded without protection. </ins> 6.4.

Discussion:
As NAME observes in his review, "same entity" is more or less meaningless when it comes to ensuring that forwarding doesn't happen in the clear. This narrows the recommendation to a concrete "same origin", but notes that even that is not sufficient in all cases.
Change:
opposed to how sockets represent network resources as file system objects that may be temporarily unavailable. <del> 1.3. </del> <ins> 2.2. </ins> Sockets provide a message interface for datagram protocols like UDP, but provide an unstructured stream abstraction for TCP.  While TCP

Discussion:
Based on discussion with NAME rearrange things to put a proper document overview in the intro, and split out the API Model discussion into its own section outside of the introduction.
LGTM (modulo one nit)Thank you NAME to do this - really improves the structure.
Change:
The document also updates the processing requirements on the Token. The updated processing ensures secure binding of responses to <del> requests. </del> <ins> requests, thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request. </ins> 1.1.

Discussion:
"AEAD keys" -> "traffic keys" In (D)TLS, the algorithms may be other types than AEAD. "thus mitigating error cases and attacks where the client may erroneously associate the wrong response to a request." Some more text about this in the intro, the current text was very barebone.
Change:
Replace the IP address of the ICE host candidate with the name with ".local" appended to it.  Expose the candidate. <del> 3.2. </del> <ins> 2.2. </ins> For any remote host ICE candidate received by the ICE agent, the following procedure is used:

Discussion:
Privacy text was moved to ip-handling, so no longer needed here. Update some surrounding sections accordingly.
LGTM. Let's merge this one, we will correct RFC6762 in the PR that is already doing that or as an editorial commit.
As discussed at IETF 101, ip-handling should define the problems, and this document should present the mDNS solution.
See URL
LGTM
Change:
Web bundles provide a way to bundle up groups of HTTP responses, with the request URLs and content negotiation that produced them, to transmit or store together.  They can include multiple top-level <del> resources with one identified as the default by a primaryUrl metadata, provide random access to their component exchanges, and </del> <ins> resources, provide random access to their component exchanges, and </ins> efficiently store 8-bit resources. 1.

Discussion:
Closes WICG/webpackage. This is transferred from NAME WICG/webpackage.
The WG hummed in favor of this direction at IETF 110: URL
Change:
%%% Supported Groups Extension Indicates support for the corresponding named curve, defined in <del> either FIPS 186-4 DSS or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </del> <ins> either NIST SP 800-186 ECDP or in RFC7748.  Values 0xFE00 through 0xFEFF are reserved for Private Use RFC8126. </ins> Indicates support for the corresponding finite field group, defined in RFC7919.  Values 0x01FC through 0x01FF are reserved for

Discussion:
FIPS 186-4 is obsolete Curve definitions have moved to the new NIST SP 800-186 ANSI X9.62 is behind a paywall and should be avoided if possible. References behind paywall can not be accessed by most readers. This makes it harder to implement and to evaluate the security of the protocol. FIPS 186-5 removed the dependency on ANSI X9.62 and defines ECDSA itself. Point validation is defined in the new NIST SP 800-186.
Change:
future connections.  The client includes this token in Initial packets to provide address validation in a future connection.  The client MUST include the token in all Initial packets it sends, unless <del> a Retry or NEW_TOKEN frame replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </del> <ins> a Retry replaces the token with a newer one.  The client MUST NOT use the token provided in a Retry for future connections.  Servers MAY discard any Initial packet that does not carry the expected token. </ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the

Discussion:
The client only replaces a token sent in Initial packets when receiving a Retry. NEW_TOKEN is an orthogonal mechanism to provide tickets for subsequent connections, and doesn't have any effect on the current connection.
Change:
new nonce, e.g., on its first request to the server or if an existing nonce is no longer valid. <del> To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce and SHOULD have status code 200 (OK).  The server MUST also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header) with a status code of 204 (No Content). </del> <ins> To get a fresh nonce, the client sends a HEAD request to the newNonce resource on the server.  The server's response MUST include a Replay- Nonce header field containing a fresh nonce and SHOULD have status code 200 (OK).  The server MUST also respond to GET requests for this resource, returning an empty body (while still providing a Replay- Nonce header) with a status code of 204 (No Content). </ins> <del> Proxy caching of responses from the new-nonce resource can cause </del> <ins> Proxy caching of responses from the newNonce resource can cause </ins> clients to receive the same nonce repeatedly, leading to "badNonce" errors.  The server MUST include a Cache-Control header field with <del> the "no-store" directive in responses for the new-nonce resource, in </del> <ins> the "no-store" directive in responses for the newNonce resource, in </ins> order to prevent caching of this resource. 7.3.

Discussion:
This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM
Change:
The label associated with the SNI encryption key. <del> A cryptographically random 128-bit nonce </del> The cipher suite used to encrypt the SNI. The original ServerNameList from the "server_name" extension,

Discussion:
You are mixing URL in. That would seem to be sufficient. From that you can generate the AEAD nonce and key as though this were record protection. We don't need another reason for people to complain about exposing the random number generator state to the network.
If servers choose to use the same ESNI and semi-static key, not generating and including a nonce could lead to nonce-reuse for 0-RTT data. We talked about just prohibiting this sort of key sharing for servers, though it's good to have a client-side defense against it.
Change:
Construct a table mapping MID to RtpReceiver for each RtpReceiver configured to receive from this transport. <del> Construct a table mapping SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive.  Some of the SSRCs may be presesnt in the m= section corresponding to that RtpReceiver in the remote description. </del> <ins> Construct a table mapping incoming SSRC to RtpReceiver for each RtpReceiver configured to receive from this transport and for each SSRC that RtpReceiver is configured to receive.  Some of the SSRCs may be present in the m= section corresponding to that RtpReceiver in the remote description. Construct a table mapping outgoing SSRC to RtpSender for each RtpSender configured to transmit from this transport and for each SSRC that RtpSender is configured to use when sending. </ins> Construct a table mapping payload type to RtpReceiver for each RtpReceiver configured to receive from this transport and for each

Discussion:
Fixes URL URL
LGTM
I made a bunch of edits to cover how the different types of RTCP packets should be handled, including compound RTCP packets. I also tweaked the RTP text slightly to be more consistent with the RTCP text. NAME NAME NAME PTAL.
NAME can you take a look?
LGTM
Fixed by
If the RTCP SDES has a MID value, update the SSRC mapping table for that SSRC to map to the receiver associated with that MID
This LGTM
Change:
Upon receipt of a GOAWAY frame, if the client has already sent requests with a Stream ID greater than or equal to the identifier <del> received in a GOAWAY frame, those requests will not be processed. Clients can safely retry unprocessed requests on a different connection.  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. </del> <ins> contained in the GOAWAY frame, those requests will not be processed.  Clients can safely retry unprocessed requests on a different connection.  A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. </ins> Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the server might have been processed; their status cannot be

Discussion:
Ambiguous description with for user agents in : It'd be better to remove or clarify rather than ambiguously allowing user agents with . A bit misleading expression with in This sentence looks to readers like that clients MAY send same requests on another connection even when the server keeps canceling or something regardless of clients' requests. There should be additional sentences no matter if it's the expected behavior or not. Some phrases in look verbose and confusingThe link in is wrong: should be replaced with .
These are separate issues, so let's look at them separately: This is deliberately vague, and the reason is explicitly stated. They don't affect the operation of the protocol, but user agents are allowed to make use of the associations in implementation-specific ways. This reflects HTTP/2, where some browsers use the association and some do not. Here again, I'm not seeing the problem. The requests have been canceled -- effectively "unsent" on this connection. If the client still needs to make those requests, they can't send them on this connection, but they MAY open a new connection. "received in a" -> "contained in the" would help here, unless you had a suggestion for making it tighter. The final issue is unrelated to these drafts, and is something the Tools server does. If you see an incorrect reference in the text draft or Editor's Copy HTML, please do point them out.
Change:
functions defined below: The Hash function and the HKDF hash are the cipher suite hash <del> algorithm.  Hash.length is its output length. </del> <ins> algorithm.  Hash.length is its output length.  Messages are the concatenation of the indicated handshake messages, including the handshake message type and length fields, but not including record layer headers. </ins> Given a set of n InputSecrets, the final "master secret" is computed by iteratively invoking HKDF-Extract with InputSecret_1,

Discussion:
When I was implementing the key schedule, it was unclear to me what stands for. This additional note would help other implementors. Kazuho Oku pointed out the similarity to Handshake Context. So, I updated that part, too.
Change:
this might be provided by the redemption protocol in AUTHSCHEME. Given this configuration and these inputs, the two messages exchanged <del> in this protocol are described below. </del> <ins> in this protocol are described below.  The constant "Nk" is defined by public-token-type. </ins> 6.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:
6.1. <del> To expedite loss detection, endpoints SHOULD send an acknowledgement immediately on receiving an ack-eliciting packet that is out of order.  Endpoints MAY continue sending acknowledgements immediately on each subsequently received packet, but they SHOULD return to using delay thresholds as specified above within a period of 1/8 x RTT, unless more ack-eliciting packets are received out of order. </del> <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, endpoints SHOULD send an acknowledgement immediately on receiving a reordered ack- eliciting packet, unless the peer has sent a "disable_ack_on_reordering" transport parameter, described below: </ins> <del> Similarly, packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header SHOULD be acknowledged immediately, to reduce the peer's response time to congestion events. </del> <ins> This optional transport parameter is sent by an endpoint that is reordering tolerant or expects reordering in the connection.  An endpoint that receives this transport parameter MUST NOT send an immediate acknowledgement when reordering is observed, and MUST continue delaying acknowledgements as per sending.  This parameter is a zero-length value. </ins> 6.2. <ins> As specified in Section 13.3.1 of QUIC-TRANSPORT, an endpoint SHOULD immediately acknowledge packets marked with the ECN Congestion Experienced (CE) codepoint in the IP header.  Doing so reduces the peer's response time to congestion events. 6.3. </ins> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements

Discussion:
merging.
Endpoints expect the connection to encounter reordering might want to indicate that the receiver should not send immediate acks on receiving a reordered packet.
Change:
resource depletion and related errors are comparable to 500 type errors.) <del> The JSON value the JSONPath query is applied to is, by definition, a valid JSON value.  The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this specification.  Sections RFC8259 and RFC8259 of RFC8259 identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, as they may cause unpredictable behavior.  The present specification does not attempt to define predictable behavior for JSONPath queries in these situations. Specifically, the "Semantics" subsections of Sections name-selector, wildcard, filter-selector, and descendant-segment describe behavior that becomes unpredictable when the JSON value for one of the objects under consideration was constructed out of JSON text that exhibits multiple members for a single object that share the same member name ("duplicate names", see RFC8259).  Also, selecting a child by name (name-selector) and comparing strings (comparisons in Section filter- selector) assume these strings are sequences of Unicode scalar values, becoming unpredictable if they aren't (RFC8259). </del> 3.2. Syntactically, a JSONPath query consists of a root identifier ("$"),

Discussion:
The text will be adjusted in a future PR.
This github bug is slowing me down a bit:
Huh! I'm not seeing that.
I'm only seeing it every second time I try to pull the repo state (issues, PRs) into emacs, which seems to use a graphql API. Annoying. This used to work well...
Thanks!
Change:
BRSKI defines how a pledge MAY contact a well-known URI of a cloud registrar if a local domain registrar cannot be discovered. <del> Additionally, certain pledge types may never attempt to discover a local domain registrar and may automatically bootstrap against a </del> <ins> Additionally, certain pledge types might never attempt to discover a local domain registrar and might automatically bootstrap against a </ins> cloud registrar. The details of the URI are manufacturer specific, with BRSKI giving

Discussion:
The two occurences of lower-case "may" might be clearer as "might". "The Pledge can be done with" ???? "may" or "MAY"? There are a few occurences of "should" and "must" in these sections, and I wondered about "SHOULD" and "MUST".
Change:
Confidentiality of exchanged attestation information may be desirable.  This requirement usually is present when communication takes place over insecure channels, such as the public Internet.  In <del> such cases, TLS may be uses as a suitable communication protocol that preserves confidentiality.  In private networks, such as carrier management networks, it must be evaluated whether or not the transport medium is considered confidential. </del> <ins> such cases, TLS may be used as a suitable communication protocol which provides confidentiality protection.  In private networks, such as carrier management networks, it must be evaluated whether or not the transport medium is considered confidential. </ins> 9.2. <del> In particular use cases mutual authentication may be desirable in </del> <ins> In particular use cases, mutual authentication may be desirable in </ins> such a way that a Verifier also needs to prove its identity to the Attester, instead of only the Attester proving its identity to the Verifier.

Discussion:
In all diagrams, valueGeneration should be replaced by produceClaims. The return type "claims" also indicates that claims are produced(/generated) somehow. Generated claims, e.g. could be Measured Boot data (TPM PCRs + the boot event log). BTW: I don't see a passage in the text that describes valueGeneration. See also .
Diagrams should be as close to UML as possible to improve understanding. That is (this applies to all diagrams): Actions should be verbs, not nouns ("generateValues" instead of "valueGeneration"). Returns of data should also be just arrows with data elements, i.e. nouns ("evidence --->" instead of "returnEvidence --->". Uni-Directional Remote Attestation: Handle Distributor should be at the top as an actor. It should be indicated that the "claimsDelta" value generation is a loop.
The text must be reworked. All above, the sequence in the diagram should be described entirely. This may also apply to the other models.
This should also be described in the text.
Change:
Versions of TLS before TLS 1.3 supported a session resumption feature which has been merged with Pre-Shared Keys in this version (see resumption-and-psk).  This field MUST be ignored by a server <del> negotiating TLS 1.3 and SHOULD be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </del> <ins> negotiating TLS 1.3 and MUST be set as a zero length vector (i.e., a single zero byte length field) by clients which do not have a cached session ID set by a pre-TLS 1.3 server. </ins> This is a list of the symmetric cipher options supported by the client, specifically the record protection algorithm (including

Discussion:
All other fields deprecated by this spec use "MUST be set to ...", such as ClientHello.legacyversion, ClientHello.legacycompressionmethods, TLSPlaintext.legacyrecordversion. Only ClientHello.legacysession_id "SHOULD be set as [...]" So I suggest changing this to "MUST" as well.
Change:
exception of the end-entity certificate which MUST be first. The server's certificate list MUST always be non-empty.  A client <del> will MAY send an empty certificate list if it does not have an </del> <ins> will send an empty certificate list if it does not have an </ins> appropriate certificate to send in response to the server's authentication request.

Discussion:
This should be "chose" not "choosed", which isn't really an accepted word.
Added another commit here for a minor wording fix that snuck in with changing all extensions to be referred to by type ID name.
Ok, I switched it to "chooses" instead & squashed my little fixes together here. There's also a fix for the "will MAY" bit that I think we discussed at some point but its fix didn't get in.
Change:
interpretation rules apply: extensions MAY appear in any order, but there MUST NOT be more than one extension of the same type in the extensions block.  An extension can be tagged as mandatory by using <del> an extension type codepoint with the high order bit set to 1.  A client that receives a mandatory extension they do not understand MUST reject the "ECHConfig" content. </del> <ins> an extension type codepoint with the high order bit set to 1. </ins> Clients MUST parse the extension list and check for unsupported mandatory extensions.  If an unsupported mandatory extension is

Discussion:
I can see how that sentence is redundant, but it seems like it would be helpful to implementers.
Change:
This value is placed in an "encrypted_server_name" extension. <del> The client MUST place the value of ESNIConfig.public_name in the "server_name" extension.  (This is required for technical conformance with RFC7540; Section 9.2.)  The client MUST NOT send a "cached_info" extension RFC7924 with a CachedObject entry whose </del> <ins> The client MUST place the value of ESNIConfigContents.public_name in the "server_name" extension.  (This is required for technical conformance with RFC7540; Section 9.2.)  The client MUST NOT send a "cached_info" extension RFC7924 with a CachedObject entry whose </ins> CachedInformationType is "cert", since this indication would divulge the true server name.

Discussion:
ESNIConfig has a version number in front for extensibility, but it is unclear what the version invariants are. Presumably we would like versions to change the contents of an ESNIConfig (indeed different drafts have done so), but it is not obvious this is possible and it is impossible to skip over an ESNIConfig with a version you do not understand. Fix this by moving the body of an ESNIConfig into an ESNIConfigContents and adding a length prefix in front.
As of draft-ietf-tls-esni-04, when the server rejects ESNI with esniretryrequest, it includes one or more ESNIKeys for retry: The client behavior described in section 5.1.2 is to pick one of the ESNIKeys values from this vector: Encoding of contains the total size of the vector field but not the size of the individual ESNIKeys elements. This makes it difficult (impossible?) to parse a vector with unknown future versions, so this part is not really extensible.
Thanks for the comment! URL should resolve this. It's a little goofy-looking but ah well.
Thank you for confirming the issue. Not the nicest but will be effective. It's the only real blocking point I see when implementing draft -04.