jiebi/CodeConvo huggingface dataset:
Change:
If the corresponding certificate type extension ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was <del> negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> negotiated, then each CertificateEntry contains a DER-encoded X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,

Discussion:
Without specifying the encoding, I don't think it's actually defined how you transit the certificates. RFC 5280 only says that the TBSCertificate is DER-encoded for computing the signature, which still allows insanity like XER-encoded everything with the receiver re-encoding the TBSCertificate to DER before verifying the signature.
Change:
7.3.1. This method is indicated by "jwsd" in the "proof" field.  A JWS <del> RFC7515 signature object is created as follows: </del> <ins> RFC7515 object is created as follows: </ins> <del> The header of the JWS MUST contain the "kid" field of the key bound to this client instance for this request.  The JWS header MUST contain an "alg" field appropriate for the key identified by kid and MUST NOT be "none".  The "b64" field MUST be set to "false" and the "crit" field MUST contain at least "b64" as specified in </del> <ins> The JOSE (JSON Object Signing and Encryption) header MUST contain the "kid" parameter of the key bound to this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none".  The "b64" parameter MUST be set to "false" and the "crit" parameter MUST contain at least "b64" as specified in RFC7797. </ins> <del> To protect the request, the JWS header MUST contain the following additional fields. </del> <ins> To protect the request, the JOSE header MUST contain the following additional parameters. </ins> The HTTP Method used to make this request, as an uppercase ASCII string.

Discussion:
These changes replace with replace with replace with in Detached JWS and Attached JWS sections.
Deploy preview for gnap-core-protocol-editors-draft ready! Built with commit df67d81f6aadce526a2eecb1d9185d684f17242c https://deploy-preview-207--gnap-core-protocol-editors-URL
I think the proposal in could have some impact on this language, as well as making sure both attached and detached JWS methods are fully aligned.
could definitely have some impact. Although, these changes touch only the used terminology.
Accept to align with JOSE terminology, will probably be updated again when crypto methods get updated.
Change:
and outer keys. The protections with regard to the network are the same as with the <del> normal SRTP AES-GCM transforms. </del> <ins> normal SRTP AES-GCM transforms.  The major difference is that the double transforms are designed to work better in a group context.  In such contexts, it is important to note that because these transforms are symmetric, they do not protect against attacks within the group. Any member of the group can generate valid SRTP packets for any SSRC in use by the group. </ins> With regard to a malicious MD, the recipient can verify the integrity of the base header fields and confidentiality and integrity of the

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
4.2.1. Transport Properties are referred to by property names.  These names <del> are lower-case alphanumeric strings in which words may be separated by hyphens.  These names serve two purposes: </del> <ins> are alphanumeric strings in which words may be separated by hyphens. These names serve two purposes: </ins> Allowing different components of a TAPS implementation to pass Transport Properties, e.g., between a language frontend and a

Discussion:
This doesn't change the idea of translating keywords from the IANA protocol numbers registry to lower-case; it just removes the requirement for all Transport Property Names to be lower-case. Why? Right now, they're camlCase, and I guess that reads better than changing them all into hardtoreadstrings or using-hyphens-everywhere ...
Change:
the number of seconds until the quota resets. <del> The field value is </del> <ins> The field is an Integer Structured Field and its value is </ins> The delay-seconds format is used because:

Discussion:
uses structured fields based on NAME preliminary work: thanks!!!referencing the RFC distinguishing sf-item and sf-integer, since sf-integer do not support parameters whereas sf-item does retaining the intermediate syntaxes (quota-policy, quota-units, service-limit, ...)
LGTM, waiting on ack from NAME before merging.
NAME thanks for reviewing! Can we merge?
It's your draft :)
I take it for a YES :D
Since parameters are always allowed in Limit we could define a "registry" and add them subsequently as soon as implementers needs them. They can be used to specify: max throughputs request distribution other policies All data in parameters is informative.
I assume there must be previous art in keeping a registry like this that we can mimic, but I can't think of a good example off the top of my head that wouldn't be using a separate registry or document to manage that. What's your thinking about where to keep this registry?
NAME registries are usually maintained by IANA: we can check with NAME if that's possible...
We can pretty easily define a registry. You include a section in the RFC. See URL You define a table that is the registry, and meanings of the columns, and perhaps populate it with the initial entries. The WG decides some rules, like "X-" is left for experimentation. There must be something written (it can be an internet draft or something else on the net), whether a set of "experts" need to review for comliance and clarity, and so on.
If you'd like, I can make a PR that provides the initial text for this next week.
Yes, that would be great NAME
Can you give me an initial set of fields (even if it's just one or two), and an example, and a pointer to which section in the current draft? thanks.
Hi NAME Thanks for your support! To make best use of your time, I'd wait for to be merged (waiting for mnot's review) so you can PR directly vs . WRT the parameter registry: currently the initial set is just : See: URL Do you have a proposal for the registration policy?
Thanks, I'll wait. I think it should be expert review.

