jiebi/CodeConvo huggingface dataset:
Change:
A model system is shown in [TODO: Figure]. <del> The messaging service presents as two abstract services: </del> <ins> The Messaging Service (MS) presents as two abstract services: </ins> <del> An Authentication Server (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </del> <ins> An Authentication Service (AS) which is responsible for maintaining user identities, issuing credentials which allow them to authenticate to each other, and potentially distributing user </ins> keying material. <del> A Message Switch (MS) which is responsible for delivering messages between users.  In the case of group messaging, the message switch may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </del> <ins> A Delivery Service (DS) which is responsible for delivering messages between users.  In the case of group messaging, the delivery service may also be responsible for acting as an "exploder" where the sender sends a single message to a group and the switch then forwards it to each recipient. </ins> <del> In many systems, the AS and the MS are actually operated by the same </del> <ins> In many systems, the AS and the DS are actually operated by the same </ins> entity and may even be the same server.  However, they are logically distinct and, in other systems, may be operated by different entities so we show them as separate here.  Other partitions are also

Discussion:
The current naming is confusing: MS stands for "Message Switch" and "Messaging Server" but not for "Messaging Service" AS stands for "Authentication Server" and "Authentication Service". The proposed change gives: MS as "Messaging Service" (AS* + DS) AS as "Authentication Service" DS as "Delivery Service" the "Server"s being the endpoints and not the functionality
Change:
A list of extensions.  The ServerHello MUST only include extensions which are required to establish the cryptographic <del> context.  Currently the only such extensions are "key_share" and "pre_shared_key".  All current TLS 1.3 ServerHello messages will contain one of these two extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </del> <ins> context and negotiate the protocol version.  All TLS 1.3 ServerHello messages MUST contain the "supported_versions" extension.  Current ServerHello messages contain either the "pre_shared_key" or "key_share" extensions, or both when using a PSK with (EC)DHE key establishment.  The remaining extensions are sent separately in the EncryptedExtensions message. </ins> For backward compatibility reasons with middleboxes (see middlebox) the HelloRetryRequest message uses the same structure as the

Discussion:
Issue 1: supportedversions is required in TLS 1.3 SH. Issue 2: supportedversions.selected_version must be identical in HRR and SH
NAME please submit a PR to add yourself to acknowledgements
Thanks for the fixup.
Change:
The ICE-CONTROLLED attribute is present in a Binding request and indicates that the client believes it is currently in the controlled role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del> <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> The ICE-CONTROLLING attribute is present in a Binding request and indicates that the client believes it is currently in the controlling role.  The content of the attribute is a 64-bit unsigned integer in <del> network byte order, which contains a random number used for tie- breaking of role conflicts. </del> <ins> network byte order, which contains a random number.  The number is used for solving role conflicts, when it is referred to as the tie- breaker value.  An ICE agent MUST use the same number for all Binding requests, for all streams, within an ICE session.  The ICE agent MAY change the number when an ICE restart occurs. </ins> 16.2. This specification defines a single error response code: The Binding request contained either the ICE-CONTROLLING or ICE- <del> CONTROLLED attribute, indicating a role that conflicted with the server.  The server ran a tie-breaker based on the tie-breaker value in the request and determined that the client needs to </del> <ins> CONTROLLED attribute, indicating an ICE role that conflicted with the server.  The server compared the tie-breaker values of the client and the server and determined that the client needs to </ins> switch roles. 17.

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero- <del> length connection IDs - the local address and port.  If the packet doesn't match an existing connection, the server continues below. </del> <ins> length connection IDs - the local address and port.  These packets are processed using the selected connection, otherwise the server continues below. </ins> If the packet is an Initial packet fully conforming with the specification, the server proceeds with the handshake (handshake).

Discussion:
Not saying explicitly that was a small oversight.
S 5.2.2 says: Packets with a supported version, or no version field, are matched to a connection using the connection ID or - for packets with zero-length connection IDs - the local address and port. If the packet doesn't match an existing connection, the server continues below. So, this tells us what to do if we don't match, but not if we do match. I know this is a nit, but I think there should be some kind of pointer after the first sentence.
LGTM
Change:
Servers use quota mechanisms to avoid systems overload, to ensure an equitable distribution of computational resources or to enforce other <del> policies - eg. monetization. </del> <ins> policies - e.g. monetization. </ins> A basic quota mechanism limits the number of acceptable requests in a <del> given time window, eg. 10 requests per second. </del> <ins> given time window, e.g. 10 requests per second. </ins> When quota is exceeded, servers usually do not serve the request <del> replying instead with a "4xx" HTTP status code (eg. 429 or 403) or </del> <ins> replying instead with a "4xx" HTTP status code (e.g. 429 or 403) or </ins> adopt more aggressive policies like dropping connections. <del> Quotas may be enforced on different basis (eg. per user, per IP, per </del> <ins> Quotas may be enforced on different basis (e.g. per user, per IP, per </ins> geographic area, ..) and at different levels.  For example, an user may be allowed to issue:

Discussion:
Fix typos
I'm really sorry for the poor Camilleri :) Wu Ming's "Q" is really worth reading though URL(novel)
What, no Eco? :)
No warnings
There are six lines that are marked as too long.: It might make sense to break these into two lines: and add text saying "Shown on two lines for clarity" or something.
3 fixed ;)
NAME Can this be closed now?
Looks good - thanks for the literary recommendations; I already followed inspector Montalbano's deeds, but Q looks an interesting addition... if/whenever my son gives me some time to read! :smile:
Change:
accordance with the requirements of RFC5246 when negotiating that version.  In particular: <del> TLS 1.2 ClientHellos may omit this extension. </del> <ins> TLS 1.2 ClientHellos MAY omit this extension. </ins> In TLS 1.2, the extension contained hash/signature pairs.  The pairs are encoded in two octets, so SignatureScheme values have

