jiebi/CodeConvo huggingface dataset:
Change:
may be updated throughout the connection as described in updating- traffic-keys. <del> Note: although the steps above are phrased as individual HKDF-Extract </del> <ins> Note: Although the steps above are phrased as individual HKDF-Extract </ins> and HKDF-Expand operations, because each HKDF-Expand operation is paired with an HKDF-Extract, it is possible to implement this key schedule with a black-box HKDF API, albeit at some loss of efficiency

Discussion:
One more minor fix I just noticed when diffing the latest draft. Just capitalization fixes to match the other notes.
Change:
transfers.  The absence of options in the CSM indicates that base values are assumed. <ins> To avoid unnecessary latency, a client MAY send additional messages without waiting to receive the server CSM; however, it is important to note that the server CSM might advertise capabilities that impact how a client is expected to communicate with the server.  For example, the server CSM could advertise a Max-Message-Size option (See max-message-size) that is smaller than the base value (1152). </ins> Clients and servers MUST treat a missing or invalid CSM as a connection error and abort the connection (see sec-abort).

Discussion:
Also clarifies that "same kind" in Alternate-Address refers to scheme.
When I submitted the original pull request, I also posed a question on the but did not receive a response. One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM. This would be similar to HTTP/2: URL To avoid unnecessary latency, clients are permitted to send additional messages to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server. Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.
I support not blocking the device until the server CSM. The server can choose to not process messages that are invalid (e.g. too large) and immediately follow up with the server CSM. From the perspective of a cloud and gateway software provider, the CoAP (using TCP/TLS) server will usually be in the cloud or gateway and therefore usually not power constrained. I may be missing other scenarios where a battery powered device is acting as a CoAP/TCP server. Does anyone have plans for any of those scenarios?
NAME added a related comment to (which is closed) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either. To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well. If that is the case, the client will have to re-send the data, I guess. For the currently defined options I don't see problems.
Change:
failure response to the application server monitoring the receipt subscription resource. <del> 6.2. </del> <ins> 6.3. </ins> The application server requests the delivery of receipts from the push service by making a HTTP GET request to the receipt subscription

Discussion:
These are the initial and incomplete changes related to the subscription set feature. One remaining gap is how a push service correlates two different subscriptions. See the for the related thread.
Overall I like how this looks. The PENDING section on how a server might know to attach new subscription requests to an existing subscription set could be resolved by requiring a client upon connecting to immediately request delivery of a notification set before asking for new subscriptions. This way the connection handler can associate the subscription set with the connection, and a server may then associate new subscriptions with the outstanding subscription set request. This could also provide a client with a way to manage 'groups' of subscription sets, since it could assume that the last subscription set it asked for is what new subscriptions on that connection will be attached to. This could be useful for the IoT use-cases where a client might want to have some input on which subscriptions are grouped together.
I was thinking even simpler for correlation: include link relation to a subscription set in the request. That allows clients to share a connection without risking the server creating a set that they can't use. For instance, applications using URL on windows could use the same HTTP/2 connection to a server (though I don't think that they do, the protocol permits, even encourages it). However, they might independently want to use push. Sharing a subscription set is not entirely practical in this case. Good point. In earlier discussions, one proposal was to pass the first subscription resource that was created (as parent) with subsequent subscription requests (children) to provide that common link between the user agent and push service. This allowed the user agent to make the decision to aggregate or not. If it did not pass a parent subscription, then the push service could not aggregate the separate subscriptions. My thought was to avoid 'special' properties on the first subscription. The subscription set ensures a clean separation between operations on aggregated and individual subscriptions. For example, the user agent can continue to GET (or poll) and DELETE individual subscriptions - including the first one. To enable the current proposal where the push service makes the decision to aggregate, there must be some form of client authentication/identification included with the subscription request in order for a push service to correlate the subscriptions.

Darshak noted this in a previous message: I’m not sure how a PS can force a UA to aggregate (unless the PS somehow identifies the client based on authentication/cookie/something-else). I may be taking it out of context as "something-else", but Benjamin also commented: I'm associating one h2 connection as being one UA
Change:
Thus the "confirmed_transcript_hash" field in a GroupContext object represents a transcript over the whole history of MLSPlaintext Commit <del> messages, up to the confirmation field in the current MLSPlaintext message.  The confirmation and signature fields are then included in the transcript for the next epoch.  The interim transcript hash is passed to new members in the GroupInfo struct, and enables existing members to incorporate a Commit message into the transcript without having to store the whole MLSPlaintextCommitAuthData structure. </del> <ins> messages, up to the confirmation tag field in the current MLSPlaintext message.  The confirmation tag and signature fields are then included in the transcript for the next epoch.  The interim transcript hash is passed to new members in the GroupInfo struct, and enables existing members to incorporate a Commit message into the transcript without having to store the whole MLSPlaintextCommitAuthData structure. </ins> As shown above, when a new group is created, the "interim_transcript_hash" field is set to the zero-length octet