That means that there should be a document describing the parameter, and that the experts can be directed to verify that the documentation is clear and unambiguous, and that there is no significant overlap with the parameters already defined. The other choices are "specification required" and "first-come first-served."
NAME we just merged structured fields in RateLimit Headers!
Thanks for the ping, I saw :) I'll propose a PR soon.
URL I think it needs to be tweaked, since it's just defined as a "quota" registry in that PR. Should it be a ratelimit fields registry?
Change:
The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del> <ins> The value to be used in generation of validation certificate. This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to the challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The

Discussion:
(As part of closing out the letsencrypt/acme-spec repo.)
Change:
Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages <del> between local and remote systems.  It holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  This represents, for example, an active Connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </del> <ins> between local and remote systems.  It is an abstraction that represents the communication.  The Connection object holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  For example, an active Connection can represent a connection-oriented protocol such as TCP, or can represent a fully-specified 5-tuple for a connectionless protocol such as UDP, where the Connection remains an abstraction at the end points.  It can also represent a pool of transport protocol instances, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance.  Connections can be created from a Preconnection or by a Listener. </ins> Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding

Discussion:
Trying to with a hint upfront that connections can be UDP, TCP or any other transport protocol instance... and then later explain about a connection that can remain an abstraction at the end points for a UDP example.
The last bullet in the Overview is out of place - the others are an overview of the document, but this one is a description of a concept.
Change:
Distributor MUST NOT alone be interpreted as being authorized to have access to the E2E media encryption keys, as the Media Distributor does not have the ability to determine whether an endpoint is <del> authorized.  Trusted endpoint authorization is described in I- D.roach-perc-webrtc. </del> <ins> authorized.  Instead, the Key Distributor is responsible for authenticating endpoints (e.g., using WebRTC Identity I-D.ietf- rtcweb-security-arch) and determining their authorization to receive E2E media encryption keys. </ins> A Media Distributor MUST perform its role in properly forwarding media packets while taking measures to mitigate the adverse effects

Discussion:
This looks good to me
Minor nits “hadnshake” —> “handshake” “Each E2E key that an endpoint uses to receive SRTP media is set by receiving a Full EKT Field from another endpoints.” —> from other endpoints.
Change:
defined. The protocol must use a secure transport that meets the <del> requirements for modern HTTPS. </del> <ins> requirements for HTTPS. </ins> 4.1.

