jiebi/CodeConvo huggingface dataset:
Change:
TLS Alert Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to <del> include values for "end_of_early_data", "missing_extension", and "certificate_required". </del> <ins> include values for "missing_extension" and "certificate_required". </ins> TLS HandshakeType Registry: Future values are allocated via Standards Action RFC5226.  IANA [SHALL update/has updated] this registry to rename item 4 from "NewSessionTicket" to "new_session_ticket" and to add the "hello_retry_request", <del> "encrypted_extensions", and "key_update" values. </del> <ins> "encrypted_extensions", "end_of_early_data", and "key_update" values. </ins> This document also uses a registry originally created in RFC4366. IANA has updated it to reference this document.  The registry and its

Discussion:
key changes happen at Handshake boundaries. Suggested by David Benjamin
I have one here, that could be a start: URL Also this is assuming PR URL is accepted ( becomes a message)
Merged.
Change:
if all Web browsers start using ESNI, the presence of this value does not signal suspicious behavior to passive eavesdroppers. <ins> Additionally, this specification allows for clients to send GREASE ESNI extensions (see grease-extensions), which helps ensure the ecosystem handles the values correctly. </ins> 7.2.5. This design is not forward secret because the server's ESNI key is

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
the RtpReceiver whose m= section appears earliest in the local description. <ins> As RtpTransceivers (and, thus, RtpReceivers) are added, removed, stopped, or reconfigured, the tables above must also be updated. </ins> For each RTP packet received, the following steps MUST be followed to route the packet:

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:
QUIC aims to constrain the capabilities of an on-path attacker as follows: <del> An on-path attacker can prevent use of a path for a connection, causing the connection to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </del> <ins> An on-path attacker can prevent the use of a path for a connection, causing the connection to fail if it cannot use a different path that does not contain the attacker.  This can be achieved by dropping all packets, modifying them so that they fail to decrypt, or other methods. </ins> An on-path attacker can prevent migration to a new path for which the attacker is also on-path by causing path validation to fail on

Discussion:
Do you need to rebase? There's a change that seems to have been repeated in a previously merged PR.
Change:
The following section specifies the behaviour fully, without depending on JavaScript or Python behaviour. <del> 3.5.2.4.2.2. </del> <ins> 3.5.6.2.2. </ins> An array selector is either an array slice or an array index, which is defined in terms of an array slice.

Discussion:
This is a full rebase of branch pr-98 () on current main.
Does this incorporate any changes from the discussions from , or is it a simple rebase?
It is a simple rebase, followed by a number of edits coming from the discussions here. Most of the remaining conversations need some further discussion, so I hope to cover them with my updated slides in a couple of hours.
Looks like a good next step on our path.
Change:
Content-Length, Content-Type, or Transfer-Encoding header fields. Additionally, HTTP status codes 204 (No Content), 205 (Reset Content), and 206 (Partial Content) MUST NOT be sent on responses <del> that use the Capsule Protocol. </del> <ins> that use the Capsule Protocol.  A receiver that observes a violation of these requirements MUST treat the HTTP message as malformed. </ins> <del> 4.2. </del> <ins> 3.3. </ins> <del> When an error occurs processing the capsule protocol, the receiver </del> <ins> When an error occurs in processing the Capsule Protocol, the receiver </ins> 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 H3.  For HTTP/2, the handling of malformed

Discussion:
NAME thank you for the suggestions over on URL David and I worked through your proposal from top to bottom and turned it into this PR, which accepts many suggestions but not all. Please review and let us know if you're happy with it. NAME we believe some of your comments are addressed here too (unless tracked on a separate ticket). Please take a look.
While the argument in Section 2 "requests are strictly serialised in the connection, therefore demultiplexing is not needed" is technically correct, Section 4. further restricts the use of HTTP/1.1 connections to a single stream of capsules/HTTP datagrams. I would prefer to see this restriction as an argument here.
The sentence "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." seems a little misleading … During the IETF 113 discussions, I understood capsules as general mechanism reliable datagrams/wire encoding over HTTP In the draft however, Section 1 state "Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP." contradicts this impression. Can we clarify this?
Why is the ebnf instead of ? Should this allow request/upgrade methods to append a list of additional parameters?
Yes, allows parameters but does not. We didn't see a good reason to ban future parameters
Maybe you should mention it and require intermediaries to pass and ignore them in case they don't understand them.
as per recent changes in HTTPland specs, the ABNF adds confusion. My suggestion is to remove the ABNF. That might still leave a question over the structured types, but that is answered by the Structured Field value specs and we are unlikely to need to state anything ourselves. I can take a pass at this.
LGTM, thanks!
Change:
10. <ins> Content Encryption Algorithms provide data confidentialty for potentially large blocks of data using a symmetric key.  They provide either no or very limited data origination.  (One cannot, for example, be used to prove the identity of the sender to a third party.)  The ability to provide data origination is linked to how the symmetric key is obtained. We restrict the set of legal content encryption algorithms to those which support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition.  For simplicity sake, the authentication code will normally be defined as being appended to the cipher text stream.  The basic structure becomes: Most AEAD algorithms are logically defined as returning the message content only if the decryption is valid.  Many but not all implementations will follow this convention.  The message content MUST NOT be used if the decryption does not validate. </ins> 10.1. The GCM mode is is a generic authenticated encryption block cipher

