jiebi/CodeConvo huggingface dataset:
Change:
amount of review provided by the WG for cipher suites and supported groups.  This change reflects reality in that the WG essentially provided no cryptographic review of the cipher suites or supported <del> groups.  This was espcecially true of national cipher suites. </del> <ins> groups.  This was especially true of national cipher suites. Recommended algorithms regarded as secure for general use at the time of registration, however, cryptographic algorithms and parameters will be broken or weakened over time.  It is possible that the recommended status in the registry lags behind the most recent advances in cryptanalysis.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. </ins> 18.

Discussion:
This fixes a typo in the security considerations section and adds some additional text.
We probably need to say something more in the security considerations. What springs to mind first is the implications of relaxing to specification required for cipher suites and named groups. There must be others.
Change:
The cipher suite for use with this PSK <del> The Application-Layer Protocol Negotiation (ALPN) protocol, if any is to be used </del> <ins> The Application-Layer Protocol Negotiation (ALPN) protocol RFC7301, if any is to be used </ins> The Server Name Indication (SNI), if any is to be used

Discussion:
The reference to [RFC7301] is after the third mention of ALPN. It should instead be at the first reference to ALPN.
Change:
4.3. <del> HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230, Section 6.7) or 101 (Switching Protocols) informational status code (RFC7231, Section 6.2.2). </del> <ins> HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.7 of RFC7230) or 101 (Switching Protocols) informational status code (Section 6.2.2 of RFC7231). </ins> 4.4.

Discussion:
Martin flagged this on some imported text in , but others have crept in other places, mostly also as text imported from RFC7540. For future reference, (({{])), (Section d+(.d+)*) => 1
Change:
Abstract <del> In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about a remote peer to assess the peer's trustworthiness, and a way to appraise such evidence.  The evidence is typically a set of claims about its software and hardware platform.  This document describes an architecture for such remote attestation procedures (RATS). </del> <ins> In network protocol exchanges it is often the case that one entity requires believable evidence about the operational state of a remote peer.  Such evidence is typically conveyed as claims about the peer's software and hardware platform, and is subsequently appraised in order to assess the peer's trustworthiness.  The process of generating and appraising this kind of evidence is known as remote attestation.  This document describes an architecture for remote attestation procedures that generate, convey, and appraise evidence about a peer's operational state. </ins> 1.

Discussion:
The last sentence of the abstract is: but "such" remote attestation procedures are not defined earlier.
This abstract literally reads more self-consistent. +1
Change:
An agent that uses this protocol to establish shared cryptographic state with other clients.  A client is defined by the <del> cryptographic keys it holds.  An application or user may use one client per device (keeping keys local to each device) or sync keys among a user's devices so that each user appears as a single client. </del> <ins> cryptographic keys it holds. </ins> A collection of clients with shared cryptographic state.

Discussion:
Could you please just restore the PSK part of the KeySchedule, I’ll handle that separately. Ps: we wouldn’t have forgot you... :) we intended to go back to the list later, but I’ll merge it now...
Change:
6.3. <ins> For a device that is battery-powered, it is often critical that it remains dormant for extended periods.  Radio communication in particular consumes significant power and limits the length of time that the device can operate. To avoid consuming resources to receive trivial messages, it is helpful if an application server can communicate the urgency of a message and if the user agent can request that the push server only forward messages of a specific urgency. An application server MAY include an Urgency header field in its request for push message delivery.  This header field indicates the message urgency.  The push service MUST not forward the Urgency header field to the user agent.  A user agent MAY include the Urgency header field when requesting push messages to indicate that it only wants to receive messages at an equal or greater urgency. An absent Urgency header field indicates that the request is to be forwarded at "normal" urgency.  Multiple values for the header field MUST NOT be included in requests; otherwise, the push service MUST return a 400 (Bad Request) status code. 6.4. </ins> A push message that has been stored by the push service can be replaced with new content.  If the user agent is offline during the time that the push messages are sent, updating a push message avoids

