jiebi/CodeConvo huggingface dataset:
Change:
classification. Note that the use of a connection ID to support connection migration <del> renders 5-tuple based filtering insufficient and requires more state to be maintained by DDoS defense systems.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </del> <ins> renders 5-tuple based filtering insufficient to detect active flows and requires more state to be maintained by DDoS defense systems if support of migration of QUIC flows is desired.  For the common case of NAT rebinding, where the client's address changes without the client's intent or knowledge, DDoS defense systems can detect a change in the client's endpoint address by linking flows based on the server's connection IDs.  However, QUIC's linkability resistance ensures that a deliberate connection migration is accompanied by a change in the connection ID.  In this case, the connection ID can not be used to distinguish valid, active traffic from new attack traffic. </ins> It is also possible for endpoints to directly support security functions such as DoS classification and mitigation.  Endpoints can

Discussion:
We recently added this sentence but the text two paragraphs up already says this. Here is my proposed change, however, maybe we can shorten this paragraph even further.
Change:
depth N in the input value. There are two kinds of segment: child segments and descendant <del> segments.  ~~~~ abnf segment = child-segment / descendant-segment ~~~~ </del> <ins> segments. </ins> The syntax and semantics of each kind of segment are defined below.

Discussion:
Weirdly, I cannot reply to this observation: URL Expiry is somewhat unusual for IANA registries (early allocations do expire). What is the behavior you would expect implementations to exhibit? The function extension to stop working on the expiry day?
Hey NAME based on this useful-looking discussion, do you plan to revise this significantly? I'm wondering if I should give it a careful read now or wait for an updated version.
Definitely. Of course, I'd like to have your input on the points raised (the non-trivial ones). We might even want to have a design-team meeting...
Might be a good idea to mark the non-non-trivial issues above resolved, to help reviewer focus. If it's OK, I'll wait for the next revision to go end-to-end. Agreed on a design meeting.
Here's my list of items where we could use input: More frugal with allowing whitespace? return value of functions that don't get the right arguments (e.g., length(1)) (interaction with -- non-singular paths in exist-expr) IANA designated expert instructions (frugal with "good" names) expiring reservations? (shades of certificates) domain of length (arrays now, add strings, objects?)? should there be another function for the size of nodelists (size())? Probably mostly resolved: for function names (ASCII, lowercase, only)
NAME I rebased this and resolved some conflicts.
Update: Address whitespace in a separate PR, if desired. Semantic issue: What to do with value of wrong kind? Fixed in 08dd7ad Fixed in afda44a Probably not. Semantic issue: What to do with value of wrong kind? Yes, that is called count() now (e3a565a) Let's stick with that name space.
We may be able to make this syntactically invalid. See URL for some ideas.
Change:
might be destroyed sooner, as soon as handshake keys are available (see Section 4.9.1 of QUIC-TLS). <del> 5.6. The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow. A shorter delayed ack time of 25ms was chosen because longer delayed acks can delay loss recovery and for the small number of connections where less than packet per 25ms is delivered, acking every packet is beneficial to congestion control and loss recovery. </del> 6. QUIC's congestion control is based on TCP NewReno RFC6582.  NewReno

Discussion:
The recommendation for a 25ms delayed ack time is in transport, not recovery, so remove it from recovery. Should this paragraph be moved to transport?
I think that it's fine to just cut this.
This paragraph didn't seem to relate to anything else in the document: Is it left-over from a previous version?
Thanks for pointing this out. The intent was to explain why 25ms was chosen, given it's smaller than most TCP implementations default delayed ack time. There were more exceptions before, but now there's only the one, which makes the preceding paragraph awkward as well. "The majority of constants were derived from best common practices among widely deployed TCP implementations on the internet. Exceptions follow."
I realized that the 25ms recommendation is in transport, so this is just out of place now.
Ah, I see, I remember I went looking for it in transport, but I think I looked for "delayed ack" and didn't come up with anything fitting. I've got no concrete suggestion how to resolve it but moving the notice to transport in some form would probably make sense.
Change:
A request by an application for Protocol Properties that include requirements or prohibitions that cannot be satisfied by any of the available protocols.  For example, if an application requires <del> "Configure Reliability per Message", but no such protocol is available on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. </del> <ins> "Configure Reliability per Message", but no such feature is available in any protocol the host running the transport system on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. </ins> A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited

