jiebi/CodeConvo huggingface dataset:
Change:
Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its <del> claimed network address.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request.  The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </del> <ins> claimed network address; it is now the recommeded way to mitigate amplification attacks.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </ins> 1.

Discussion:
I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten
Change:
"RateLimit" values and the returned status code. Servers should be careful in returning "RateLimit" fields in <del> redirection responses (eg. 3xx status codes) because a low </del> <ins> redirection responses (e.g. 3xx status codes) because a low </ins> "RateLimit-Remaining" value could limit the client from issuing requests.  For example, given the rate limiting fields below, a client could decide to wait 10 seconds before following the

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:
15.8.1. This section registers the "application/cose" and "application/ <del> cose+cbor" media types in the "Media Types" registry.  [CREF17] These </del> <ins> cose+cbor" media types in the "Media Types" registry.  [CREF15] These </ins> media types are used to indicate that the content is a COSE_MSG. Type name: application

Discussion:
The CFRG EC algorithms are currently too far in the future to keep. Remove the ad put in the to be done later document.
Change:
gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. <del> For the current default candidate, a "c=" line, as specific in </del> <ins> For the current default candidate, a "c=" line, as specified in </ins> RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1.

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
and require configuration changes to address the underlying cause. For example, if attestation is compromised because of a zero-day exploit on compliant devices, then the corresponding attestation <del> format should be untrusted until the exploit is patched.  Addressing changes in attestation quality is therefore a deployment-specific task.  In Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched. </del> <ins> procedure should be untrusted until the exploit is patched. Addressing changes in attestation quality is therefore a deployment- specific task.  In Split Attester and Issuer deployments (see deploy- split), Issuers can choose to remove compromised Attesters from their trusted set until the compromise is patched. </ins> 3.2.2.

Discussion:
From Section 3.2.1: This is a pretty wild equivalence. I stumbled badly on this one. It's very much like saying "in this context a verb is sometimes referred to as a noun". Is the goal here to say that "there is a attestation process by which the Attester determines whether a Client meets the requirements for issuance; if successful, the Attester captures this information using an attestation format" ? That seems to be the case, but that's not what this says.
I think we might just drop the equivalence to avoid confusion, but in the interest of transparency, here's where it came from. Consider the two following types of attestation procedures: Attestation based on , where the client and attester use this mechanism to prove that the client's device is valid. Attestation based on , perhaps where the signature is computed in some client enclave, where the client authenticates its token request with such a ring signature. In (1), attestation is some procedure that takes place between client and attester, whereas in (2) attestation is sort of non-interactive mechanism for producing an attestation format or proof of sorts. Since we don't specify the details of attestation, the text was written in a way to be maximally accommodating to these types of things. In any case, I think it's probably fine to just treat attestation as a procedure_, be it interactive or non-interactive or whatever, and that procedure has certain properties associated with it. I'll propose text.
Change:
An HTTP origin advertises the availability of an equivalent HTTP/3 endpoint via the Alt-Svc HTTP response header field or the HTTP/2 <del> ALTSVC frame (ALTSVC), using the Application Layer Protocol Negotiation (ALPN; see RFC7301) token defined in connection- establishment. </del> <ins> ALTSVC frame (ALTSVC), using the "h3" ALPN token. </ins> For example, an origin could indicate in an HTTP response that HTTP/3 was available on UDP port 50781 at the same hostname by including the

