jiebi/CodeConvo huggingface dataset:
Change:
IXDTF strings such as: <del> are internally inconsistent, as Europe/Paris does not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del> <ins> are internally inconsistent (see inconsistent), as Europe/Paris did not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with:

Discussion:
Minor fix of 3.3, now that we have 3.4. There is still a certain amount of redundancy between the two sections, which might be smoothened out by further editorial action. For now, let's get agreement on Section 2 before further tinkering.
Change:
1.3. <ins> A fundamental requirement of secure REST operations is that the client can bind a response to a particular request.  In HTTPS this is assured by the ordered and reliable delivery as well as mandating that the server sends responses in the same order that the requests were received. The same is not true for CoAP where the server can return responses in any order.  Concurrent requests are instead differentiated by their Token.  Unfortunately, CoAP RFC7252 does not treat Token as a cryptographically important value and does not give stricter guidelines than that the tokens currently "in use" SHOULD (not SHALL) be unique.  If used with security protocol not providing bindings between requests and responses (e.g.  DTLS and TLS) token reuse may result in situations where a client matches a response to the wrong request (see e.g.  Section 2.3 of I-D.mattsson-core-coap-actuators). Note that mismatches can also happen for other reasons than a malicious attacker, e.g. delayed delivery or a server sending notifications to an uninterested client. A straightforward mitigation is to mandate clients to never reuse tokens until the traffic keys have been replaced.  As there may be any number of responses to a request (see e.g.  RFC7641), the easiest way to accomplish this is to implement the token as a counter and never reuse any tokens at all.  This document updates the Token processing in RFC7252 to always assure a cryptographically secure binding of responses to requests. 1.4. </ins> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.
Change:
a central server (n keys for n devices), or have pairwise keys for communicating with each other (n^2 keys for n devices). <ins> 6.2. </ins> The exact provisioning process depends on the system requirements and threat model.  Whenever possible, avoid sharing a PSK between nodes; however, sharing a PSK among several node is sometimes unavoidable. When PSK sharing happens, other accommodations SHOULD be used as discussed in recommendations. <del> 6.1. </del> <ins> Examples of PSK provisioning processes are included below. </ins> Many industrial protocols assume that PSKs are distributed and assigned manually via one of the following approaches: typing the

Discussion:
While trying to find a home for this text, I did some other unrelated cleanup. I couldn't find a spot better than the security considerations. cc NAME
Slightly different placement than I suggested, but it works too.
From NAME This is a great point. We can add some language which describes considerations for external PSK reuse with early data.
Martin: I think we should add: When early data is used with an external PSK, the random value in the ClientHello is the only source of entropy that makes the keying material for the early data associated with one session different from the keying material for the early data associated win another session. As a result, when the external PSK is used more than one time, the random number source on the client has a significant role in the protection of the early data. However, this does not address the last point. Early data always has replay concerns. This was discussed at length during the development of RFC 8446. This is the reason that RFC 8446 says that clients "MUST only send early data which they deem safe to be replayed." With that warning in RFC 8446, what more needs to be said here?
Not sure what you mean regarding the last point, but this is a good contribution. How about (copy editing only):
That reads pretty well to me. Thanks, NAME
MT's text also looks good to me. I'm not sure I understand the (as-yet-unaddressed) point about anti-replay performance, though. I mean, I can parse it -- it's a claim that (some? all?) anti-replay implementations will incur more runtime cost than in scenarios where the PSK is reused and the random data is "not good enough". But how would that come to happen? Are we imagining an implementation that uses a hash table and inputs the client random as the hash input, and "not good enough" randomness would cause unbalanced hashing? Or is the nature of the concern on a totally different axis?
Yeah, I think that we can let that point lie. The NSS anti-replay implementation is somewhat vulnerable to hash stacking, but the effect is that early data is accepted less often, it's not that server CPU cycles are wasted.
Change:
6.1. <del> Selective Forwarding Units (SFUs) as described in https://tools.ietf.org/html/rfc7667#section-3.7 receives the RTP streams from each participant and selects which ones should be forwarded to each of the other participants.  There are several approaches about how to do this stream selection but in general, in order to do so, the SFU needs to access metadata associated to each frame and modify the RTP information of the incoming packets when they are transmitted to the received participants. </del> <ins> Selective Forwarding Units (SFUs) as described in Section 3.7 of RFC7667 receives the RTP streams from each participant and selects which ones should be forwarded to each of the other participants. There are several approaches about how to do this stream selection but in general, in order to do so, the SFU needs to access metadata associated to each frame and modify the RTP information of the incoming packets when they are transmitted to the received participants. </ins> This section describes how this normal SFU modes of operation interacts with the E2EE provided by SFrame

