jiebi/CodeConvo huggingface dataset:
Change:
server is located.  (If it is empty or not given, then the default port 5683 is assumed, as with UDP.) <del> 6.2. </del> <ins> 4.1.2. </ins> The semantics defined in RFC7252, Section 6.2, apply to this URI scheme, with the following changes:

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
7.1. <del> If a path has been verified to support ECN (RFC3168, RFC8311), QUIC </del> <ins> If a path has been validated to support ECN (RFC3168, RFC8311), QUIC </ins> treats a Congestion Experienced (CE) codepoint in the IP header as a signal of congestion.  This document specifies an endpoint's response when its peer receives packets with the ECN-CE codepoint.

Discussion:
URL verified. Consistency in terms helps.
mentions /verification/ of ECN but defines /validation/ of ECN.: In section 9.2: the term /verify/ is used 3 times, but not explained: /verifies ECN capability/ and /verifies ECN support/ should these both be /validates ECN support/ ? … ALSO is there a difference between ECN support and ECN capability? - I didn’t expect a subtle difference, can we use one set of words instead? (and sorry if I compounded any confusion in the terms...)
Change:
Template: <del> Field name: The string to be used as a key in the JSON object </del> <ins> Field name: The string to be used as a field name in the JSON object </ins> Field type: The type of value to be provided, e.g., string, boolean, array of string

Discussion:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.
Change:
A unique index for each entry in the dynamic table. <del> A reference point for relative indices.  Dynamic references are made relative to a Base in header blocks. </del> <ins> A reference point for relative and post-base indices.  References to dynamic table entries in header blocks are relative to a Base. </ins> The total number of entries inserted in the dynamic table.

Discussion:
Since post-base index has a section separate from relative index, I do not consider post-base index a type of relative index, but a distinct category. Update text accordingly. If the consensus is that this is not the case, relative index and post-base index sections should be reworded, and a new term should be introduced for non-post-base relative index.
Change:
On the first received ACK_FREQUENCY frame in a connection, an endpoint MUST immediately record all values from the frame.  The sequence number of the frame is recorded as the largest seen sequence <del> number.  The new Ack-Eliciting Threshold and Update Max Ack Delay </del> <ins> number.  The new Ack-Eliciting Threshold and Request Max Ack Delay </ins> values MUST be immediately used for delaying acknowledgements; see sending.

Discussion:
Fixes the remainder of not fixed by
This is good enough. You have a conflict to resolve, but let's merge this.
Change:
The message can also contain the following OPTIONAL parameters: <del> A "audience" element containing a suggested audience that the client should request at the AS (see audience for a discussion of this parameter). </del> <ins> A "audience" element contains an identifier the client should request at the AS, as suggested by the RS.  With this parameter, when included in the access token request to the AS, the AS is able to restrict the use of access token to specific RSs.  See audience for a discussion of this parameter. </ins> A "kid" element containing the key identifier of a key used in an existing security association between the client and the RS.  The

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
Upon receiving the client's Initial packet, the server can request address validation by sending a Retry packet (packet-retry) containing a token.  This token MUST be repeated by the client in all <del> Initial packets it sends after it receives the Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </del> <ins> Initial packets it sends for that connection after it receives the Retry packet.  In response to processing an Initial containing a token, a server can either abort the connection or permit it to proceed. </ins> As long as it is not possible for an attacker to generate a valid token for its own address (see token-integrity) and the client is

Discussion:
Although not super-important, the biggest decision in here is that the packet number of the response to a RETRY is 1. Based on interop experience, I believe this is the semi-consensus of implementers.
Should there be normative text mandating that the packet number be increased?
I think we need a new issue on that. The information about this is scattered around issuing CID's, path validation, retransmission of Initial. It would be good with a clear statement of when the packet number starts counting. I also believe that there is somewhere text to the effect that a CID cannot have the same PN twice, but that does not apply to Retry.
Change:
<del> If the request from the client is successful (i.e. correct and authorized), the AS returns an access token and optionally a refresh token (note that only certain grant types support refresh tokens).  It can also return additional parameters, referred to as "Access Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP access token extension, this framework defines parameters that can be used to inform the client about capabilities of the RS, e.g.  the profile the RS supports. More information about these parameters can be found in tokenParams. </del> <ins> If the request from the client has been successfully verified, authenticated, and authorized, the AS returns an access token and optionally a refresh token.  Note that only certain grant types support refresh tokens.  The AS can also return additional parameters, referred to as "Access Information".  In addition to the response parameters defined by OAuth 2.0 and the PoP access token extension, this framework defines parameters that can be used to inform the client about capabilities of the RS, e.g.  the profile the RS supports.  More information about these parameters can be found in tokenParams. </ins>

