jiebi/CodeConvo huggingface dataset:
Change:
In the example above, the response parameter "AS" points the receiver of this message to the URI "coaps://as.example.com/token" to request <del> access tokens.  The RS sending this response (i.e., RS) uses an internal clock that is not synchronized with the clock of the AS. Therefore it can not reliably verify the expiration time of access tokens it receives.  To ensure a certain level of access token freshness nevertheless, the RS has included a "cnonce" parameter (see cnonceParam) in the response. </del> <ins> access tokens.  The RS sending this response uses an internal clock that is not synchronized with the clock of the AS.  Therefore, it can not reliably verify the expiration time of access tokens it receives. To ensure a certain level of access token freshness nevertheless, the RS has included a "cnonce" parameter (see cnonceParam) in the response.  (The hex-sequence of the cnonce parameter is encoded in CBOR-based notation in this example.) </ins> fig:as-info-cbor illustrates the mandatory to use binary encoding of the message payload shown in fig:as-info-payload.

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:
2. <del> The request/response interaction model of CoAP TCP/TLS is the same as CoAP UDP.  The primary differences are in the message layer.  CoAP UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgement, and Reset.  TCP eliminates the need for the message layer to support reliability.  As a result, message types are not defined in CoAP TCP/TLS. </del> <ins> The request/response interaction model of CoAP over TCP is the same as CoAP over UDP.  The primary differences are in the message layer. CoAP over UDP supports optional reliability by defining four types of messages: Confirmable, Non-confirmable, Acknowledgement, and Reset. TCP eliminates the need for the message layer to support reliability. As a result, message types are not defined in CoAP over TCP. </ins> 2.1. <del> Conceptually, CoAP TCP/TLS replaces most of the CoAP UDP message layer with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that on datagram transports is provided by the UDP/DTLS datagram layer. </del> <ins> Conceptually, CoAP over TCP replaces most of the CoAP over UDP message layer with a framing mechanism on top of the byte stream provided by TCP/TLS, conveying the length information for each message that on datagram transports is provided by the UDP/DTLS datagram layer. </ins> <del> TCP ensures reliable message transmission, so the CoAP TCP/TLS </del> <ins> TCP ensures reliable message transmission, so the CoAP over TCP </ins> messaging layer is not required to support acknowledgements or detection of duplicate messages.  As a result, both the Type and Message ID fields are no longer required and are removed from the

Discussion:
I'm finding "CoAP over protocol" to be too verbose - especially in text that references or compares multiple protocol bindings. Can we agree on a shorthand? CoAP protocol such as CoAP UDP, CoAP TCP/TLS, CoAP WebSockets CoAP+protocol such as CoAP+UDP, CoAP+TCP/TLS, CoAP+WebSockets
The URI scheme component provides a reasonably good shorthand form to reflect the protocol bindings and the "Terminology" section could perhaps reflect that? It would be approximately lead to something like the following text: In this document, references to the various transport bindings for conveying CoAP messages adopt the following abbreviations: CoAP+TCP refers to CoAP over TCP, and CoAP+WS refers to CoAP over WebSockets. Using "CoAPS+" instead of "CoAP+" implies the use of their corresponding TLS-based secure counterparts. CoAP and CoAPS refer to CoAP over UDP and CoAP over DTLS, respectively.
Change:
The true content type is inside the encryption envelope, as described below. <del> When CID is being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </del> <ins> When CIDs are being used, the content to be sent is first wrapped along with the true content type and padding into a DTLSInnerPlaintext value prior to encryption.  The DTLSInnerPlaintext value is then encrypted. dtls-record12 illustrates the record format. </ins> This field contains the byte encoding of a handshake, an alert message, or the raw bytes of the application's data to send.

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:
authorization token. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included in the </del> <ins> Range of 1-4294967295.  If no lifetime is included in the </ins> initial registration, a default value of 90000 (25 hours) SHOULD be assumed.