Discussion:
Nit: Section 3.1: No such protocol…
I’ll argue this “but no such protocol is available on the host running the transport system” is asking for a feature, so I think the text ought to read: “but no such feature is available in any protocol the host running the transport system”
"but no protocol available on the host offers such a feature"
This was fixed in the already merged PR.
Change:
3.1. In order to indicate support for WebTransport, both the client and <del> the server MUST send a SETTINGS_ENABLE_WEBTRANSPORT value set to "1" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport- related functionality unless the parameter has been negotiated. </del> <ins> the server MUST send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS value greater than "0" in their SETTINGS frame.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. </ins> 3.2. RFC8441 defines an extended CONNECT method in features, enabled by the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint needs to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and <del> SETTINGS_ENABLE_WEBTRANSPORT for WebTransport to be enabled. </del> <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS for WebTransport to be enabled. </ins> 3.3.

Discussion:
Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS.
I can't seem to remember or work out what the purpose of SETTINGSENABLEWEBTRANSPORT is now that we have SETTINGSWEBTRANSPORTMAXSESSIONS. This leads to the following questions: If the server sends SETTINGSWEBTRANSPORTMAXSESSIONS>0 but SETTINGSENABLEWEBTRANSPORT=0, what does that mean? If the client sends SETTINGSENABLEWEBTRANSPORT=0 but sends a WebTransport request, what is the purpose of having the server fail the request?
Yeah, I thought that we would remove SETTINGSENABLEWEBTRANSPORT when the session limit was added. If nothing else, it removes those awkward interactions.
Chair: discussed in editor's meeting, sounds like we should remove SETTINGSENABLEWEBTRANSPORT. We might add another setting to be removed by the RFC editor for versioning between drafts
IIRC, we discussed at IETF 115 and only the server needed to send MAX_SESSIONS, so we kept both. Can spell that either way though.
If we're doing this for H2, should we also do it for H3, since we have SETTINGSMAXWEBTRANSPORT_SESSIONS there, too?
h3 requires SETTINGSENABLEWEBTRANSPORT because it changes the format of server-initiated bidi streams h2 has no such requirement for a setting
Change:
successful.  If no DNS record is found, or DNS record and response payload do not pass these checks, then the validation fails. <del> 8.6. There may be cases where a server cannot perform automated validation of an identifier, for example, if validation requires some manual steps.  In such cases, the server may provide an "out of band" (OOB) challenge to request that the client perform some action outside of ACME in order to validate possession of the identifier. The OOB challenge requests that the client have a human user visit a web page to receive instructions on how to validate possession of the identifier, by providing a URL for that web page. The string "oob-01" The URL to be visited.  The scheme of this URL MUST be "http" or "https".  Note that this field is distinct from the "url" field of the challenge, which identifies the challenge itself. A client responds to this challenge by presenting the indicated URL for a human user to navigate to.  If the user chooses to complete this challenge (by visiting the website and completing its instructions), the client indicates this by sending a simple acknowledgement response to the server.  The payload of this response is an empty JSON object ("{}", or "e30" base64url-encoded). On receiving a response, the server MUST verify that the value of the "type" field is "oob-01".  Otherwise, the steps the server takes to validate identifier possession are determined by the server's local policy. </del> 9. 9.1.

Discussion:
The OOB challenge was added to accommodate non-ACME CAs building ACME integrations. Since then two non-ACME CAs have implemented ACME integrations using the external account binding feature but not implementing OOB challenges. Since the target demographic has not implemented this feature and has also not presented a use-case requiring it there seems to be no strong reasons to keep it in-spec.
NAME If you could update this to remove the OOB challenge from the , I'll go ahead and merge
NAME Good catch - thanks! Addressed in 0753c73.
Change:
ack_delay_exponent, max_ack_delay, initial_source_connection_id, original_destination_connection_id, preferred_address, retry_source_connection_id, and stateless_reset_token.  The client <del> MUST use the server's new values in the handshake instead, and absent new values from the server, the default value. </del> <ins> MUST use the server's new values in the handshake instead; if the server does not provide new values, the default value is used. </ins> A client that attempts to send 0-RTT data MUST remember all other transport parameters used by the server.  The server can remember

