jiebi/CodeConvo huggingface dataset:
Change:
The requested operation cannot be served over HTTP/3.  The peer should retry over HTTP/1.1. <ins> Error codes of the format "0x1f * N + 0x21" for integer values of N are reserved to exercise the requirement that unknown error codes be treated as equivalent to H3_NO_ERROR (extensions).  Implementations SHOULD select an error code from this space with some probability when they would have sent H3_NO_ERROR. </ins> 9. HTTP/3 permits extension of the protocol.  Within the limitations

Discussion:
Pleasantly, the same formula we've used for grease values elsewhere in HTTP/3 does not collide with any currently-assigned error code, so I've just reused it. (We'll need to be cautious about 0x119, though.) The same logic could be applied to transport error codes, but there's not much point. If you're intolerant of the way your peer closed the connection, you might erroneously... close the connection? Editorial-ish: A recommendation which reserves some error code space we haven't used; modifies the IANA instructions. Doesn't mandate or prohibit anything new.
Constraining the recommendation on grease streams, because sending any error code potentially generates an error code that has semantics to your peer of which you are unaware.
The discussion on made us conclude that the reason for doing this is that we want to safeguard our ability to define new error codes. Greasing might help with that.
Since you'd probably want want the grease to not sacrifice connections it might make sense to couple grease error codes to H3 grease streams. Also, what about greasing of transport-level error codes? Can't play the stream tricks there.
Unknown error codes are supposed to be equivalent to H3NOERROR. Perhaps a recommendation (SHOULD) to substitute a grease code with non-zero probability when you would have sent NO_ERROR? And MAY use them when terminating grease streams, sure.
Looks fine to me. I wonder how much this will end up doing anything...LG, but I think it's worth accepting Martin's suggestion.
Change:
was sent in the same connection (i.e., where the ClientHello was itself in response to a HelloRetryRequest). <del> Otherwise, the client MUST send a ClientHello with a new KeyShare extension to the server.  The client MUST append a new KeyShareEntry list which is consistent with the "selected_group" field to the groups in its original KeyShare. </del> <ins> Otherwise, the client MUST send a ClientHello with an updated KeyShare extension to the server.  The client MUST append a new KeyShareEntry for the group indicated in the selected_group field to the groups in its original KeyShare. </ins> Upon re-sending the ClientHello and receiving the server's ServerHello/KeyShare, the client MUST verify that the selected CipherSuite and NamedGroup match that supplied in the <del> HelloRetryRequest. </del> <ins> HelloRetryRequest.  If either of these values differ, the client MUST abort the connection with a fatal "handshake_failure" alert. </ins> [[OPEN ISSUE: https://github.com/tlswg/tls13-spec/issues/104]]

Discussion:
NAME You addressed the main ambiguity in URL . This fixes a few remaining issues. An itemized list: "handshakefailure" alert is fatal note it must be appended, not just "used", in the selectedgroup description (just using instead of appending creates a downgrade attack due to lack of authentication for this message, as discussed previously) clean up styling of variable names; the dominant style uses no quotes around variable names, but quotes around enum values (granted, this may not be the ideal style, but it is more or less consistently the case elsewhere in the document) note that the same rule as ServerHello applies: no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if "MUST" fails (could be a "SHOULD" error, here)
NAME Repushed commit with changes for comments. Changed description to not say used/amended, but rather describe what it actually represents directly: the group the server intends to negotiate and is requesting a retry for. (we don't need duplicated MUSTs here, and stating its actual meaning more explicitly is preferable) Changed text wrt selected group as suggested.
Rebased on top of PR (which still merges cleanly onto master, as of this moment; this does too) to avoid flip-flopping again on the omit vs. empty KeyShare for retry request.
Change:
no time should it be simple or straightforward for one User Equipment to pretend to be another User Equipment, regardless of whether both are active at the same time.  This property is particularly important <del> when the User Equipment is extended externally to devices such as billing systems, or where the identity of the User Equipment could imply liability. </del> <ins> when the User Equipment identifier is referenced externally by devices such as billing systems, or where the identity of the User Equipment could imply liability. </ins> 3.2.3.

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
In the following cases, failure should be detected during pre- establishment: <del> A request by an application for Protocol Properties that include requirements or prohibitions that cannot be satisfied by any of the available protocols.  For example, if an application requires "Configure Reliability per Message", but no such feature is available in any protocol the host running the transport system on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. </del> <ins> A request by an application for Protocol Properties that cannot be satisfied by any of the available protocols.  For example, if an application requires "Configure Reliability per Message", but no such feature is available in any protocol the host running the transport system on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. </ins> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited

Discussion:
So implementation talks about pooled connections - I must have blinked and missed that, obviously it is different to a connection group - or is it? If I am asking a silly question then I suspect we need just a few lines of text to demuddle me.
LGTM, thanks!
Change:
The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: <del> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated bidirectional streams to be used by WebTransport: </del> <ins> The "WEBTRANSPORT_STREAM" frame allows HTTP/3 client-initiated and server-initiated bidirectional streams to be used by WebTransport: </ins> 0x41

Discussion:
This updates the IANA considerations section for Frame Type to match URL, by including "server-initiated" in the type of bidirectional streams allowed by the frame.
Change:
Unlike TLS implementations, DTLS implementations SHOULD NOT respond to invalid records by terminating the connection. <ins> TLS 1.3 requires replay protection for 0-RTT data (or rather, for connections that use 0-RTT data; see Section 8 of TLS13).  DTLS provides an optional per-record replay-protection mechanism, since datagram protocols are inherently subject to message reordering and replay.  These two replay-protection mechanisms are orthogonal, and neither mechanism meets the requirements for the other. </ins> The security and privacy properties of the CID for DTLS 1.3 builds on top of what is described for DTLS 1.2 in I-D.ietf-tls-dtls- connection-id.  There are, however, several differences:

Discussion:
Discuss the properties needed of cookies and some ancillary operational procedures, as well as mentioning that the DTLS record replay protection mechanism and 0-RTT replay protection mechanism play different roles and cannot substitute for each other.
Change:
it. To check the health of the WebSocket connection (and thereby of all <del> active requests, if any), the client can send a Ping frame or an unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There is no way to retransmit a request without creating a new one.  Re- registering interest in a resource is permitted, but entirely </del> <ins> active requests, if any), a client can send a CoAP Ping Signaling message (sec-ping).  WebSocket Ping and unsolicited Pong frames as specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that redundant maintenance traffic is not transmitted. There is no way to retransmit a request without creating a new one. Re-registering interest in a resource is permitted, but entirely </ins> unnecessary. 3.5.

Discussion:
There needs to be guidance about the intersection of WebSocket Ping-Pong and Signaling Ping-Pong.
Since Signaling Ping-Pong is a superset of WebSockets Ping-Pong and to use a consistent mechanism across reliable transports, I will add guidance that Signaling Ping-Pong is preferred over WebSockets Ping-Pong.
Change:
This procedure is intended to permit or prohibit presence of a certain KeyPurposeId or complete absence of KeyPurposeIds.  It is outside the scope of this document, but the relying party can <del> permit or prohibit combinations of KeyPurposeIds, instead of </del> <ins> permit or prohibit combinations of KeyPurposeIds, instead of a </ins> single KeyPurposeId.  A consideration on prohibiting combinations of KeyPurposeIds is described in the Security Considerations section of this document.  If both "Excluded KeyPurposeId" and

Discussion:
Addressing Erik's . Given that documents may be presented to people "by means of ... software" perhaps a slight tweak to the "rather than processed by machines", e.g.: "rather than processed primarily by machines", or "rather than processed principally by machines" s/instead of single/instead of a single/ s/proresses/processes/ I think?
Change:
This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. <del> The behaviour of a "descendant-selector" is unpredictable if the node or one of its descendants is an object with duplicate names. </del> The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node.

Discussion:
Centralize the text that explains how non-interoperable JSON may cause unpredictable behavior. This is a little clumsy as the sections to be referenced are currently unnumbered.
Solves a few "behaviours", too :-)
This centralizing approach is a good thing. I suggest to reuse the phrase "duplicate names" for better recognition of the wording in RFC8259, though is more general, as it addresses more than two.
There may be scope for fine-tuning the section cross-referencing, but this can be deferred to purely editorial activity
Change:
3. <del> QUIC provides for 0-RTT connection establishment.  This presents opportunities and challenges for applications using QUIC. 3.1. </del> <ins> QUIC provides for 0-RTT connection establishment.  Though the same facility exists in TLS 1.3 with TCP, 0-RTT presents opportunities and challenges for applications using QUIC. </ins> A transport protocol that provides 0-RTT connection establishment is qualitatively different than one that does not from the point of view