Discussion:
Section 3.2: "A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address on the indicated port, and sending an HTTP/3 request message targeting the URI to the server over that secured connection." draft-ietf-quic-tls states in Section 8.1: "Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose." Looking at Section 3.2 with Section 3.1 deleted I think there is an important aspect missing which is expressed in first sentence of Section 3.1: "HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc." In Section 3.3: "QUIC connections are established as described in [QUIC-TRANSPORT]. During connection establishment, HTTP/3 support is indicated by selecting the ALPN token "h3" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake." So what I interpret is that the inclusion of the "h3" ALPN token will be required in the clients messages when establishing an QUIC connection with the intention of communicating using HTTP/3 according to this specification. So I think there are two changes needed here. First that there needs to be a first paragraph in Section 3.2 to state that HTTP/3 uses "h3" as token in ALPN and Alt-Svc as a lead in, secondly that the sentence first referenced above needs to state that ALPN = "h3" will be given in the QUIC-TLS handshake. If I understand this correctly, a QUIC connection that has been established using "h3" ALPN token, i.e. client tells it interested in this application and where the server choice that token in the handshake will be using HTTP/3 according to this specification. It is possible for other ALPN tokens to be application foo using HTTP/3. Finally do I interpret things correctly that "h3" is not strictly required but then both client and server need to know that yes, this connection establishment is for the purpose of HTTP/3?
If some other mechanism is used for agreeing on protocol, ALPN can be omitted, yes. I'm not convinced that the first paragraph of 3.

[2->1] is the appropriate place to put the token statement; the section is about discovering an HTTP/3 endpoint given a URL, and the definition of the ALPN token is incidental there. I've added the token to 3.[2->1] in the paragraph about the connection; see what you think.
I think the proposed text does clarify the issue and makes the default and alternative clear. So this resolves my issue.
Based on , labeling this as "editorial"
Change:
operate over multiple (separate) DetNet member flows of a DetNet compound flow. <del> A control word used for sequencing and identifying duplaicate </del> <ins> A control word used for sequencing and identifying duplicate </ins> packets at the DetNet service layer. 2.2.

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
techniques to serve legacy clients, and clients will need to perform probing to detect captive portals. <ins> Clients that support the Captive Portal DHCP option SHOULD include the option in the Parameter Request List in DHCPREQUEST messages. DHCP servers MAY send the Captive Portal option without any explicit request. </ins> In order to support multiple "classes" of clients (e.g.  IPv4 only, IPv6 only with DHCPv6 (RFC3315), IPv6 only with RA) the captive portal can provide the URI via multiple methods (IPv4 DHCP, IPv6

Discussion:
Fixes issue
Aaaaannd fixed the merge conflicts again. NAME NAME please take a look!
In our interop testing, all of the implementations of portals require that the DHCP option is in the request list in order for it to be sent. We should be explicit that this is what SHOULD be done in the document (clients SHOULD request).
Change:
A "new-order" resource (applying-for-certificate-issuance) <del> A "revoke-certificate" resource (certificate-revocation) </del> <ins> A "revoke-cert" resource (certificate-revocation) </ins> A "key-change" resource (account-key-roll-over)

Discussion:
Fixes per feedback . Section 6.1 referenced "revoke-certificate" where elsewhere using "revoke-cert", this commit replaces it with "revoke-cert". Section 7.1 has a resource diagram that previously labelled the termination of the "new-account" flow as "acct", this commit replaces that label with "account". Elsewhere the use of "acct" is limited to URLs and not referencing specific resources/spec content. I'm resending this message as there were no responses and nothing changed. ---------- Forwarded message ---------- Morning, the current draft contains a few inconsistencies in the resource naming. 1) https://ietf-wg-URL mentions "revoke-certificate", while it's called "revoke-cert" in the rest of the document. 2) There's "new-account", but the account resource is called "acct", I think it should be "account" everywhere. We don't gain anything by saving a few keystrokes / bytes there. Maybe we should then also rename "authz" to "authorization" and "cert" to "certificate" everywhere. Regards, Niklas
Change:
IP header to influence the sender's rate.  RFC3168 discusses manipulations and their effects in more detail. <del> An on-the-side attacker can duplicate and send packets with modified ECN fields to affect the sender's rate.  If duplicate packets are discarded by a receiver, an off-path attacker will need to race the duplicate packet against the original to be successful in this </del> <ins> A limited on-path attacker can duplicate and send packets with modified ECN fields to affect the sender's rate.  If duplicate packets are discarded by a receiver, an attacker will need to race the duplicate packet against the original to be successful in this </ins> attack.  Therefore, QUIC endpoints ignore the ECN field on an IP packet unless at least one QUIC packet in that IP packet is successfully processed; see ecn.