Discussion:
Add more intro text to algorithms Put in a note about the fact that a zero length map is not the preferred encoding for the protected field, but is a legal one.
Change:
WireGuard <ins> OpenVPN </ins> Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites.

Discussion:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1
Change:
"info". 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.  This section uses notation described in OPRF, Section 4, including SerializeElement and DeserializeElement, SerializeScalar and DeserializeScalar, and DeriveKeyPair. </ins> 3.1. <del> The Client first creates a verifiable context as follows: </del> <ins> The Client first creates a context as follows: </ins> Here, 0x0004 is the two-octet identifier corresponding to the OPRF(P-384, SHA-384) ciphersuite in OPRF.

Discussion:
draft-irtf-cfrg-voprf-09 went out today, and this just aligns the basic issuance protocol on top of those changes. cc NAME
Change:
The sender of a Remove message generates it as as follows: <ins> Blank the path from the removed leaf to the root node for the time of the computation Truncate the tree such that the rightmost non-blank leaf is the last node of the tree, for the time of the computation </ins> Generate a fresh leaf key pair Compute its direct path in the current ratchet tree, starting from <del> the removed leaf </del> <ins> the sender's leaf </ins> A member receiving a Remove message first verifies the signature on the message.  The member then updates its state as follows: <del> Update the ratchet tree by replacing nodes in the direct path from the removed leaf using the information in the Remove message </del> Update the ratchet tree by setting to blank all nodes in the direct path of the removed leaf, and also setting the root node to blank

Discussion:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </del> <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire, and therefore multiple probes to be sent in the event of loss, prior to idle timeout. </ins> 10.1.1.

Discussion:
I think this was the intent of the sentence, but I kept not being able to parse it so.
Change:
for different connection IDs, the endpoint MAY treat that receipt as a connection error of type PROTOCOL_VIOLATION. <del> The Retire Prior To field is a request for the peer to retire all connection IDs with a sequence number less than the specified value. This includes the initial and preferred_address transport parameter connection IDs.  The peer SHOULD retire the corresponding connection IDs and send the corresponding RETIRE_CONNECTION_ID frames in a timely manner. The Retire Prior To field MUST be less than or equal to the Sequence Number field.  Receiving a value greater than the Sequence Number MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> The Retire Prior To field counts connection IDs established during connection setup and the preferred_address transport parameter (see retiring-cids).  The Retire Prior To field MUST be less than or equal to the Sequence Number field.  Receiving a value greater than the Sequence Number MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> Once a sender indicates a Retire Prior To value, smaller values sent in subsequent NEW_CONNECTION_ID frames have no effect.  A receiver

Discussion:
Consolidate Retire Prior To instructions in the section that discusses retiring CIDs and clean up the frame description. Left the operational requirements about the frame and its values with the frame, but all of the mechanism for requesting retirement of CIDs is now in one section.
In the section talking about Connection IDs (section 5.1.2) it says: In the description of the NEWCONNECTIONID frame (section 19.15) it says: So it's not clear if you just SHOULD or if you MUST send the RETIRECONNECTIONID frame. As an editorial remark, I find the existing text a bit hard to understand, since it's spread over these two sections. Maybe it would be easier to keep the frame description relatively short, and move more of the logic into the section that describes how CIDs are used and retired.
I think what we concluded in previous discussion was that you MUST retire them, and SHOULD do so in a timely manner. The suggested reorganization isn't a bad suggestion either.
Based on this feedback, this can probably be handled as an editorial matter. I would be happy to receive a PR that reconciled this with .
Definitely agree that this is editorial, we just missed this duplicate requirement in the original change. Removed that duplication and cleaned up the frame description a bit.
Change:
Recommended: Same as in <ins> External: Whether a proposal of this type may be sent by an "external" sender (see external-proposals). </ins> Path Required: Whether a Commit covering a proposal of this type is required to have its "path" field populated (see commit).