Discussion:
This cuts a section heading and coalesces a few paragraphs. It adds a point of comparison with TLS 1.3.
Section 3 talks about the challenges of 0-RTT, but seems to ignore that very similar challenges exist when TLS 1.3 Early Data is used over TCP. I think I'd reword this to talk about the similarity, and that while QUIC gives Early Data more visibility, the same cautions and mitigations still apply. (I'd also probably find a more technical title than "Here There Be Dragons," but that's purely stylistic.)
I agree that challenges are similar to TLS1.3 over TCP. However, given this document is scoped to the use of QUIC, I'm not sure what mentioning TCP in this section gets you. I find the section actually quite clear without mentioning anything about TCP. Or did I miss the point you are making?
Otherwise PRs are always welcome! :-)
Change:
At the time this is published, the response types are works in progress.  The only response type defined in this document is <del> "application/dns-udpwireformat", but it is possible that other response formats will be defined in the future. </del> <ins> "message/dns", but it is possible that other response formats will be defined in the future. </ins> <del> The DNS response for "application/dns-udpwireformat" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </del> <ins> The DNS response for "message/dns" in dnswire MAY have one or more EDNS options, depending on the extension definition of the extensions given in the DNS request. </ins> Each DNS request-response pair is matched to one HTTP exchange.  The responses may be processed and transported in any order using HTTP's