Discussion:
Should we include a reference to URL - perhaps in Acknowledgements?
I don't care about acknowledgments for -nice. But I do care about the issues that I raised on the list.
Change:
Abstract While WebRTC has been very sucessful in a wide range of scenarios, <del> its adption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </del> <ins> its adoption in the broadcasting/streaming industry is lagging behind.  Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it. </ins> These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with

Discussion:
Authtentication, bearear, proposse, detailled, endpoings, adption, traditionnal.
Thank you very much!
Change:
mechanisms SHOULD be used to protect it, including file system controls, physical security, or hardware security modules. <del> 6.2. </del> <ins> 7.2. </ins> It is not possible to use the same delegated credential for both client and server authentication because issuing parties compute the corresponding signature using a context string unique to the intended role (client or server). <del> 6.3. </del> <ins> 7.3. </ins> Delegated credentials do not provide any additional form of early revocation.  Since it is short lived, the expiry of the delegated

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
In addition to the features that pull requests share with issues, users can also review the changes in a pull request.  This is a <del> valuable feature, but it has some issues. </del> <ins> valuable feature, but presents some challenges. </ins> Comments in a review other than a summary are attached to specific lines of the proposed change.  Such comments can be hard or

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
The agent MUST include the ICE-CONTROLLED attribute in the request if it is in the controlled role, and MUST include the ICE-CONTROLLING <del> attribute in the request if it is in the controlling role.  The content of either attribute MUST be the tie-breaker that was determined in sec-role.  These attributes are defined fully in sec- </del> <ins> attribute in the request if it is in the controlling role. The content of either attribute are used as tie-breaker values when an ICE role conflict occurs sec-role-conflict. The ICE-CONTROLLED and ICE-CONTROLLING attributes are defined in sec- </ins> ice-newatts. 6.1.2.4.

Discussion:
Trying to avoid conflicts with txt files by creating a new pull request for the tie-breaker and role changes.
Change:
This behavior creates a number of possible attacks for certain server configurations.  For example, if "https://$HOSTNAME/upload" accepts any POST request as a public file upload, the adversary could forge a <del> SVCB record containing "dohpath=/upload".  This would cause the </del> <ins> SVCB record containing "dohpath=/upload{?dns}".  This would cause the </ins> client to upload and publish every query, resulting in unexpected storage costs for the server and privacy loss for the client. Similarly, if two DoH endpoints are available on the same origin, and

Discussion:
NAME Please review.
currently says: This MUST seems strange. Is this just saying "don't do silly or otherwise bad things with client queries"? I'm not sure that's something we need normative language for here, so unless there's a particular behavior that this is meant to require (or prohibit), I'd recommend removing it.
Suppose is your consumer-facing endpoint with limited logging, and is a debug endpoint that drops all queries into a log that's accessible to your whole engineering staff. The point of this sentence is that, if this is your configuration, you can't promise users the limited logging on the consumer-facing endpoint, because any intermediary could flip users onto the debug endpoint, causing you to violate your own promise. You need to move these endpoints onto separate hostnames. Separate paths, port numbers, or even separate ALPNs, is not sufficient, because an attacker can steer the user between them.
I agree the original text was unclear unless you're already familiar with the problem. I wasn't. However Ben's response above DID make sense to me, so it would be good to use some of it.
recommends that clients mitigate redirection attacks by not using client authentication to DNS resolvers. Perhaps a better approach would be to not use a TLS context or association that is used for other purposes, regardless of whether that context uses client authentication.
I don't think that is sufficient. The attack does not depend on the client authentication being shared with another context. For example, if I rewrite the to be , and this triggers an HTTP Basic Authentication response that causes the client software to pop up a username+password prompt, the user might log in and enable the attack.
There are lots of ways connection state could be misused here. For example, what if the new DNS query is sent over a connection that uses cookies? What if the DNS query resumes a previously established TLS connection that used some application layer authentication? Basically, this text seems not quite right, since it seems to focus on TLS-layer things. I recommend further refining to make it clear what is expected of this new connection. I'm happy to propose a PR to clarify my thinking, if that would be useful.
"Client authentication" in this text is not intended to to be limited to TLS. It applies to any form of client authentication in any protocol, including HTTP.
Great -- I'll propose text!
I've added a small change to that tries to clarify this requirement.
Change:
It was noted in XPROT that certificates in use by servers that support outdated protocols such as SSLv2 can be used to forge signatures for certificates that contain the keyEncipherment KeyUsage <del> (RFC5280 section 4.2.1.3).  In order to prevent this type of cross- protocol attack, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate- requirements.) </del> <ins> (RFC5280 section 4.2.1.3).  In order to reduce the risk of cross- protocol attacks on certificates that are not intended to be used with DC-capable TLS stacks, we define a new DelegationUsage extension to X.509 that permits use of delegated credentials.  (See certificate-requirements.) </ins> 3.1.

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
cease retransmission of the closing packet. Disposing of connection state prior to the end of the closing or <del> draining period could cause delayed or reordered packets to be handled poorly.  Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not create QUIC state, such as those that are able to close the UDP socket, MAY use an abbreviated draining period which can allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. </del> <ins> draining period could cause delayed or reordered packets to generate an unnecessary stateless reset.  Endpoints that have some alternative means to ensure that late-arriving packets on the connection do not induce a response, such as those that are able to close the UDP socket, MAY use an abbreviated draining period which can allow for faster resource recovery.  Servers that retain an open socket for accepting new connections SHOULD NOT exit the closing or draining period early. </ins> Once the closing or draining period has ended, an endpoint SHOULD discard all connection state.  This results in new packets on the