Discussion:
minor editoral changes
thanks for these. The only one that's a little iffy is the inclusion of the reason phrase for 415... but I think here its giving more explanatory value than an impression that particular phrase needs to be used (which wouldn't jibe with http details).
Change:
3.2. <del> Inputs: - "server_origin": The origin to retrieve a server </del> <ins> Inputs: - "server_origin": The origin to retrieve a Server </ins> configuration for. No outputs. <del> The client makes an anonymous GET request to </del> <ins> The Client makes an anonymous GET request to </ins> "CONFIG_ENDPOINT"/.well-known/privacy-pass with a message of type "fetch-config" and a body of: <del> The server looks up the configuration associated with the origin </del> <ins> The Server looks up the configuration associated with the origin </ins> "server_origin" and responds with a message of type "config" and a body of: <del> The client then stores the associated configuration state under </del> <ins> The Client then stores the associated configuration state under </ins> the corresponding "server_origin". (TODO: This might be mergable with key commitment retrieval if

Discussion:
cc NAME for review. Mainly just removing the interfaces that were previously present and using the API functions from the protocol directly. I've also changed some of the wording around the key registry, and replaced client -> Client and server -> Server. Let me know if there is anything that you think I've missed.
We currently have interfaces in the architecture document that lay out how messages should be sent and received. I think the architecture document should be solely focused on the building of the ecosystem in a way that maintains the utility of the privacy and security guarantees made by the protocol. The interfaces are mainly used by the HTTP API doc, and so I think this will be a better home for them.
I've removed the interfaces from the architecture doc () and used the protocol API directly in the HTTP doc ()
Change:
<del> Problem Details For CoAP APIs </del> <ins> Concise Problem Details For CoAP APIs </ins> draft-ietf-core-problem-details-latest Abstract This document defines a "problem detail" as a way to carry machine- <del> readable details of errors in a CoAP response to avoid the need to define new error response formats for CoAP APIs.  The proposed format is inspired by the Problem Details for HTTP APIs defined in RFC 7807. </del> <ins> readable details of errors in a REST response to avoid the need to define new error response formats for REST APIs.  The format is inspired by, but intended to be more concise than, the Problem Details for HTTP APIs defined in RFC 7807. </ins> 1. <del> CoAP RFC7252 response codes are sometimes not sufficient to convey enough information about an error to be helpful.  This specification defines a simple and extensible CoRAL I-D.ietf-core-coral vocabulary to suit this purpose.  It is designed to be reused by CoAP APIs, which can identify distinct "problem types" specific to their needs. Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using this vocabulary), as shown in fig-problem-details. </del> <ins> REST response status information such as CoAP response codes (RFC7252) is sometimes not sufficient to convey enough information about an error to be helpful.  This specification defines a simple and extensible framework to define CBOR STD94 data items to suit this purpose.  It is designed to be reused by REST APIs, which can identify distinct "problem types" specific to their needs.  Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using this vocabulary), as shown in fig-problem-details. </ins> <del> The vocabulary presented is largely inspired by the Problem Details for HTTP APIs defined in RFC7807. </del> <ins> The framework presented is largely inspired by the Problem Details for HTTP APIs defined in RFC7807.  comp7807 discusses applications where interworking with RFC7807 is required. </ins> 1.1.

Discussion:
This PR provides the write-up of the discussed at the interim. Note that it branches off Carsten's "bundled" PR ()
I did a little bit of editing. Comments welcome...
Change:
fragmented or dropped (RFC8085). If a QUIC endpoint determines that the PMTU between any pair of local <del> and remote IP addresses has fallen below the smallest allowed maximum </del> <ins> and remote IP addresses cannot support the smallest allowed maximum </ins> datagram size of 1200 bytes, it MUST immediately cease sending QUIC packets, except for those in PMTU probes or those containing CONNECTION_CLOSE frames, on the affected path.  An endpoint MAY

Discussion:
URL the path doesn't provide extra headroom. Includes some rewording of the text.
Éric Vyncke said:
We wanted some space for things like extension headers/options and maybe for tunnels. See which is in response to your peer Erik. And yeah, 1200 is a nice number.
Based on the discussion here and the linked issue, I don't think we need to do anything here.
Erik Kline said:
Seems reasonable to mention. Obviously many paths support a larger MTU and so will support more extensions (or options), but it's worth noting that there isn't a ton of space available.
Change:
functionalities through new issuance protocols.  Each issuance protocol SHOULD come with a detailed analysis of the privacy impacts of the extension, why these impacts are justified, and guidelines on <del> changes to the parametrization in parametrization.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </del> <ins> how to deploy the protocol to minimize any privacy impacts.  Any extension to the Privacy Pass protocol MUST adhere to the guidelines specified in issuer-role for managing Issuer public key data. </ins> 4.

Discussion:
After quickly skimming the parameterization section, it became clear that we already discuss these things in various consideration sections throughout the document, so this was just redundant. Moreover, it's very use-case and deployment specific that once had value in the joint deployment model, so it doesn't seem like particularly helpful now that we've generalized things a bit. Removing and avoiding confusion seems like the best path forward.
I'll take this one to the list before merging.
The privacy calculations should be updated to take into account metadata more explicitly, and take into account the cost of the number of redemptions, rather than the global issuer count. If used in a multiple disjoint architecture ecosystem, then the math should also be taken in terms of a specific 'context' rather than treating the whole PrivacyPass ecosystem as a single global system (allowing for more nuanced requirements/limitations on issuer counts).
On reflection, we may be better off deleting the text entirely and making sure the justification for the parameterization is adequately covered in the security and privacy considerations elsewhere in the document.
Change:
and structure of data that follows this integer is determined by the stream type. <del> Two stream types are defined in this document: control streams (control-streams) and (push-streams).  RFC9204 defines two additional stream types.  Other stream types can be defined by extensions to HTTP/3; see extensions for more details.  Some stream types are reserved (stream-grease). </del> <ins> Two stream types are defined in this document: (control-streams) and (push-streams).  RFC9204 defines two additional stream types.  Other stream types can be defined by extensions to HTTP/3; see extensions for more details.  Some stream types are reserved (stream-grease). </ins> The performance of HTTP/3 connections in the early phase of their lifetime is sensitive to the creation and exchange of data on