Discussion:
The media type has been the subject of some debate. The above might be the best I've seen.
Change:
across two QUIC connections: one before the Version Negotiation packet, and a distinct connection after. <del> 3.2. </del> <ins> 4.2. </ins> <del> The server starts incompatible version negotiation by sending a VN packet, listing all the versions that it does support. </del> <ins> The server starts incompatible version negotiation by sending a Version Negotiation packet.  This packet SHALL include each entry from the server's set of Offered Versions (see server-fleet) in a Supported Version field.  The server MAY add reserved versions (as defined in the Versions section of QUIC) in Supported Version fields. </ins> Upon receiving the VN packet, the client will search for a version it supports in the list provided by the server.  If it doesn't find one,

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.
Change:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> This document uses terminology from QUIC. Where this document defines protocol types, the definition format uses the notation from QUIC.  Where fields within types are integers, they are encoded using the variable-length integer encoding from QUIC.  Integer values do not need to be encoded on the minimum number of bytes necessary. </ins> 2. HTTP Datagrams are a convention for conveying bidirectional and

Discussion:
Inspired by Martin Duke's suggestion to reference integer encoding more directly, this change just sticks it all in one place and makes it clear that there is no expectation to minimally-encode varints. Styled on similar references to QUIC made in URL
Change:
5. <ins> Main differences of mapping to DetNet MPLS (compared to plain MPLS) are that (1) there is a mandatory flow identification to make the forwarding decision (i.e., forwarding is not based on FEC), (2) the d-CW (DetNet Control Word) is mandatory for the MPLS encapsulation and (3) during forwarding over the DetNet MPLS network DetNet flow specific treatment is needed. </ins> 5.1. A DetNet relay node (ingress T-PE) that sends a DetNet IP flow over a

Discussion:
Changes: 1, Section “5. IP over DetNet MPLS Procedures” Add new text before section 5.1. 2, Fix a nit in penultimate paragraph of “5.1. DetNet IP over DetNet MPLS Flow Identification and Aggregation Procedures”
Change:
is a specific type of packet injection attack that is used to interrupt an established stream by sending RST packets to both sides of a TCP connection; as each receiver thinks the other has dropped <del> the connection, the session is terminated.  QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (See I-D.ietf-quic-transport for more details). </del> <ins> the connection, the session is terminated. QUIC is not vulnerable to these types of injection attacks once the connection has been setup, but is vulnerable during setup (See I- D.ietf-quic-transport for more details). </ins> Trade-offs: Although ineffective against non-TCP protocols (QUIC, IPSec), RST Packet Injection has a few advantages that make it

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
supported. The place such URIs are specified (see general-record-format) allows <del> a list of these to be provided.  A report is normally sent to each listed URI in the order provided by the Domain Owner.  Receivers MAY impose a limit on the number of URIs to which they will send reports but MUST support the ability to send to at least two.  The list of URIs is separated by commas (ASCII 0x2C). </del> <ins> a list of these to be provided.  The list of URIs is separated by commas (ASCII 0x2c).  A report is normally sent to each listed URI in the order provided by the Domain Owner. </ins> Each URI can have associated with it a maximum report size that may be sent to it.  This is accomplished by appending an exclamation

Discussion:
should serve to regulate the size of reports, by sending them more often. See .
The work of the design team is to propose text at this stage. Discussion of the proposed text can take place on-list starting after April 23.
Change:
client-facing server forwards all other TLS messages between the client and backend server unmodified. <del> Otherwise, if all candidate ECHConfigs fail to decrypt the extension, the client-facing server MUST ignore the extension and 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> Otherwise, if all candidate ECHConfig values fail to decrypt the extension, the client-facing server MUST ignore the extension and 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. </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:
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:
need be, by providing an expiry date or by signaling that records from a particular window need to be refreshed. <del> 8.4. </del> <ins> 8.3. </ins> [[OPEN ISSUE: explain potential and mitigations for server centralization]]

Discussion:
cc NAME NAME
Yeah, I agree. Something to bring up for discussion.
LGTM, 1 week might still be too small of a window for actively malicious servers, but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations.
Change:
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, message authentication, and replay protection for RTP data packets <del> and RTP control protocol (RTCP) packets RFC3711. </del> <ins> and RTP control protocol (RTCP) packets RFC3711.  SRTP can use different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or ZRTP RFC6189. </ins> 3.2.2.

Discussion:
This PR mainly changes the beginning of Section 3, Transport Security Protocol Descriptions. It substitutes the sentence on how the document is structured (which I moved to the Introduction) with a brief discussion on the classification we use in Section 3. This includes an explanation of the difference between handshake and record protocols as suggested by Ekr. Furthermore, this PR references DTLS-SRTP, renames "QUIC + TLS" to "IETF QUIC", and mentions that OpenVPN can use TLS as a handshake protocol.
Thank you!