Discussion:
This PR gets rid of the explicit HMAC reference and uses KDF.Extract instead (which internally uses HMAC). Also is renamed to .
I don't love the extra , but I can live with it.
Change:
httpfronting. This document does not present the design of a solution, but provides <del> guidelines for evaluating proposed solutions.  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </del> <ins> guidelines for evaluating proposed solutions.  (The review of HTTP- level solutionsin httpfronting is not an endorsement of these solutions.)  The need for related work on the encryption of the Application Layer Protocol Negotiation (ALPN) parameters of TLS is discussed in hiding-alpn. </ins> 2.

Discussion:
Trying to address the last comments (issue ).
NAME I hope this reflects our discussion.
Checking in after Roman's comments on the list.
Change:
functional in both directions.  The initiator MUST NOT enforce this behaviour. <del> The initiator MUST silently discard any invalid "path_response" it receives. </del> <ins> The initiator MUST silently discard any invalid "path_response" or "path_drop" it receives. </ins> Note that RRC does not cater for PMTU discovery on the reverse path. If the responder wants to do PMTU discovery using RRC, it should

Discussion:
Signed-off-by: Thomas Fossati
We say: "The initiator MUST silently discard any invalid pathresponse it receives." we should say instead: "The initiator MUST silently discard any invalid pathresponse or pathdrop it receives."_
Change:
confirmation key and the "confirmed_transcript_hash" from the GroupInfo. <ins> Use the confirmed transcript hash and confirmation tag to compute the interim transcript hash in the new state. </ins> 11.3. By default, a GroupInfo message only provides the joiner with a

Discussion:
As discussed on 2020-10-20, this field is not needed now that moved the signature under the confirmation tag.
We have a long-standing OPEN ISSUE on creating a group with a single Init message instead of N Add messages, which would change the work of initialization from O(N log N) to O(N). I would propose roughly the following: Then the processing would be: Find the welcome that's for you Initialize a one-member tree from the Welcome Use the UserInitKeys to populate the leaves of the tree Use the DirectPath to populate the creator's direct path (as in Update)
Fixed by URL
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.
Change:
used.  This produces a set of candidate PSKs, each of which are bound to a specific target protocol and KDF.  This expands what would normally have been a single PSK identity into a set of PSK <del> identities.  However, importantly, it requires no change to the TLS 1.3 key schedule. </del> <ins> identities. </ins> 2.

Discussion:
Addresses . cc NAME
The document says: Aside from this statement needing update in light of the changes to the binder label, the core statement here isn't expanded upon. The document needs to very clearly say that the PSK ID that is sent in the psk extension is literally the serialized content of .
Fixed in .
Change:
promotes those 4 cipher suites to standards track (see TO-DO insert reference). <ins> RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is inconsistent with respect to the ordering of components within PSK

Discussion:
Adding instructions for the RFC editor to delete the sentence that notes the algorithms defined in RFC 5289 as these algorithms will be standards track at or before the time this draft gets to the RFC editor.
Change:
An endpoint can cause its peer to retire connection IDs by sending a NEW_CONNECTION_ID frame with an increased Retire Prior To field. Upon receipt, the peer MUST retire the corresponding connection IDs <del> and send corresponding RETIRE_CONNECTION_ID frames.  Failing to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. </del> <ins> using RETIRE_CONNECTION_ID frames.  Failure to retire the connection IDs within approximately one PTO can cause packets to be delayed, lost, or cause the original endpoint to send a stateless reset in response to a connection ID it can no longer route correctly. </ins> An endpoint MAY discard a connection ID for which retirement has been requested once an interval of no less than 3 PTO has elapsed since an

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:
Truncate the tree such that the rightmost non-blank leaf is the last node of the tree <del> Note that, in step 4, there must be at least one non-null element in the tree, since any valid GroupContext must have the current member in the tree and self-removal is prohibited.  The same reasoning justifies the existence of a non-blank leaf in the ratchet tree in step 5. </del> <ins> Update the ratchet tree by replacing nodes in the direct path from the sender's leaf using the information in the Remove message Note that there must be at least one non-null element in the tree, since any valid GroupContext must have the current member in the tree and self-removal is prohibited </ins> The "update_secret" resulting from this change is the "path_secret[i+1]" derived from the "path_secret[i]" associated to

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:
8.4. <del> On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame. </del> <ins> On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </ins> An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-