Discussion:
This might conflict, but I think it supersedes the other "off-path" tweaks.
NAME said:
Change:
If an encoder receives a Header Acknowledgement instruction referring to a stream on which every header block with a non-zero Required Insert Count has already been acknowledged, that MUST be treated as a <del> connection error of type "HTTP_QPACK_DECODER_STREAM_ERROR". </del> <ins> connection error of type QPACK_DECODER_STREAM_ERROR. </ins> The Header Acknowledgement instruction might increase the Known Received Count; see known-received-count.

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
RFC7540 provide some further advice on mitigations within an HTTP/2 context. <ins> The HTTPS connection also authenticates the DNS API server but does not inherently assure of authenticity of DNS data.  A DNS API client may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recurvise DNS resolver.  A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server. </ins> [[ From the WG charter: The working group will analyze the security and privacy issues that

Discussion:
Separate out confidentiality and authentication - -01 said "Running DNS over HTTPS relies on the security of the underlying HTTP connection." This PR clarifies that the HTTPS connection can only provide confidentiality and authentication of the DNS API server. Clients wanting authentic DNS answers need to perform DNSSEC validation or explicitly trust the DNS API server.
I reverted this because my comment above was not satisfied before merge.
pr did some of this but was backed out. see that diff and discussion
I agree with the notion of separating transport security from e2e validation.. but I think the changes overshoot a touch. I would leave the first paragraph alone - https provides more than confidentiality and I don't think the text suggests anything other than doh relies on https. I like your second paragraph - though if we leave the first one in tact you probably want to remove the "also authenticates" part.. it can be recast as transport security between api server and client vs e2e validation
Change:
matching capability, i.e., testing whether a given regexp matches a given piece of text. <ins> I-Regexp supports the entire repertoire of Unicode characters. </ins> I-Regexp is a subset of XSD regexps XSD-2. This document includes rules for converting I-Regexps for use with

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:
these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). <del> 11.2. </del> <ins> 11.3. </ins> The http-01, and dns-01 validation methods mandate the usage of a random token value to uniquely identify the challenge.  The value of

Discussion:
Thanks for the comments NAME I've updated the PR to address.
There has been list discussion on this PR and consensus is positive. I'm going to merge this now that NAME has addressed the feedback provided.
LGTM :rocket:
Change:
values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. <ins> Finally, this document obsoletes a registry originally created in RFC5246.  IANA [shall/has] updated it to list values 7-223 as "Reserved". </ins>

Discussion:
It has been replaced by SignatureScheme which assumes that no more HashAlgorithms will ever be allocated. Future allocations will go in SignatureScheme. Closes issue .
(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:
The Header Acknowledgement and Stream Cancellation instructions permit the encoder to remove references to entries in the dynamic table.  When an entry with absolute index lower than the Known <del> Received Count has zero references, then it is no longer considered blocking (see blocked-insertion). </del> <ins> Received Count has zero references, then it is considered evictable (see blocked-insertion). </ins> 2.2.2.3.

Discussion:
Acting on NAME suggestion.
Thank you, this greatly improves clarity.
Technically, all reviews request rather than require. Those are good suggestions, though.
Incorporated, though the parenthetical reads even more awkwardly now. Suggestions on improving that (or consensus to drop it) are welcome.
This review suggests changes, not "requires" them.
Change:
ACME uses different URIs for different management functions.  Each function is listed in a directory along with its corresponding URI, <del> so clients only need to be configured with the directory URI. </del> <ins> so clients only need to be configured with the directory URI.  These URIs are connected by a few different link relations RFC5988. </ins> The "up" link relation is used with challenge resources to indicate the authorization resource to which a challenge belongs.  It is also

Discussion:
Since the rest of the spec and protocol makes extensive use of JSON, when I was reading the spec the first time, I didn't know if the link relations were supposed to be JSON link relations like HAL or LinkedData. The spec mentions "link relation" 6 times, but only one of them (the 2nd-to-last) makes explicit reference to RFC 5988 for web linking via HTTP header.