Discussion:
The document was pretty crisp about the version downgrade protections, but was less good about the changes to signature schemes. I have made a few changes to the description of signature_algorithms that should improve that. In particular, I have made it clear that the RSASSA-PSS codepoints are also defined for TLS 1.2 and that they can be used there. That means that TLS implementations need to be prepared to accept PSS signatures. This also adds a section that points to the pieces that 1.2 implementations need to consider.
(Well, I think, strictly speaking, we need only lock down HashAlgorithm.) The SignatureScheme change assumes that we will never again allocate new values in the TLS 1.2 HashAlgorithm and SignatureAlgorithm ranges. I'm not sure how to write that kind of IANA consideration or I'd put together a PR. The end result should probably be something like s/Unassigned/Reserved for TLS 1.3 compatibility/. From TLS 1.3 onwards, all new signature algorithms that apply to TLS 1.2 must go through a backported SignatureScheme. (If we're not happy with that strong of a restriction, we could perhaps only burn HashAlgorithms 0x80 and up. Then TLS 1.3 SignatureSchemes live in the 0x8000 to 0xfdff range. Though 's PSS text already implies we'll be backporting SignatureSchemes, so the division probably isn't necessary? I dunno. I don't really care either way.)
Let's just lock down HAshAlgorithm. Can you submit a PR?
Change:
Heterogeneous Storage Architecture (HeSA): A device that stores at least one firmware component differently from the rest, for <del> example a device with an external, updatable radio, or a device </del> <ins> example a device with an external, updateable radio, or a device </ins> with internal and external flash memory. Trusted Execution Environments (TEEs): An execution environment <del> that runs alongside of, but is isolated from, an REE. </del> <ins> that runs alongside of, but is isolated from, an REE.  For more information about TEEs see I-D.ietf-teep-architecture. </ins> Rich Execution Environment (REE): An environment that is provided and governed by a typical OS (e.g., Linux, Windows, Android, iOS),

Discussion:
First chunk of changes.
This is a really great set of edits. I think that it really improves the document as a whole! I have suggested a couple of minor edits.Quick partial language review
Change:
addresses has privacy implications.  This document describes a way to share local IP addresses with other clients while preserving client privacy.  This is achieved by obfuscating IP addresses with <del> dynamically generated Multicast DNS RFC6762 names. </del> <ins> dynamically generated Multicast DNS (mDNS) RFC6762 names. </ins> 1.

Discussion:
Or alternatively consistently use mDNS, but mention in the intro that this refers to Multicast DNS {{RFC6762}}
Yeah, I think we should do the latter. That's what 6762 does.
Change:
5.3. <del> The Key Distributor needs to know what endpoints are to being added to in a given conference resource.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </del> <ins> The Key Distributor needs to know what endpoints are being added to a given conference.  Thus, the Key Distributor and the Media Distributor will need to know endpoint-to-conference mappings, which is enabled by exchanging a conference-specific unique identifier as defined in I-D.jones-perc-dtls-tunnel.  How this unique identifier is assigned is outside the scope of this document. </ins> 6.

Discussion:
Fixed typos/deleted extra words in the Conf Id section.
LGTMlooks good.
Change:
10.7. <ins> Section 4.2.2 of RFC8446 defines a cookie value that servers may send in HelloRetryRequest for clients to echo in the second ClientHello. While ECH encrypts the cookie in the second ClientHelloInner, the backend server's HelloRetryRequest is unencrypted.This means differences in cookies between backend servers, such as lengths or cleartext components, may leak information about the server identity. Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server.  This may be done by handling HelloRetryRequest statefully, thus not sending cookies, or by using the same cookie construction for all backend servers. Note that, if the cookie includes a key name, analogous to Section 4 of RFC5077, this may leak information if different backend servers issue cookies with different key names at the time of the connection. In particular, if the deployment operates in Split Mode, the backend servers may not share cookie encryption keys.  Backend servers may mitigate this by either handling key rotation with trial decryption, or coordinating to match key names. 10.8. </ins> To signal acceptance, the backend server overwrites 8 bytes of its ServerHello.random with a value derived from the ClientHelloInner.random.  (See backend-server for details.)  This

Discussion:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)
Change:
The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes <del> the need for a device to perform clear-text "canary" HTTP queries to check for response tampering. </del> <ins> the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning).