Discussion:
This terminology decision was made in early days of OAuth = long time ago. Done. Done. Changed. I added a note that this confidentiality protection of the access token happens on top of the protection offered by the underlying communication security protocol. Text added. >-- Section 5 -- Text changed. >-- Section 5.1.1 -- >Could the word "unprotected" be better defined in "received on an unprotected channel" ? E.g., is it only about TLS ? Else, I like the implicit lack of trust. Text changed to "unsecured channel" >-- Section 5.1.2 -- I assume you mean "Section 5.3". Text added. >-- Section 5.5 -- >In "Since it requires the use of a user agent (i.e., browser)" is it "i.e." or "e.g." ? I cannot find this text in the document. >-- Section 5.6 -- OK OK. >-- Section 5.6.4.1 -- >In figure 11, would you mind adding the section ID in addition to RFC 6749 ? I failed to spot them in RFC 6749. Done. >-- Section 5.7.2 -- >It is a little unclear to me which profile must be used as 'profile' is optionnial? Should a default or any profile be used ? I cannot find this text. >-- Section 5.8.1 -- >Suggest to use the BCP14 "SHOULD" in the text "The default name of this endpoint in an url-path is '/authz-info'" Changed. >-- Section 10.2 -- >Is RFC 7049 really an informative reference as CBOR appears as the default encoding ? Changed to a normative reference and updated reference. All nits below have been addressed.
Comments addressed in this PR: URL
Merged
Change:
This specification defines the KeyPurposeId id-kp-documentSigning. <del> As described in RFC5280, If the Extended Key Usage extension is </del> <ins> As described in RFC5280, "[i]f the [Extended Key Usage] extension is </ins> present, then the certificate MUST only be used for one of the <del> purposes indicated.  RFC5280 also describes that If multiple key purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. </del> <ins> purposes indicated."  RFC5280 also describes that "[i]f multiple [key] purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present." </ins> Document Signing applications MAY require that the Extended Key Usage extension be present and that the id-kp-documentSigning be indicated

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
queries for "resolver.arpa" to the unencrypted DNS server indicated by the network over DHCP or RAs, and the DNR indications SHOULD take precedence over those discovered using "resolver.arpa" for the same <del> resolver if there is a conflict. </del> <ins> resolver if there is a conflict, since DNR is considered a more reliable source. </ins> The designated resolver information in DNR might not contain a full set of SvcParams needed to connect to an encrypted DNS resolver.  In

Discussion:
NAME please check!
I think there are way too many bald SHOULDs in this document. Since SHOULD presents an implementer with a choice, it's usually a good idea to describe that choice rather than presenting something that looks like "you really should do this, but it's probably fine if you don't" and moves on. To wit: An example of one that could use improvement is the first one in Section 4, as I've no idea why you would not always do what it says. An example of one that does provide such guidance is the second one in Section 4, where I understand the consequences of not doing what it says.
LGTM!
Change:
Once an endpoint successfully receives a packet with a given packet number, it MUST discard all packets in the same packet number space with higher packet numbers if they cannot be successfully unprotected <del> with either the same key, or - if there is a key update - the next packet protection key (see key-update).  Similarly, a packet that appears to trigger a key update, but cannot be unprotected successfully MUST be discarded. </del> <ins> with either the same key, or - if there is a key update - a subsequent packet protection key; see key-update.  Similarly, a packet that appears to trigger a key update, but cannot be unprotected successfully MUST be discarded. </ins> Failure to unprotect a packet does not necessarily indicate the existence of a protocol error in a peer or an attack.  The truncated

Discussion:
This is a little pedantic, but it's more correct. Also fix reference format.
NAME said:
Change:
Config.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: <del> [TODO: Decide whether to use the same config structure as OHTTP/ECH. This would add support for multiple cipher suites.] </del> <ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).] </ins> The client issues a key configuration request to "Param.leader_url" and "Param.helper_url".  It aborts if any of the following happen for