Discussion:
FWIW, the state that was implied was the creation of a new connection. That's not realistic in QUICv1 however, so this is good.
I'm not following why in general this would create state. If the handshake has occurred > MSL ago, and you just refuse to create state on short packets with unknown CIDs s, why isn't that enough?
This was written when there was some uncertainty about what packets might look like. I think that we can truncate this sentence. Basically, you can drop state earlier, but it will mean that you won't be able to attribute any laggardly packets properly.
Change:
10.4.1. <del> An endpoint detects a potential stateless reset when a incoming packet with a short header either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet. The endpoint then compares the last 16 bytes of the packet with the Stateless Reset Token provided by its peer, either in a NEW_CONNECTION_ID frame or the server's transport parameters.  If these values are identical, the endpoint MUST enter the draining period and not send any further packets on this connection.  If the </del> <ins> An endpoint detects a potential stateless reset when an incoming packet either cannot be associated with a connection, cannot be decrypted, or is marked as a duplicate packet.  The endpoint MUST then compare the last 16 bytes of the packet with all Stateless Reset Tokens that are associated with connection IDs that are currently in use.  This includes Stateless Reset Tokens from NEW_CONNECTION_ID frames and the server's transport parameters.  An endpoint MUST NOT check for any Stateless Reset Tokens associated with connection IDs it has not used or for connection IDs that have been retired. If the last 16 bytes of the packet values are identical to a Stateless Reset Token, the endpoint MUST enter the draining period and not send any further packets on this connection.  If the </ins> comparison fails, the packet can be discarded. 10.4.2.

Discussion:
We don't want to prohibit the use of long headers in other versions - in case they want to share the stateless reset design, but there is no sense in sending long headers.
While I agree with the issue, the PR says that other versions might want to reset with a long header and therefore the receiver must inspect long headers anyway. I can see this, but given that, I think it is pointless to require the current version to only send resets for short headers. A general advice ought to suffice since the MUST is not enforceable anyway.
The requirement exists to protect those packets from detection.
Please don't close issues until AFTER consensus is declared (not just called).
I suspect Martin was confused because this issue was tagged has-proposal 15 days ago.
Right. The trigger is , not .
But it's understandable Martin would have assumed this was one of the issues that was sent out in the batch of issues a week and a half ago, given this has been tagged with has-proposal for 15 days.
Change:
but uses normal HTTP content negotiation mechanisms for selecting alternatives that endpoints may prefer in anticipation of serving new use cases.  In addition to this media type negotiation, it aligns <del> itself with HTTP features such as caching, proxying, and compression. </del> <ins> itself with HTTP features such as caching, redirection, proxying, and compression. </ins> The integration with HTTP provides a transport suitable for both traditional DNS clients and native web applications seeking access to