Discussion:
Happy to elaborate on them if the motivation is not clear from the changes, let me know!
Thanks NAME b1dc7ba4e26ab17ed12d8a5a2408fe8063b1177a accepts the suggestion. 509d855e5ddba7dd1c5db58646c85516d0b40987 corrects the mistake I had made, which your question was about.
Looks great. Thanks for the PR!
Change:
A client SHOULD NOT reuse a NEW_TOKEN token for different connection attempts.  Reusing a token allows connections to be linked by <del> entities on the network path; see migration-linkability.  A client MUST NOT reuse a token if it believes that its point of network attachment has changed since the token was last used; that is, if there is a change in its local IP address or network interface.  A client needs to start the connection process over if there is any change in its local address prior to completing the handshake. </del> <ins> entities on the network path; see migration-linkability. </ins> Clients might receive multiple tokens on a single connection.  Aside from preventing linkability, any token can be used in any connection

Discussion:
states: This is an unnecessary constraint and there’s value in not having it. A server can, for example, include multiple IP addresses for a client in a token, enabling client validation from multiple attachment points.
Agreed. Just to give one example, it'd make sense for a server to issue a NEWTOKEN token containing two addresses, if the client is using one path to communicate while having another path being probed and validated. Note also that it is difficult to implement the MUST NOT that exists now. Consider the case where a client receives a NEWTOKEN frame during or after path migration. Is the client expected to bind the token to the old IP address? Or the new address? It is hard to tell the intention of the server.
I agree this seems unnecessary, given tokens cannot be used multiple times. The worst case scenario is including the token increases the number of Initial packets the client needs to send to two packets from one and the token turns out not to be useful for address validation.
As is clear from the PR, this should be marked design.
Change:
ServerHello messages authenticates the protocol version, so this value is redundant. <del> The length (in bytes) of the following TLSCiphertext.fragment, which is the sum of the lengths of the content and the padding, plus one for the inner content type.  The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </del> <ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of the content and the padding, plus one for the inner content type. The length MUST NOT exceed 2^14 + 256.  An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert. </ins> The AEAD encrypted form of the serialized TLSInnerPlaintext structure.

Discussion:
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Yes. There is a fair amount of other cleanup needed in this area; I have lots of red pen markings on a printout but haven't translated them into a patch yet.
Bah, github was angry-unicorning on me and did not indicate that the comment went through. I guess github doesn't like me this week...
Change:
DTLS <del> SRTP </del> <ins> ZRTP </ins> QUIC