Discussion:
It seems silly to have clients revalidating the HPKE key for each request, so we probably want some kind of caching. I'm not sure HTTP Caching is quite what we want, but something... NAME NAME recommendations?
I'm going to need a little more context to provide good advice. If we don't need key consistency (it doesn't appear so) and you only need correctness, then the client should just be able to talk directly to the collector and get keys periodically. HTTP caching works fine for that purpose. This would also need a rejection message so that the collector (or the leader on their behalf - the leader is more likely to learn about bad key identifiers before clients) can reject an out-of-date key in case the cache needs to be invalidated.
We do not need key consistency. The rejection message seems like a good idea.
Change:
rebinding leads to connection failure, with the resulting cost of a new handshake. <del> This document defines an extension to DTLS to add a connection ID (CID) to the DTLS record layer.  The presence of the connection ID is negotiated via a DTLS extension. </del> <ins> This document defines an extension to DTLS 1.2 to add a CID to the DTLS record layer.  The presence of the CID is negotiated via a DTLS extension. </ins> 2.

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
to continue. Sent by a server in response to an invalid connection retry <del> attempt from a client. (see [RFC7507]) </del> <ins> attempt from a client RFC7507. </ins> Sent by endpoints that receive a hello message not containing an extension that is mandatory to send for the offered TLS version or

Discussion:
Most of these are simple enough, kramdown treats all bracketed text as a reference. So these can be replaced with and the warnings go away. The biggest change here is slightly stylistic: a few places had , which kramdown complained about, but rendered correctly. However, this produced a non-sentence. Also, I fixed some inconsistent use of references and s/data/date in one of the references.
See comment
Change:
_who_ "hosts" something. In link-format serialization, it is expressed in the "anchor" <del> attribute.  There, it can be a relative reference, in which case it gets resolved against the URI of the ".well-known/core" document it was obtained from.  It defaults to that document's URI. </del> <ins> attribute.  It defaults to that document's URI. </ins> A link target URI: It defines the destination of the relation (eg. _what_ is hosted), and is the topic of all target attributes.

Discussion:
This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.
Change:
service using the described technique.  This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. <del> This can used to reduce the secrecy for push subscription URLs by </del> <ins> This can be used to reduce the secrecy for push subscription URLs by </ins> being able to restrict subscriptions to a specific application server.  An application server is further able to include additional information that the operator of a push service can use to contact

Discussion:
These are some suggested fixes for some nits that came up from the Shepherd write-up review.
Change:
On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: <ins> Validate the POST request belongs to a currently active account, as described in Message Transport. </ins> Check that the payload of the JWS is a well-formed JWS object (the "inner JWS") Check that the JWS protected header of the inner JWS has a "jwk" <del> field containing a key that matches a currently active account </del> <ins> field. </ins> Check that the inner JWS verifies using the key in its "jwk" field

Discussion:
Signing with the current account key allows servers to use the same message transport authentication that they use for other requests, simplifying the verification. Also fix two spots where we still described newKey/oldKey as thumbprints.
LGTM. I had only done that signing order to be forward-compatible with some imagined future recovery scheme, but if we decide to do that someday, that patch can differ in signature order as well as whatever else.
Change:
ACME messaging is based on HTTPS RFC2818 and JSON RFC7159. <del> Binary fields are encoded using Base64url encoding described in </del> <ins> Binary fields are encoded using base64url encoding described in </ins> RFC4648 Section 5, according to the profile specified in JSON Web Signature RFC7515 Section 2.  This encoding uses a URL safe character set.  Trailing '=' characters MUST be stripped.

Discussion:
The current draft stipulates Base64 encoding without padding in relation to JSON data. It is unclear whether omitting the padding characters also applies to the Base64url encoding of key authorization resources (which are not JSON objects). To avoid ambiguity with regards to the encoding of the key authorization string (with padding / without padding) either specify "Base64url Encoding" in the terminology section or change the wording of the aforementioned provision so it is clear that the RFC7515 variant applies to any Base64 encoding throughout the spec. Reference: URL
Data for the discussion: boulder uses Base64url without padding (a.k.a. ) everywhere. (The DNS challenge deployed to boulder's staging instance was buggy, has been fixed in master, and is going to be deployed to again Real Soon Now)
Change:
and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol <del> RFC9000 as its transport layer.  QUIC relies only on the TLS 1.3 initial handshake for key exchange RFC9001, and encrypts almost all transport parameters, with the exception of a few invariant fields. In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the destination connection ID RFC8999.  For </del> <ins> RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself, with the exception of a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination Connection ID, and Source Connection ID.  For </ins> these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

Discussion:
I did add a few paragraphs of text, but don't expect it to be too controversial. Any thoughts?
Needs to be edited and possibly some text migrated.
Change:
precedence from highest (binds most tightly) to lowest (binds least tightly). <del> 3.5.9.2. </del> <ins> 3.5.8.2. </ins> The "filter-selector" works with arrays and objects exclusively.  Its result might be a list of

Discussion:
To do: [x] Consider reorganising selectors in section 3.3 to match the order of the document [x] Consider reorganising table 1 to match the order of the document Fixes URL
Reorganised selectors in section 3.3 to match the order of the document. Did not reorganise table 1 as it flows better as is.
Filter selectors should come before list selectors to avoid a forward reference. The following comment should be deleted: Also, as noted by NAME at today's interim WG meeting, we should factor out a separate production to avoid repeating here: and here: Possible names for this production: or .
I think we proposed something like ... and here: thanks.
(And once we are don't with this issue, we can reorder table 1. Not quite sure if we want to do this entirely in section order; let's see how that turns out first.)
Change:
with payload in CBOR diagnostic notation without the tag and value abbreviations. <ins> As specified in section 5.8.3 of I-D.ietf-ace-oauth-authz, the RS must notify the client with an error response with code 4.01 (Unauthorized) for any long running request before terminating the session, when the access token expires. If the RS receives the token in a OSCORE protected message, it means that the client is requesting an update of access rights.  The RS MUST discard any nonce in the request, if any was sent.  The RS MUST check that the "kid" of the "cnf" parameter of the new access token matches the OSCORE Security Context used to protect the message.  If that's the case, the RS MUST discard the old token and associate the new token to the Security Context identified by "kid".  The RS MUST respond with a 2.01 (Created) response protected with the same Security Context, with no payload.  If any verification fails, the RS MUST respond with a 4.01 (Unauthorized) error response. </ins> As specified in section 5.8.1 of I-D.ietf-ace-oauth-authz, when receiving an updated access token with updated authorization information from the client (see c-as), it is recommended that the RS

Discussion:
OCF comments.
check that re-sending token triggers nonces exchange and new security context derived.
add a implementation note about namespaces for identifiers in case several methods are used (EDHOC, ACE, others)