Discussion:
This PR addresses a few outstanding formatting cleanup issues: Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns
Merging on my own since these are just formatting changes.
This : ... is probably not a single paragraph. Similar problems and . It might be worth a more thorough proof-read of the document for others similar formatting problems.
Change:
Since the RS is acting as a client instance, the RS MUST identify itself with its own key in the "client" field and sign the request <del> just as any client instance would. [[ See issue #116 [2] ]] </del> <ins> just as any client instance would, as described in authentication. </ins> The AS responds with a token for the downstream RS2 as described in I-D.ietf-gnap-core-protocol.  The downstream RS2 could repeat this

Discussion:
Expands discussion of RS authentication, with examples. Re-uses structures from client instance auth used in core. Addresses
:heavycheckmark: Deploy Preview for gnap-resource-servers-editors-draft ready! :hammer: Explore the source changes: 71b0e6f2bdaa5a34903865e3130160be29eefc4b :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Change:
true: If it occurs as a "filter-path" in a test expression, the function <del> is defined to have result type "OptionalNodes" or one of its subtypes, or to have result type "OptionalBoolean" or one of its subtypes. </del> <ins> is defined to have result type "OptionalNodesType" or one of its subtypes, or to have result type "OptionalBooleanType" or one of its subtypes. </ins> If it occurs as a "comparable" in a comparison, the function is <del> defined to have result type "OptionalNodeOrValue" or one of its subtypes. </del> <ins> defined to have result type "OptionalNodeOrValueType" or one of its subtypes. </ins> For it and any function expression it contains, each argument of the function matches the defined type of the argument according to

Discussion:
This is literally just a renaming of the names in the Type column of Table 13. I also noticed that the description doesn't account for non-nodelist inputs. I'll open another issue for that.
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
Thanks!
Change:
This parameter is an integer value specifying the initial flow control limit for unidirectional streams.  This limit applies to <del> newly created bidirectional streams opened by the endpoint that </del> <ins> newly created unidirectional streams opened by the endpoint that </ins> receives the transport parameter.  In client transport parameters, this applies to streams with an identifier with the least significant two bits set to 0x3; in server transport parameters,

Discussion:
Quoted from draft 17, value specifying the initial flow control limit for unidirectional streams. This limit applies to newly created bidirectional streams It should be - This limit applies to newly created unidirectional...
Change:
Transport Property Names are hierarchically organized in the form [<Namespace>.]<PropertyName>. <del> The Namespace part is empty for well known, generic properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. </del> <ins> The Namespace part MUST be empty for well-known, generic properties, i.e., for properties that are not specific to a protocol and are defined in an RFC. </ins> <del> Protocol Specific Properties must use the protocol acronym as </del> <ins> Protocol Specific Properties MUST use the protocol acronym as </ins> Namespace, e.g., "tcp" for TCP specific Transport Properties.  For <del> IETF protocols, property names under these namespaces should be </del> <ins> IETF protocols, property names under these namespaces SHOULD be </ins> defined in an RFC. <del> Vendor or implementation specific properties must use a string </del> <ins> Vendor or implementation specific properties MUST use a string </ins> identifying the vendor or implementation as Namespace. <ins> Namespaces for the keywords provided in the IANA protocol numbers registry (see https://www.iana.org/assignments/protocol-numbers/ protocol-numbers.xhtml) are reserved for Protocol Specific Properties and MUST not be used for vendor or implementation specific properties. </ins> 4.2.2. Transport Properties can have one of a set of data types:

Discussion:
It looks like we should use normative language here. We could also use the keywords of the IANA protocol number registry to indicate reserved namespaces for IETF protocols (that can not be used in the vendor or implementation specific namespaces anyway). See URL
Like this?
This is great, thanks!
Change:
New registries created in this document operate under the QUIC registration policy documented in Section 22.1 of QUIC-TRANSPORT. These registries all include the common set of fields listed in <del> Section 22.1.1 of QUIC-TRANSPORT. </del> <ins> Section 22.1.1 of QUIC-TRANSPORT.  These registries [SHALL be/are] collected under a "Hypertext Transfer Protocol version 3 (HTTP/3) Parameters" heading. </ins> The initial allocations in these registries created in this document are all assigned permanent status and list a change controller of the

Discussion:
Please see the for full context. This issue is tracking the following IANA question:
Responded to e-mail as well, but for GitHub tracking purposes, I believe HTTP/3 should be its own registry page, separate from QUIC and analogous to HTTP/2.
NAME I think that is a good proposal.
Can we put that in the draft then?
Change:
streams QUIC.  Applications can implement their own prioritization scheme on top of QUIC: an application protocol that runs on top of QUIC can define explicit messages for signaling priority, such as <del> those defined for HTTP/2; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </del> <ins> those defined in I-D.draft-ietf-httpbis-priority for HTTP; it can define rules that allow an endpoint to determine priority based on context; or it can provide a higher level interface and leave the determination to the application on top. </ins> Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data

Discussion:
for signaling priority, such as those defined for HTTP/2 First, if we retain this comment, it should probably have a reference to RFC 7540 and the appropriate section. However, as NAME noted in reply to a previous issue, this document is about QUIC, not TCP; the use of HTTP/2 as an exemplar seems out-of-place, particularly since we're actively deprecating that priority scheme. Perhaps a reference to draft-ietf-httpbis-priority would be more appropriate?
I agree that a reference to draft-ietf-httpbis-priority would be more appropriate.
Yes, sounds good. I'll create a PR if no-one else does it before me.
Change:
Identify the lowest common ancestor in the tree of the new member's leaf node and the member sending the Commit <del> Compute the path secret corresponding to the common ancestor node </del> <ins> If the "path" field was populated above: Compute the path secret corresponding to the common ancestor node </ins> Compute an EncryptedGroupSecrets object that encapsulates the <del> "init_secret" for the current epoch and the path secret for the common ancestor. </del> <ins> "init_secret" for the current epoch and the path secret (if present). </ins> Construct a Welcome message from the encrypted GroupInfo object and the encrypted group secrets.

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.
Change:
The RateLimit-Policy field (see ratelimit-policy-field), might contain information on the associated time window. <del> This field MUST NOT occur multiple times and can be sent in a trailer section. </del> <ins> This field can be sent in a trailer section. </ins> 3.2.

Discussion:
According to URL there is no need to specify that information.
This text appears in relation to Item fields. By their nature Items can only occur on one field line (the proper terminology, btw), so this requirement is extraneous, and should be removed.
... and it's also on RateLimit-Policy, even though that is a List field.
Change:
negotiated MLS ciphersuite to AEAD encrypt and decrypt their Application messages according to the Message Framing section. <del> The group identifier and epoch allow a device to know which group </del> <ins> The group identifier and epoch allow a recipient to know which group </ins> secrets should be used and from which Epoch secret to start computing other secrets and keys.  The "sender" identifier is used to derive the member's Application secret chain from the initial group

Discussion:
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Change:
the administrator, implementations MUST disable the spin bit for a given connection with a certain likelihood.  The random selection process SHOULD be designed such that on average the spin bit is <del> disabled for at least one eighth of connections.  The selection </del> <ins> disabled for at least one eighth of network paths.  The selection </ins> process performed at the beginning of the connection SHOULD be applied for all paths used by the connection. <del> In case multiple connections share the same five-tuple, that is, have the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </del> <ins> In case multiple connections share the same network path, as determined by having the same source and destination IP address and UDP ports, endpoints should try to co-ordinate across all connections to ensure a clear signal to any on-path measurement points. </ins> When the spin bit is disabled, endpoints MAY set the spin bit to any value, and MUST ignore any incoming value.  It is RECOMMENDED that

Discussion:
When multiple connections share the same network path or multiple connection IDs are used for the same path, using the spin bit is complicated by the difficulty in correlating forward and reverse flows. There is currently text that uses RFC 6919 language in the draft recommending coordination of the spin to avoid this problem. However, as , this coordination seems difficult and therefore unlikely. It also creates a strong signal that indicates that all the connections on the path are terminated at the same endpoint on both ends. Maybe we don't want to be generating that signal. Also, because this coordination can't be guaranteed, the on-path observer is forced to build code for correlating/segregating measurements by connection ID in the case where there is no coordination. Maybe it's best just to remove this recommendation entirely.
+1 to removing the recommendation, or changing the statement to just a caution (e.g., if you are to coalesce connections that spin, then you'd better be aware of ...). FWIW I am not sure if I agree with this observation. IIUC, the connections sharing a 5-tuple will be terminated by the same endpoint on both ends; it is impossible for a middlebox to coalesce multiple QUIC connections. It is impossible because CIDs can change mid-connection, and a middlebox cannot determine to where the packets containing the new CID must be sent.
There definitely needs to be a degree of coordination between the middlebox and the endpoints, but that doesn't mean that you can't use something like the quic-lb stuff on either end (or both ends).
Yes, I think it is better to remove that recommendation, but perhaps replace it with a note to observers.
Text says: How would that work when 1/8th of the connections are not spinning? Wouldn't that either be sending a misleading signal, or violate the 1/8th rule?
Change:
divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes <del> idempotence either ecplicitly or implicitly. </del> <ins> idempotence either explicitly or implicitly. </ins> 3.2.

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)