Discussion:
This revises the description of SRTP and the relation between SRTP, DTLS, and ZRTP.
If we keep that headline, we need one for DTLS-SRTP too. Yes, that was intentional. SRTP is just the record protocol. The key management is usually done by DTLS or occasionally by ZRTP.
Comment from Ekr's review of -10: Pre-Connection Interfaces […] Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches.
ZRTP uses , compared by the users, as an external authentication mechanism (similar process to the Safety Numbers in Signal, I believe). ZRTP does maintain a session cache.
In other words, ZRTP supports interfaces to Authentication Delegation and Session Cache Management, and DTLS-SRTP does not?
Thanks for the reply. I'm okay with merging these changes as they are, or you can add that one reference for ZRTP to have both.
Change:
5. The authors would like to thank Mert Ocak, Heidi-Maria Back, Tero <del> Kauppinen, and Michael Koster for the reviews and feedback. </del> <ins> Kauppinen, Michael Koster, Robby Simpson, Ravi Subramaniam, and Dave Thaler for the reviews and feedback. </ins>

Discussion:
Removed "path is hierarchical query not" comment. Added note about query component order being unspecified.
This addresses issue
URL
Fixed in PR Hi, In reading draft-keranen-t2trg-rest-iot-01 I note the following: It is my understanding that this statement is subject to debate. Certainly some RESTful APIs assign hierarchical semantics to the path. For example, /foo may refer to a "collection-style" resource and /foo/bar may refer to a resource within that collection. However, is this a necessary requirement? From my perspective, this could potentially limit extensibility as future revisions of a RESTful API may, for instance, wish to insert a resource "between" /foo and /foo/bar. If the resources themselves are truly self-describing, containing links to "subordinate" resources, then the path portion of the URI can become an opaque identifier and backward compatibility in this hypothetical RESTful API could be maintained. Likewise, I have seen RESTful APIs where the order of the elements in the query portion of the URI matters (particularly if a given element occurs multiple times). I would suggest staying silent on the semantics of these parts of the URI or noting that they MAY be hierarchical / non-hierarchical. Thanks, Robby
Change:
server MAY include an "encrypted_client_hello" extension in its EncryptedExtensions message with the following payload: <del> An ECHConfigs structure containing one or more ECHConfig </del> <ins> An ECHConfigList structure containing one or more ECHConfig </ins> structures, in decreasing order of preference, to be used by the client in subsequent connection attempts.  These are known as the server's "retry configurations".

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
example, if reliable delivery was requested for a Message handed over before calling Close, the Closed Event will signify that this Message has indeed been delivered.  If the Remote Endpoint still has data to <del> send, it cannot be received after this call. </del> <ins> send, it cannot be received after this call.  This action does not affect any other Connection that is entangled with this one in a Connection Group. </ins> The Closed Event informs the application that the Remote Endpoint has closed the Connection.  There is no guarantee that a remote Close will indeed be signaled. <del> Abort terminates a Connection without delivering any remaining data: </del> <ins> Abort terminates a Connection without delivering any remaining data. This action does not affect any other Connection that is entangled with this one in a Connection Group. AbortGroup terminates a Connection and also terminates any other Connections that are entangled with this one in a Connection Group. For example, all of the Connections in a group might be streams of a single session for a multistreaming protocol; aborting the entire group would close the underlying session.  See also groups. </ins> A ConnectionError informs the application that: 1) data could not be delivered to the peer after a timeout, or 2) the Connection has been

Discussion:
Should taps-interface provide a way to close a connection group? I don't see an obvious way to close an HTTP/2 or QUIC connection just using connection-level commands. You could make TAPS automatically close a connection if all user streams are closed, but that's... not great?
What's the problem with closing a connection (I presume you mean the underlying transport's one, not the one exposed by TAPS) once all user streams (i.e., grouped TAPS Connections) are closed? I think this would obviously happen. If I, as a user, want to avoid delay for connection establishment and tear-down, I'm not closing my Connection... Else, closing a group containing multiple open Connections in one go would be a matter of issuing "Close" for all of them... e.g., by checking the Connection's group number, in a loop. We could spec that as part of the API, but it doesn't seem to be extremely useful to me, as this function could very easily be written on top of the TAPS API.
This works for me, Gorry
Alternative discussed: make ConnectionGroup an explicit object (as opposed to just a []Connection), and add (at least) an AbortGroup call on it. Another option: add AbortGroup to a Connection, which aborts all connections in the group. Discussion at December interim leans toward the second: don't create a new object for only one operation.
Also, make sure to be clear that Abort() does NOT close all entangled Connections. (same thing for Close())