Discussion:
NAME was helpful enough to show me how to do this in URL, so now singular and plural versions of the same term are a single index entry.
Change:
See COSE for more examples. <ins> 3.5.3.1. To comply with the LAKE message size requirements, see I-D.ietf-lake- reqs, two optimizations are made for the case when ID_CRED_x contains a single 'kid' parameter. The CBOR map { 4 : kid_x } is replaced by the byte string kid_x. The representation of identifiers specified in bstr-repr is applied to kid_x. These optimizations MUST be applied if and only if ID_CRED_x = { 4 : kid_x } and ID_CRED_x in PLAINTEXT_y of message_y, y = 2 or 3, see asym-msg2-proc and asym-msg3-proc.  Note that these optimizations are not applied to instances of ID_CRED_x which have no impact on message size, e.g., context_y, or the COSE protected header. For ID_CRED_x = { 4 : h'FF' }, the encoding in PLAINTEXT_y is not the CBOR map 0xA10441FF but the CBOR byte string h'FF', i.e., 0x41FF. For ID_CRED_x = { 4 : h'21' }, the encoding in PLAINTEXT_y is neither the CBOR map 0xA1044121, nor the CBOR byte string h'21', i.e., 0x4121, but the CBOR integer 0x21. </ins> 3.6. An EDHOC cipher suite consists of an ordered set of algorithms from

Discussion:
Clarification of the optimization of ID_CRED for 'kid',
Merging to include in -18
In , there is I would have expected this to be as per or have I missed something? There is a degree of ambiguity in ` is this refers to the byte string, not necessarily the subset integer equivalent, but the lake-traces would still appear to be wrong.
NAME That looks like a bug. As you can see further down in the same section: ( ? PAD2, IDCREDR / bstr / -24..23, SignatureorMAC2, ? EAD2 ) 32 48 d0 d1 a5 94 79 7d 0a af which is IDCREDR followed by 9 bytes CBOR encoding of SignatureorMAC2. We should also clarify to avoid the ambiguity. Thanks!
I removed the label so we don't forget to also clarify in the spec.
I was too quick making a change in -traces which I had to revert. The implementation is right (of course). So I made a clarification in -edhoc instead, see . Please review.
NAME PR is now merged. Let us know if you have any further comments.
Thanks for the update. When I have some spare time, I am doing a libcoap port. I have now got as far as doing Message_2 as per the traces.
Cool, keep us updated on the progress and if you are interested in interop-testing. Closing this issue then.
Change:
4. The security and privacy considerations of SenML apply also with the <del> FETCH and iPATCH methods. </del> <ins> FETCH and (i)PATCH methods. </ins> <del> In FETCH and iPATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource. </del> <ins> In FETCH and (i)PATCH requests, the client can pass arbitrary names to the target resource for manipulation.  The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource. </ins> If the client is not allowed to do a GET or PUT on the full target resource (and thus all the names accessible through it), access

Discussion:
using "(i)PATCH" to refer to both PATCH methods Clarified defaulting rules Clarified name resolving rules Clarified use of "resource" Added note that application of Patch Packs is idempotent Removed "more details in RFC-AAA" from media type encoding considerations (there are no more details actually)
Change:
default system or application trust anchors. The client MUST verify that the certificate contains the IP <del> address of the designating Unencrypted Resolver in a subjectAltName extension. </del> <ins> address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension as described in Section 4.2.1.6 of RFC5280. </ins> If these checks pass, the client SHOULD use the discovered Designated Resolver for any cases in which it would have otherwise used the

Discussion:
Section 4.2 The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in a subjectAltName extension. Consider being more precise by saying: NEW The client MUST verify that the certificate contains the IP address of the designating Unencrypted Resolver in an iPAddress entry of the subjectAltName extension (see 4.2.1.6 of [RFC5280]). Section 5. For these cases, the client simply sends a DNS SVCB query using the known name of the resolver. This query can be issued to the named Encrypted Resolver itself or to any other resolver. Unlike the case of bootstrapping from an Unencrypted Resolver (Section 4), these records SHOULD be available in the public DNS. If there was a limited domain mechanism using DDR, why would these records be in public DNS?