Discussion:
:
(Broken out of .) what does ‘absent’ mean in this clause, could you reword?
Change:
6. <del> Hybrid public-key encryption (HPKE) I-D.irtf-cfrg-hpke is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key. </del> <ins> Hybrid public-key encryption (HPKE) RFC9180 is a scheme that provides public key encryption of arbitrary-sized plaintexts given a recipient's public key. </ins> For use with firmware encryption the scheme works as follows: HPKE, which internally utilizes a non-interactive ephemeral-static Diffie-

Discussion:
Based on discussions with Russ, I have updated the text in Section 7 about CEK Verification. Text about the parameters used for encryption were missing.
Change:
The string "dns-01" <del> A serialized authorized key object, base64-encoded.  The "key" field in this object MUST match the client's account key. </del> <ins> A random value that uniquely identifies the challenge.  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> <del> In response to the challenge, the client MUST parse the authorized key object and verify that its "key" field contains the client's account key.  The client then computes the SHA-256 digest of the JSON-encoded authorized key object (without base64-encoding). </del> <ins> A client responds to this challenge by constructing a key authorization from the "token" value provided in the challenge and the client's account key.  The client then computes the SHA-256 digest of the key authorization. </ins> The record provisioned to the DNS is the base64 encoding of this digest.  The client constructs the validation domain name by

Discussion:
This PR updates the new challenges so that they no longer use a JSON object dictated by the server. Instead, they use a "key authorization" string that is canonically generated from the token and key for a given challenge. (And also, while we're here, changes "authorized key object" to "key authorization".)
Change:
8.13. <ins> IANA has added the resource type "core.edhoc" to the "Resource Type (rt=) Link Target Attribute Values" registry under the group name "Constrained RESTful Environments (CoRE) Parameters". Value: "core.edhoc" Description: EDHOC resource. Reference: [[this document]] Client applications can use this resource type to discover a server's resource for EDHOC, where to send a request for executing the EDHOC protocol. 8.14. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what the experts should be looking for, but they are being designated as

Discussion:
A new Resource Type (rt=) Link Target attribute like "URL" may be registered in the "Resource Type (rt=) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" registry.
That seems like a good idea.
Marco, do you want to provide a PR? Then we could merge that for -11
Done, see URL Note that the first commit is just about removing trailing whitespace to avoid compiling errors. The content you need is in the commit URL
Looks good. I tried to align the whole IANA section with RFC 8126. Then I merged.
Change:
Any "a=extmap" lines are parsed as specified in RFC5285, Section 5, and their values are stored. <del> TODO: msid-semantic, identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </del> <ins> TODO: identity, rtcp-rsize, rtcp-mux, and any other attribs valid at session level. </ins> Once all the session-level lines have been parsed, processing continues with the lines in media sections.

Discussion:
This contains the ice-options changes as well - will take another look once that PR is merged.
looks like a straightforward change - lgtm
LGTM
JSEP defines this attribute on media level, while 5245 says it is a session level attribute. I understand that there is development ongoing here (e.g. 5245bis), but given that canTrickleIceCandidates is an API on the PeerConnection it makes more sense IMO to have ice-options:trickle on the session level than media line level. If we want this on media line line level, canTrickleIceCandidates should be a (readonly) Transceiver attribute. To that seems messy though, what would happen if Bundle is negotiated but one media line can do trickle but the other not? While the relation between the application of an Answer and canTrickleIceCandidates is spelled out, the same thing should be done for application of an Offer.
Decision on 1): simplest thing here is to move ice-options to session level, right after "An "a=msid-semantic:WMS" line MUST be added..." 2) yes, this should be put into handling a remote description, not handling an answer.
I can take this.
JSEP requires sending q=msid-semantics:WMS: If I read URL correctly, that is no longer defined, so that requirement should probably go. I'm happy to provide a PR that removes the requirement, the example usage and updates the reference, but I assume that updating the reference involves more work than just this, so I'll refrain from doing so unless I hear it would still be useful.
I think we can just remove this line, and scrub it from the examples. More work is probably needed to fix up the refs regarding a=msid, but I think this part should be easy to handle.
Change:
? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e., <del> ID_CRED_I = { 4 : kid_I }, then only the byte string is included in the plaintext, represented as described in bstr- repr, see examples in id_cred. </del> <ins> ID_CRED_I = { 4 : kid_I }, then the compact encoding is applied, see compact-kid. </ins> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

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:
precedence from highest (binds most tightly) to lowest (binds least tightly). <del> 3.4.8.2. </del> <ins> 3.4.7.2. </ins> The "filter-selector" works with arrays and objects exclusively.  Its result is a list of