Discussion:
This is the maximal version of a clarification of this text.
WFM, and resolves the original NiT.
(Broken out of .) Of course it may not be able to immediately send anything:-) , but I suspect this needs to not delay?
These frames aren't subject to flow control, so the only reason it would be unable to send something is congestion control. The frame that it echos back needs to be enqueued for sending; if it takes some time to actually hit the network, that's fine.
NAME
Seems resolved by the PR
For the benefit of others reviewing this: This seems to refer to .
This LG, but so did the old text.
Change:
7. <del> The data payload is the DNS on-the-wire format defined in RFC1035. The format is for DNS over UDP.  Note that this is different than the wire format used in RFC7858.  Also note that while RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This protocol allows DNS on-the-wire format payloads of any size. When using the GET method, the data payload MUST be encoded with base64url RFC4648 and then provided as a variable named "dns" to the URI Template expansion.  Padding characters for base64url MUST NOT be included. When using the POST method, the data payload MUST NOT be encoded and is used directly as the HTTP message body. DNS API clients using the DNS wire format MAY have one or more EDNS options RFC6891 in the request. The media type is "application/dns-message". </del> <ins> The data payload for the application/dns-message media type is a single message of the DNS on-the-wire format defined in section 4.2.1 of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used in RFC7858 (which uses the format defined in section 4.2.2 of RFC1035). DNS API clients using this media type MAY have one or more EDNS options RFC6891 in the request.  DNS API servers using this media type MUST ignore the value given for the EDNS UDP payload size in DNS requests. When using the GET method, the data payload for this media type MUST be encoded with base64url RFC4648 and then provided as a variable named "dns" to the URI Template expansion.  Padding characters for base64url MUST NOT be included. When using the POST method, the data payload for this media type MUST NOT be encoded and is used directly as the HTTP message body. </ins> 8.

Discussion:
paul has given this thumbs up out of band
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "special meta QTYPEs"
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "EDNS UDP Payload size cache issue"
This issue is here just so we don't lose it; the discussion is happening on the mailing list under the subject line that contains "TC and message size".
Change:
Any packet containing only one or more ACK frame(s). <del> Packets are considered in-flight when they have been sent and neither acknowledged nor declared lost, and they are not ACK-only. </del> <ins> Packets are considered in-flight when they have been sent and are not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys. </ins> All frames besides ACK or PADDING are considered ack-eliciting.

Discussion:
From a full read en route to Prague.
Thanks Jana, suggestions taken and "Clearer Loss Epoch" rewritten.
Change:
model describes how the API model of Transport Services differs from traditional socket-based APIs.  Specifically, it offers asynchronous event-driven interaction, the use of messages for <del> data transfer, and the ability to easily adopt different transport protocols. </del> <ins> data transfer, and the flexibility to use different transport protocols and paths without requiring major changes to the application. </ins> design explains the design principles behind the Transport Services API.  These principles are intended to make sure that

Discussion:
Proposed some text for - I think this summarizes the "flexibility" advantage of TAPS that we elaborate on in Section 2.3.
In Section 1.2, Overview, the architecture draft says that TAPS offers "the ability to easily adopt different transport protocols". What does "adopt" mean here? I guess this relates to Section 2.3 (maybe say that explicitly here), but even after reading this Section, I don't quite understand why "adopt". Is the point here that a flexible interface makes it easier to add support for new protocols? Then perhaps we should say this here.
It means that applications don't need to rewrite a ton of code or adopt a new library to access a new transport protocol. In how I read it, "adopt" captures that, but if there's some other text you would like to suggest, that's fine.
For me "adopt" is fine as it should be clear from the rest of the doc. However, if we want to be more clear we could say "make use of different protocols without the need to change the interface" or something...?
Looks good, merged!
Change:
Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and <del> proceed with the connection using ClientHelloOuter.  This connection proceeds as usual, except the server MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys.  Servers MAY supply multiple ECHConfig values of different versions.  This allows a server to support multiple versions at once. </del> <ins> proceed with the connection using ClientHelloOuter, with the following modifications: If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see dont-stick-out for details. If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys.  Servers MAY supply multiple ECHConfig values of different versions.  This allows a server to support multiple versions at once. </ins> Note that decryption failure could indicate a GREASE ECH extension (see grease-ech), so it is necessary for servers to proceed with the

Discussion:
This assumes the formulation where, on ECH reject, the server is the client-facing server. In other words, backend servers will never get a CH without ECH having been accepted, so GREASE doesn't apply there. cc NAME
cc NAME too, since he had thoughts on this