Discussion:
Not setting to 0 as this would require further explanation on what it means, and also leaves the 0 value usable as a sentinel in implementations for "no lt given" (although the same, with -1, could be achieved by reducing the range at the top end). Closes: URL
Feedback from LwM2M: Their testing takes long with the arbitrary limit of 60s. We found no technical reasons to keep it there, and it should probably be abolished in favor of the natural lower limit of 1 second.
Change:
The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the <del> Connection ID is present and what length it has. </del> <ins> Connection ID is present and what length it has.  However, Connection IDs may be renegotiated during a connection, and this renegotiation is not visible to the path.  Keying state off the Connection ID may therefore cause undetectable and unrecoverable loss of state in the middle of a connection.  Use of Connection ID specifically discouraged for NAT applications. </ins> 4.2.

Discussion:
At Gorry's suggestion I put the NAT guidance into a different draft: URL Sorry, I thought the notification went out automatically. Regardless, this change is fine.
The manageability draft should talk a little bit about NATS for QUIC. The laziest thing to do is just continue to have NAT mapping be by 4-tuple, as it is today. This is actually fine. However, someone might attempt to be clever and use the CID as well. For example, client A and client B could share the same serverside address and port and the NAT can initially distinguish between the two because they have different CIDs. This appears to save address space, but doesn't actually work because the server could switch to a new client connection ID. In this case, the NAT won't be able to determine which client to route to.
I think it's also worth mentioning that using just the CID only is similarly broken, the fundamental underlying concept here is that subsequent CIDs are exchanged in a manner that the NAT cannot see -- the only time it's okay to use CIDs is if you're colluding with one of the endpoints, as in QUIC LB.
At least recommend to use longer binding lifetimes for identified QUIC connections?
See PR
Fixed in this doc by
Looks good to me. It might be worth adding a bit more (see my detailed comment).
Change:
mode, the client and servers MUST supply "key_share" values as described in key-share. <del> PskAuthenticationModes have the following meanings: </del> <ins> PskAuthenticationMode values have the following meanings: </ins> PSK-only authentication.  In this mode, the server MUST NOT supply either a Certificate or CertificateVerify message.  [TODO: Add a

Discussion:
The PskKeMode and PskAuthMode types were not defined, substitute them by the defined enums. Use non-plural enum names for consistency with other enumeration types. Remove the old opaque psk_identity type in favor of PskIdentity which was otherwise unused. Increase minimum length from 2 to 4 to account for the PskIdentity.identity field length.
Change:
algorithm described above. The recipient SHOULD verify that the received public keys agree <del> with the public keys derived from the new node_secret values. </del> <ins> with the public keys derived from the new path_secret values. </ins> Merge the updated path secrets into the tree.

Discussion:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.
Change:
To prevent disclosure of the host IP address to a TURN server, the ICE agent MUST NOT form candidate pairs between its own relay <del> candidates and remote mDNS candidates.  Note that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </del> <ins> candidates and remote mDNS candidates.  This restriction must not be limited to remote mDNS candidates of a specific candidate type, typically host, as mDNS candidates are identified from their connection-address fields.  their connection-address field.  Note also that the converse is not an issue; the ICE agent MAY form candidate pairs between its own mDNS candidates and remote relay candidates, as in this situation host IPs will not be sent directly to the TURN server. </ins> This restriction has no effect on connectivity; in the cases where host IP addresses are private and need to be wrapped with mDNS names,

Discussion:
Fixes URL
It is required not to pair local relay candidates with remote mDNS candidates to avoid the leak via CreatePermission requests. As Phillip points in this issue (URL), an ICE agent should not rely on the candidate type field in a hostname candidate to reinforce this constraint. The a=candidate line in signaling can be modified to inject an arbitrary type. Suggest that we clarify the remote mDNS candidates include all hostname candidates with the .local pseudo-TLD.
Seems reasonable. The text does not restrict to "typ host", but being extra specific here would still be a good idea. Phillip also points out that we may want to do this for all DNS names, to prevent the browser from becoming a roundabout DNS resolver, but that is probably outside the scope of this document.
Change:
4.1.2. Preconnection: A Preconnection object is a representation of a <del> potential Connection.  It has state that describes parameters of a Connection that might exist in the future: the Local Endpoint from </del> <ins> Connection that has not yet been established.  It has state that describes parameters of the Connection: the Local Endpoint from </ins> which that Connection will be established, the Remote Endpoint (preestablishment) to which it will connect, and Transport Properties that influence the paths and protocols a Connection <del> will use.  A Preconnection can be fully specified such that it represents a single possible Connection, or it can be partially specified such that it represents a family of possible Connections.  The Local Endpoint (preestablishment) is required if the Preconnection is used to Listen for incoming Connections.  The Local Endpoint is optional if it is used to Initiate Connections. The Remote Endpoint is required in the Preconnection that is used to Initiate Connections.  The Remote Endpoint is optional if it is used to Listen for incoming Connections.  The Local Endpoint and the Remote Endpoint are both required if a peer-to-peer Rendezvous is to occur based on the Preconnection. </del> <ins> will use.  A Preconnection can be either fully specified (representing a single possible Connection), or it can be partially specified (representing a family of possible Connections).  The Local Endpoint (preestablishment) is required for a Preconnection used to Listen for incoming Connections, but optional if it is used to Initiate a Connection.  The Remote Endpoint is required in a Preconnection that used to Initiate a Connection, but is optional if it is used to Listen for incoming Connections.  The Local Endpoint and the Remote Endpoint are both required if a peer-to-peer Rendezvous is to occur based on the Preconnection. </ins> Transport Properties: Transport Properties allow the application to express their requirements, prohibitions, and preferences and

Discussion:
Gorry's attempt to improve preconnection ()
The big paragraph that is the first bullet of section 4.1.2 doesn't read well. Pleas consider restructuring it, and simplifying the sentences as much as possible.
I think this reads better
Change:
Issuers MUST provide two parameters for configuration: <del> Issuer Request URI: A token request URL for generating access </del> <ins> Issuer Request URL: A token request URL for generating access </ins> tokens.  For example, an Issuer URL might be <del> https://issuer.example.net/request.  This parameter uses resource media type "text/plain". </del> <ins> https://issuer.example.net/request. </ins> Issuer Public Key values: A list of Issuer Public Keys for the issuance protocol.

Discussion:
Are the changes to other files on this one intentional NAME ?
Oh, hrm, no, they're not. I'll remove them.
NAME fixed!
There are several related issues in URL Should the well-known location require mTLS? The two well-known public implementations previously highlighted by Apple disagree on this point. Our opinion: mTLS should not be required for the token issuer directory. is underspecified. Should this be an absolute URI, a relative URI, or allow either format? Our opinion: We prefer relative URIs, and think either option should be supported. A relative URI is also used by at least one well-known public implementation.
No. That's deployment specific decision. Either is fine, as evidenced by current implementations. We'll make this clear.
Since this URI is intended to be used as a URL later in the protocol -- and the description in fact calls it a URL -- would it be cleaner to name the parameter "Issuer Request URL"/? What "thing" is actually ? The directory itself is , the resulting content is JSON (whose strings do not carry a notion of media types), and the token request/response using this URI use /.
I think just dropping the media type mention at all is probably best here. It's just a URL string, so let's just call it that. Does work for you?
That looks much better. Should the parameter also be ?
Change:
DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" <del> parameter.  For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </del> <ins> parameter.  For example, if a DoH resolver provides a filtering service for one URI path, and a non-filtered service for another URI path, an attacker could select which of these services is used by modifying the "dohpath" parameter.  These attacks can be mitigated by providing separate resolver IP addresses or hostnames. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such

Discussion:
Thanks for the painless read! Just a few trivial comments. Minor: The editorial commentary in the IANA Considerations section seems out of place -- generally IANA Considerations is, well, requests to IANA, not interesting and fun trivia about the resources being requested. But, IANA are smart enough to disregard the superflous material. Nits: , The client can still use others records in the same response s/others/other/ , provides provides s/provides//
Change:
If an authenticator request is present, the extensions used to guide the construction of these messages are taken from the authenticator <del> request.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request.  In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </del> <ins> request.  If the certificate_request_context from the authenticator request has already been used in the connection, then no authenticator should be constructed.  If there is no authenticator request, the extensions are chosen from the TLS handshake.  Only servers can provide an authenticator without a corresponding request. In such cases, ClientHello extensions are used to determine permissible extensions in the Certificate message. </ins> 4.2.1.

Discussion:
NAME The crc can be derived in two places: the authenticator request and the unsolicited authenticator. I want to make sure the requirement is clear in both places.
Issue raised by Jonathan Hoyland at IETF 102
So you just wanted to repeat the requirement? Because that first bit already said no repeats.
Change:
Structure definitions may be embedded.  Anonymous structs may also be defined inside other structures. <del> 3.6.1. </del> <ins> 3.7. Fields and variables may be assigned a fixed value using "=", as in: 3.7.1. </ins> Defined structures may have variants based on some knowledge that is available within the environment.  The selector must be an enumerated

Discussion:
The caveats at the beginning are silly We don't seem to every use Foo = { A, B} but we do use Foo = A;
Fixed, thanks
Change:
On receiving a delegated credential and a certificate chain, the peer validates the certificate chain and matches the end-entity <del> certificate to the peer's expected identity.  It also takes the following steps: Validate that DelegatedCredential.cred.valid_time is no more than 7 days. </del> <ins> certificate to the peer's expected identity.  It then performs the following checks with expiry time set to the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time: </ins> Verify that the current time is within the validity interval of the credential.  This is done by asserting that the current time <del> is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time. Verify that the delegated credential's remaining validity time is no more than the maximum validity period.  This is done by asserting that the current time is no more than the delegation certificate's notBefore value plus DelegatedCredential.cred.valid_time plus the maximum validity period. </del> <ins> does not exceed the expiry time. Verify that the delegated credential's remaining validity period is no more than the maximum validity period.  This is done by asserting that the expiry time does not exceed the current time plus the maximum validity period (7 days). </ins> Verify that expected_cert_verify_algorithm matches the scheme indicated in the peer's CertificateVerify message and that the

Discussion:
Update the condition for validating a DC to the following: now() <= notBefore + valid_time <= now() + 7d
LGTM % nit
Change:
eliciting packets after which the receiver sends an acknowledgement.  A value of 1 will result in an acknowledgement being sent for every ack-eliciting packet received.  A value of 0 <del> is invalid. </del> <ins> is invalid.  Receipt of an invalid value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> A variable-length integer representing an update to the peer's "max_ack_delay" transport parameter (Section 18.2 of QUIC- TRANSPORT).  The value of this field is in microseconds.  Any value smaller than the "min_ack_delay" advertised by this endpoint <del> is invalid. </del> <ins> is invalid.  Receipt of an invalid value MUST be treated as a connection error of type PROTOCOL_VIOLATION. </ins> An 8-bit field representing a boolean truth value.  This field MUST have the value 0x00 (representing "false") or 0x01 (representing "true").  This field can be set to "true" by an endpoint that does not wish to receive an immediate acknowledgement when the peer observes reordering (reordering). <del> Receipt of invalid values in an ACK_FREQUENCY frame MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </del> <ins> Receipt of any other value MUST be treated as a connection error of type FRAME_ENCODING_ERROR. </ins> ACK_FREQUENCY frames are ack-eliciting.  However, their loss does not require retransmission if an ACK_FREQUENCY frame with a larger

Discussion:
At the moment, the specification requires the use of FRAMEENCODINGERROR when an endpoint receives an ACKFREQUENCY frame with the value of Update Max Ack Delay field being smaller than . That contradicts from the practice of the core draft, that restricts the use of FRAMEENCODINGERROR to syntactic (i.e. encoding) errors. This PR fixes the problem by changing the error code to be used in that case to PROTOCOLVIOLATION.
Change:
6. <del> This document registers the "delegated_credentials" extension in the "TLS ExtensionType Values" registry.  The "delegated_credentials" </del> <ins> This document registers the "delegated_credential" extension in the "TLS ExtensionType Values" registry.  The "delegated_credential" </ins> extension has been assigned a code point of 34.  The IANA registry lists this extension as "Recommended" (i.e., "Y") and indicates that it may appear in the ClientHello (CH), CertificateRequest (CR), or <del> Certificate (CT) messages in (D)TLS 1.3 RFC8446 ID.ietf-tls-dtls13. </del> <ins> Certificate (CT) messages in (D)TLS 1.3 RFC8446 I-D.ietf-tls-dtls13. </ins> Additionally, the "DTLS-Only" column is assigned the value "N". This document also defines an ASN.1 module for the DelegationUsage

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.