Discussion:
I want to take the opportunity of there being no PRs in flight to make this purely editorial change to the order of the spec. It avoids unnecessary forward references to the filter and list selectors.
Another PR opened and merged in less than 8 hours...
Please note this PR was purely editorial. It moved some text around. but didn't change it. (I was planning to merge this later today after a bit more time.)
We should just have a flat policy of 24 hrs for a PR to ensure everyone gets to see it. It doesn't matter if it was a spelling change. Everyone should have a chance to review it.
It's one thing to agree to this policy, which I think we have, and quite another to remember to apply it when one is focussed on other things. I've raised a about automating this check.
Have we? It is not policy I would normally agree to. Editors need to be able to do their work. Github is here to help, not to hinder.
Ah, my mistake: I agreed.
We have a two-week policy for PRs in JSON Schema and it's very helpful to encourage cooperation. I don't think 24 hrs is too much to ask.
Please explain how you did not get a chance to review this change.
The PR opened at 3AM and merged at 10AM. This is an insufficient window. 24 hrs, please. It's not a big request.
You have had time to review after merge. How is a merge such an important event?
If I have objections to a PR, they should be voiced before it's merged. Reviewing after the fact is pointless. Any damage has been done. This particular PR is not one of those cases, but in general, everyone involved should get a chance to review. Why are you so opposed to this? It's one day. That's all I'm asking.
Thanks!
Change:
code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. <del> For other errors, the resource MUST return the appropriate status code and error message. </del> <ins> Error scenarios above describe the status of failed idempotent requests, after the resource server prcocesses them.  Clients MUST correct the requests before performing a retry operation, or the the resource server MUST fail the request and return one of the above errors. For other 4xx/5xx errors, such as 401, 403, 500, 502, 503, 504, 429, or any other HTTP error code that is not listed here, the client SHOULD act appropriately by following the resource server's documentation. </ins> 3.

Discussion:
1- Addressed comments wrt 5XX codes being retriable 2- Elaborated the security section to describe security issues relating to the idempotency key
Change:
mechanism. The means of dereferencing this value are out of scope for this <del> specification. </del> <ins> specification.  Commonly, key references are created by the AS and are not necessarily needed to be dereferencable by the client.  These types of key references are an internal reference to the AS, such as an identifier of a record in a database.  In other applications, it can be useful to use key references that are resolvable by both clients and ASs, which could be accomplished by e.g. a client publishing a public key at a URL.  For interoperability, this method could later be described as an extension. </ins> 7.2.

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ca9e3193f78b420b40659157f6d18545ddc97e80 Inspect the deploy log: Browse the preview:
Originally posted by NAME in URL
In general I would tend to think this doesn't need to be specified by us, supporting the current text "The means of dereferencing this value are out of scope for this specification." But before we can conclude, I'd like to ask a few questions: related the lifecycle of the referenced key (cf ) : is it something ephemeral (linked to a specific request) or not ? (but knowing that continuation could last for some time, what do we do then?) could it have an impact on error management? (for instance collision of references?)
In draft 7, says that dereferencing key references are out of scope. Add to 7.1.1 to clarify: The common case is such that key references are created by the AS and are not necessarily deferenceable by the client, they are just an internal AS reference If an implementation (or ecosystem of implementations) wants to use references that are resolvable by both clients and ASs (i.e. the client publishes its key at a URL), that could be described as an extension
I think the text looks good, left one note on formatting/structure but it's not a showstopper.
Change:
octets" in UDP). Clients MAY optimistically start sending proxied UDP packets before <del> receiving the response to its UDP proxying request, noting however that those may not be processed by the proxy if it responds to the request with a failure, or if the datagrams are received by the proxy before the request. </del> <ins> receiving the response to its UDP proxying request.  However, implementors should note that such proxied packets may not be processed by the proxy if it responds to the request with a failure, or if the proxied packets are received by the proxy before the request. </ins> By virtue of the definition of the UDP header UDP, it is not possible to encode UDP payloads longer than 65527 bytes.  Therefore, endpoints

Discussion:
This is a long sentence that mixes singular and plural terms, for different concepts. I think this needs some editing to improve readability.