Discussion:
Thats better. Thanks
It would be good to explicitly call out the DNS rcode SERVFAIL as a type of failure response as well, not just NXDOMAIN, as they are very different sorts of failures such that the latter can be considered, in some contexts, as not really a failure.
the merged patch URL no longer mentions specific rcodes at all.. wdyt?
I personally think that as a DNS implementer that there is enough ambiguity around understanding a valid DNS response, a negative answer, and a failure response, that it should be made more painfully clear that something like all DNS servers returning message-valid SERVFAILs still warrants an HTTP 2xx.
Agree with NAME .
will reopen the issue to add more text
largely a restating of mailing list thread: A question on the mix of DNS and HTTP semantics
keep pr but reopen the issue to add a little more text
Liked Martin's rewording for the response text, but removed the security considerations until further discussion. Patrick, please edit or pull.
Change:
Envelope the result in "^" and "$". <del> Note that where a regexp literal is required, this needs to enclose the actual regexp in "/". The performance of an ECMAScript matcher can be increased by turning parenthesized regexps (last choice in production "atom") into "(?:...)" constructions. </del> <ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/". </ins> 5.3.

Discussion:
Implemented the changes as suggested in Issue
The purpose of this issue is to start discussion about how to turn this into a completed draft to send to the IESG. Perhaps the most important issue is how much of the explanatory and motivational material to leave in. There is a case to be made for taking all of it out, so you get a nice short RFC that just says what I-Regexp is. So here's my initial straw-person proposal on what should be removed and changed: Remove the "issues" para in Section 3. Section 5.2, 5.3, remove the trailing note about improving performance. This is an implementation artifact, no? Section 6. Replace with a single short paragraph somewhat as follows: "While regular expressions originally were intended to describe a formal language, i.e., to provide a Boolean matching function, they have turned into parsing functions for many applications. With this accretion of features, parsing regexp libraries have become susceptible to bugs and performance degradation, in particular those that can be exploited in Denial of Service (DoS) attacks in the case where an attacker controls the regex submitted for processing. I-Regexp is designed to offer interoperability, and to be less vulnerable to such attacks, with the trade-off that its only function is to offer a boolean response as to whether a character sequence is matched by a regex. [ If we really feel that other parts of this discussion add value, they could migrate into an appendix.] 6.1 - cut this down, retaining the first para of the first bullet point, the first sentence of the second bullet point, and that's all. The Unicode discussion can migrate into Appendix A.
Resolved by
Change:
that identifies the specific occurrence of the problem.  It may or may not yield further information if dereferenced. <ins> When the "instance" URI is dereferenceable it can return the same problem response that was returned to the client which generated the problem originally.  It might also return more information about the problem occurrence in other formats (e.g., using proactive content negotiation; see HTTP, Section 12.5.1). When the "instance" URI is not dereferenceable, it serves as a unique identifier for the problem occurrence that may be of significance to the server, but is opaque to the client. </ins> When "instance" contains a relative URI, it is resolved relative to the document's base URI, as per RFC3986, Section 5.  However, using relative URIs can cause confusion, and they might not be handled

Discussion:
As discussed in URL, this PR expands on the dereferenceability of to clarify what the URI is expected to return, which hopefully also clarify the intended use of .
Merging, might tweak a bit further in situ. Thanks!
Change:
Verify that the resulting URI is well-formed. <del> Dereference the URI using an HTTP GET request. </del> <ins> Dereference the URI using an HTTP GET request.  This request MUST be sent to TCP port 80 on the server. </ins> Verify that the body of the response is well-formed key authorization.  The server SHOULD ignore whitespace characters at

Discussion:
I spotted a typo/error introduced by this PR and submitted a follow-up: URL
Since we did not get consensus around , we should be explicit that HTTP is TCP port 80, and HTTPS is TCP port 443, and that holds for redirects as well. The is pretty much a minor wording change only.