Discussion:
NAME and I have completed interop testing that covers all of the functionality in the spec. We found a couple of places where there were ambiguities in the spec that led to different implementation decisions, and in the process of resolving those, found a couple of errors / omissions in drarft-19. The current PSK proposal validation forbids with other than . The branch and reinit sections call for the creation of PSK proposals with types and . Given the text in the PSK section, these proposals would be invalid. This PR explicitly allows and in the specific context of those operations. (This is a little pro-forma, since the PSK proposals are only seen by the committer. But it seems good to allow the committer to have consistent PSK proposal validation logic.) The text says that Add, Remove, and ReInit proposals can be sent by external senders, but is silent about other proposal types. This PR explicitly indicates which proposal types may be originated by external senders, and adds an IANA registry column to track. GREASE values for proposal types, credential types, and extension types are defined for use in Capabilities, but nothing currently forbids their use elsewhere. This PR forbids their use in actual Proposal or Credential objects, and in GroupContext extensions. The field of the Proposal object was inconsistently referred to as both and . This PR changes it to be everywhere.
Merge when ready.
Change:
WT_MAX_STREAMS frames contain the following field: <del> Maximum Streams: A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection.  This value cannot exceed 2^60, as it is not possible to encode stream IDs larger than 2^(62-1). </del> <ins> A count of the cumulative number of streams of the corresponding type that can be opened over the lifetime of the connection.  This value cannot exceed 2 , as it is not possible to encode stream IDs larger than 2 -1. </ins> An endpoint MUST NOT open more streams than permitted by the current stream limit set by its peer.  For instance, a server that receives a

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
HelloRetryRequest processing apply. Clients bind encryption of the second ClientHelloInner to encryption <del> of the first ClientHelloInner via the derived ech_hrr_key by modifying HPKE setup as follows: </del> <ins> of the first ClientHelloInner via the derived ech_hrr_key by running a modified encryption process: </ins> The "info" parameter to SetupPSKS is the concatenation of "tls ech", <del> a zero byte, and the serialized ECHConfig.  Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr-hijack. Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon receipt of a second ClientHello message with a ClientECH value, servers set up their HPKE context and decrypt ClientECH as follows: ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  The "info" parameter to SetupPSKR is computed as above. </del> <ins> a zero byte, and the serialized ECHConfig.  ClientHelloOuterAAD is computed from the second ClientHelloOuter as described in authenticating-outer.  Note the encrypted value is also authenticated by ech_hrr_key.  The rationale for this is described in flow-hrr- hijack. </ins> If the client offered ECH in the first ClientHello, then it MUST offer ECH in the second.  Likewise, if the client did not offer ECH

Discussion:
Now that we have separate client HRR and server HRR sections, move some server text to the server section. Also clarify that the second ClientHelloOuterAAD is computed from the second ClientHelloOuter, not reusing the first value. (Some cleanup in advance of writing up the HPKE context reuse version.)
Can we merge this? The number of PRs is getting confusing. NAME
Change:
group's rachet tree and the credentials for the members of the group, as described in tree-hashes. <del> The "transcript_hash" field contains the list of "GroupOperation" messages that led to this state. </del> <ins> The "confirmed_transcript_hash" field contains a running hash over the handshake messages that led to this state. </ins> When a new member is added to the group, an existing member of the group provides the new member with a Welcome message.  The Welcome

Discussion:
While trying to implement , I noticed that the confirmation and transcript hash calculations in draft-06 do not actually allow a new participant to join the transcript hash. Since the value is sent, and not the value, the new joiner is missing the auth data necessary to compute the next value. To fix this and clarify terminology, this PR makes the following changes: becomes , since this is what goes into the confirmation MAC becomes is updated to refer to the
Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 1 issues have been closed and 1 issues are still open. :greenheart: , by :heart: , by :speaker: , by It received 1 comments. - - Last week, 2 pull requests were created, updated or merged. Last week, 1 pull request was updated. :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
This looks ok. If we want, merging and messages like in the TreeKEM paper would probably avoid some pain here. Merging.
Change:
unwilling to issue a certificate corresponding to the submitted CSR. For example: <del> If the order indicated does not have status "ready" </del> If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in

Discussion:
draft-ietf-acme-acme-18 §7.4 has two conflicting statements regarding what an ACME server should do when it receives a request to finalize an order that is not in the "ready" state: 'If the order indicated does not have status "ready" ... the problem document returned by the server SHOULD use error code "badCSR"'. 'A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take:', where values other than "ready" are listed. This PR proposes to resolve this conflict by requiring servers to return a new 'badState' error in response to a request to finalize an order that is not in the "ready" state. The client should respond to a "badState" error by re-fetching the order object and examining the status field to determine what to do.
I think a better name for this very specific error would be badOrderState or orderNotReady. That avoids potential confusion with bad states for authzs or challenges. Posted a proposed change in URL
Thanks NAME - this clarification makes sense to me. I'm +1 to applying your diff with the other AUTH48 changes. cc NAME Not really just editorial, but okay.
Change:
for more details.)  This service must be provided for both data and voice/video.  Ideally the same security mechanisms would be used for both types of content.  Technology for providing this service (for <del> instance, SRTP RFC3711, DTLS RFC4347 and DTLS-SRTP RFC5763) is well </del> <ins> instance, SRTP RFC3711, DTLS RFC6347 and DTLS-SRTP RFC5763) is well </ins> understood.  However, we must examine this technology to the WebRTC context, where the threat model is somewhat different.

Discussion:
I-D nits complained about a couple of outdated and unused references. This fixes them. Note that a few still remain.