jiebi/CodeConvo huggingface dataset:
Change:
This specification defines the following protocol messages, along with their corresponding media types types: <del> HpkeConfig hpke-config: "application/ppm-hpke-config" </del> <ins> HpkeConfig hpke-config: "application/dap-hpke-config" </ins> <del> Report upload-request: "message/ppm-report" </del> <ins> Report upload-request: "message/dap-report" </ins> <del> AggregateInitializeReq collect-flow: "message/ppm-aggregate- </del> <ins> AggregateInitializeReq collect-flow: "message/dap-aggregate- </ins> initialize-req" <del> AggregateInitializeResp collect-flow: "message/ppm-aggregate- </del> <ins> AggregateInitializeResp collect-flow: "message/dap-aggregate- </ins> initialize-resp" <del> AggregateContinueReq collect-flow: "message/ppm-aggregate- </del> <ins> AggregateContinueReq collect-flow: "message/dap-aggregate- </ins> continue-req" <del> AggregateContinueResp collect-flow: "message/ppm-aggregate- </del> <ins> AggregateContinueResp collect-flow: "message/dap-aggregate- </ins> continue-resp" <del> AggregateShareReq collect-flow: "message/ppm-aggregate-share-req" </del> <ins> AggregateShareReq collect-flow: "message/dap-aggregate-share-req" </ins> <del> AggregateShareResp collect-flow: "message/ppm-aggregate-share- </del> <ins> AggregateShareResp collect-flow: "message/dap-aggregate-share- </ins> resp" <del> CollectReq collect-flow: "message/ppm-collect-req" </del> <ins> CollectReq collect-flow: "message/dap-collect-req" </ins> <del> CollectResp collect-flow: "message/ppm-collect-resp" </del> <ins> CollectResp collect-flow: "message/dap-collect-resp" </ins> The definition for each media type is in the following subsections.

Discussion:
This change is basically a search-and-replace for /ppm/dap/. However, I have also re-aligned the context strings to match the next draft that will be cut (-01). I think the change is mostly correct, my main concern is the "URN Sub-namespace for PPM (urn:ietf:params:dap)" section. : Does it make sense for all drafts in the PPM WG to share the namespace, or do we want to define one specifically for DAP?
Before merging I would appreciate an answer on the question I raised above. I want to make sure the URN bits are correct.
Separate namespaces seems better, especially if we're thinking of DAP and STAR. Names are cheap, after all.
Separate namespaces, because otherwise I think we'd have to write a further document enumerating the error type URNs that both this document and other PPM drafts like STAR could reference. We should avoid spreading the specification across multiple documents more than necessary. Maybe including the WG in the URN path like helps?
Here's the RFC defining URL It's pretty loosely structured, and the existing sub-namespaces from published RFCs appear to just be named after protocols and formats, not working groups. URL
I took NAME suggestion of prefixing the dap space with ppm.
Change:
from the closest node to the leaf to the root; each node MUST be the parent of its predecessor. <del> The number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the resolution of the corresponding copath node.  Each ciphertext in the list is the encryption to the corresponding node in the resolution. </del> <ins> For each "UpdatePathNode", the resolution of the corresponding copath node MUST be filtered by removing all new leaf nodes added as part of this MLS Commit message.  The number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the filtered resolution, with each ciphertext being the encryption to the respective resolution node. </ins> The HPKECiphertext values are computed as

Discussion:
As briefly explained in the mailing list, commit messages currently contain encryptions for newly added group members that never even receive this commit message. This PR explicitely exlcudes them during the preparation of the UpdatePath.
I think this is a good point that wasn't really specified so far. The wording sounds a bit convoluted, maybe there is an easier way to describe it, like saying that the final resolution list should be filtered and all new leaf nodes should be removed from it.
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-09 Remove blanking of nodes on Add (*) Change epoch numbers to uint64 (*) Add PSK inputs (*) Add key schedule exporter (*) Sign the updated direct path on Commit, using "parent hashes" and one signature per leaf (*) Use structured types for external senders (*) Redesign Welcome to include confirmation and use derived keys (*) Remove ignored proposals (*) Always include an Update with a Commit (*) Add per-message entropy to guard against nonce reuse (*) Use the same hash ratchet construct for both application and handshake keys (*) Add more ciphersuites Use HKDF to derive key pairs (*) Mandate expiration of ClientInitKeys (*) Add extensions to GroupContext and flesh out the extensibility story (*) </ins> draft-08 Change ClientInitKeys so that they only refer to one ciphersuite

Discussion:
Since draft-08, we have neglected to update the changelog, despite a bunch of significant changes. Also, because our CI is busted, some build failures crept in.
Change:
This design is not forward secret because the server's ESNI key is static.  However, the window of exposure is bound by the key <del> lifetime.  It is RECOMMEMDED that servers rotate keys frequently. </del> <ins> lifetime.  It is RECOMMENDED that servers rotate keys frequently. </ins> 7.2.6.

Discussion:
There were two minor typos. This PR fixes them. While I was at it, I ran over it, most seemed fine.
Change:
2.01 (Created) This Response Code indicates successful receipt of the entire body <del> and the resource was created. </del> <ins> and the resource was created.  The token used SHOULD be from the last received payload.  The client should then release all of the tokens used for this body. </ins> 2.04 (Changed) This Response Code indicates successful receipt of the entire body <del> and the resource was updated. </del> <ins> and the resource was updated.  The token used SHOULD be from the last received payload.  The client should then release all of the tokens used for this body. </ins> 2.31 (Continue) This Response Code can be used to indicate that all of the blocks up to and including the Q-Block1 Option block NUM (all having the <del> M bit set) in the response have been successfully received. </del> <ins> M bit set) in the response have been successfully received.  The token used SHOULD be from the last received payload. </ins> A response using this Response Code SHOULD NOT be generated for every received Q-Block1 Option request.  It SHOULD only be

Discussion:
find another name than Quick-Block
A poll is ongoing. Updated to Q-Block in -02, but open to change if we get more inputs
Change:
The policy for this shall be "Specification Required" as described in RFC8126. <ins> 3.1. This extension allows up to 2040 flags.  However, they are not all the same, because the length of the extension is determined by the highest set bit. We would like to allocate the flags in such a way that the typical extension is as short as possible.  The scenario we want to guard against is that in a few years some extension is defined that all implementations need to support and that is assigned a high number because all of the lower numbers have already been allocated.  An example of such an extension is the Renegotiation Indication Extension defined in RFC5746. For this reason, the IANA experts should allocate the flags as follows: Flags 0-7 are reserved for documents coming out of the TLS working group with a specific request to assign a low number. Flags 8-31 are for standards-track documents that the experts believe will see wide adoption among either all users of TLS or a significant group of TLS users.  For example, an extension that will be used by all web clients or all smart objects. Flags 32-63 are for other documents, including experimental, that are likely to see significant adoption. Flags 64-79 are not to be allocated.  They are for reserved for private use. Flags 80-2039 can be used for temporary allocation in experiments, for flags that are likely to see use only in very specific environments, for national and corporate extensions, and as overflow, in case one of the previous categories has been exhausted. </ins> 4. The extension described in this document provides a more concise way

Discussion:
Provide guidance on what flag should be allocated to what extension, based on the likelihood of that extension being widely used.
Change:
where <del> label is a uint </del> <ins> info_label is an int </ins> context is a bstr

Discussion:
In the latest commit there are new names to distinguish infolabel and exporterlabel, the former is extended to be int. I also noted an error in the CDDL reference section C.2.
The current design of encryption of message2 in EDHOC limits the size of the message to 8160 bytes when SHA-256 is used. Is that a problem? message2 consists of the fields GY IDCREDR SignatureorMAC2 CR and optional fields: ? PAD2 ? EAD2 While these message fields could be very small, depending on use case, some may be arbitrarily large. The field IDCREDR would typically be a reference to an authentication credential, but may contain the credential itself, for example a certificate chain. EAD2 is defined by the application so may a priori be large. One example is revocation information. John: SHA-384 has the limit 12240 bytes and SHA-512 has the limit 16320 bytes. SHAKE128 and SHAKE256 have much much larger limits (2^2040 − 1 bits)
Some of the alternatives: Do nothing / this is not a problem Replace HKDF with HKDF', which allows larger length of output Use HKDF for message2 size < 8160, HKDF' for larger message2 Replace message_2 encryption with AES-CTR / ChaCha20 Use KMAC instead of HKDF Edit: Multiple applications of HKDF, to produce sufficiently long keystream John: HKDF' here refer only to HKDF-Expand. HKDF-Extract would stay the same. John: HKDF' would still be HKDF but not HKDF as specified in RFC 5869. The original HKDF paper just states that the counter is fixed length. RFC 5869 unfortunately chose 1 byte. URL
It seems that this is a concern if/when GY or SignatureorMAC2 becomes one of the monstrous Post-Quantum algorithms, or a HSS. I think that we should rule that out of scope, say that when it happens that we'll do EDHOC2 based upon new constraints at the time. I think that 8K is probably enough for the certificate chain. That's a lot (100) of 802.15.4 fragments. So unless switching to HKDF' is really cheap, don't bother.
Thanks Michael.

Yes, the assumption so far has been "this is not a problem". NAME It would be good to understand the impact on implementation if we would come to a different conclusion. Please comment, on the examples below. Replace HKDF with HKDF', which allows larger length of output HKDF is constructed from HMAC using a counter which is 8 bits long. By defining HKDF' with 16 / 32 bits counter would make the output 2 MB / 137 GB (if I did the maths right) before the counter wraps. How is HKDF implemented today? Is it feasible to define your own variant, say with 32 bits counter? Use HKDF for message2 size >
PR is included in -16
Change:
For both sets of users, this document aims to provide some amount of advice on practices that have proven to be effective. <ins> This document only aims to address use of GitHub in developing documents.  Working Groups could choose to use the tool to aid in managing their charter or session materials such as agendas, minutes, and presentations.  Though the advice here might apply more broadly, using GitHub to manage other material is out of scope for this document. </ins> 1.5. The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are

Discussion:
For , but not all of it.
Some working groups use GitHub to manage changes to charters or other working group materials, like agendas and presentations for sessions. I'd suggest that no great amount of detail is needed because these aren't the primary focus of the document, but it probably should include at least a passing mention of these uses and acknowledge that they are permitted.
Discussed in Singapore; MT to add text.
Closed in .
How this fits into existing processes is something that needs more thorough investigation if we're publishing an RFC on this.
Discussed in Singapore; no objections, merged, and closing.
Change:
1. <del> This document specifies an extension to QUIC v1 QUIC-TRANSPORT to enable the simultaneous usage of multiple paths for a single </del> <ins> This document specifies an extension to QUIC version 1 QUIC-TRANSPORT to enable the simultaneous usage of multiple paths for a single </ins> connection. This proposal is based on several basic design points: <del> Re-use as much as possible mechanisms of QUIC-v1.  In particular this proposal uses path validation as specified for QUIC v1 and aims to re-use as much as possible of QUIC's connection migration. </del> <ins> Re-use as much as possible mechanisms of QUIC version 1.  In particular this proposal uses path validation as specified for QUIC version 1 and aims to re-use as much as possible of QUIC's connection migration. </ins> <del> Use the same packet header formats as QUIC v1 to avoid the risk of packets being dropped by middleboxes (which may only support QUIC v1) </del> <ins> Use the same packet header formats as QUIC version 1 to avoid the risk of packets being dropped by middleboxes (which may only support QUIC version 1) </ins> Congestion Control, RTT measurements and PMTU discovery should be per-path (following QUIC-TRANSPORT)

Discussion:
Be consistent with RFC9000
In order to be consistent with RFC9000, use "QUIC version 1" instead of "QUIC v1" through the document.
Change:
mandatory set of primitives to be supported by all the participating nodes. <del> MOP as per RFC6550 is a 3-bit value carried in DIO messages and is specific to the RPL Instance.  The receipient of the DIO message can join the specified network as a router only when it can support the primitives as required by the mode of operation value.  For example, in case of MOP=3 (Storing MOP with multicast support) the nodes can join the network as routers only when they can handle the DAO advertisements from the peers and manage routing tables.  The 3-bit value is already exhausted and requires replenishment.  This document introduces a mechanism to extend mode of operation values. This document further adds a notion of capabilities using which the nodes in the network could inform its peers about its additional capabilities/features.  This document highlights the differences of capabilities from that of Mode of operation and explains the necessity of it. </del> <ins> This document adds a notion of capabilities using which the nodes in the network could inform its peers about its additional capabilities/ features.  This document highlights the differences of capabilities from that of Mode of operation and explains the necessity of it. </ins> 1.1.

Discussion:
splitup with mopex differencess with DIO config option, MOP and routing metrics/constraints (fixes for ) sections reliagnment refs updated
The draft should clarify the differences and clearly state when to use when citing examples.
handled in Section 2.1
Change:
packets with associated ECN marks received on the connection up to this point. <del> ACK_MP frame is formatted as shown in fig-mp-ack-format. </del> <ins> ACK_MP frame is formatted as shown in fig-ack-mp-format. </ins> Compared to the ACK frame specified in QUIC-TRANSPORT, the following field is added.

Discussion:
This should be a simple fix. There was only one place where MP_ACK appeared.
In the current draft, we are having two names of multi-path ACK. I think we should stick to just one.
I have a slight preference for ACKMP, on the model of ACKECN.
I submitted PR to fix this.
I would be consistent in how the I-D identifies MP additions vs. RFC9000. Given that the document uses MPCONNECTIONERROR and MPPROTOCOLVIOLATION, I have a preference for MP_ACK.
I added changes of the tag "mp-ack-frame" to "ack-mp-frame" for consistency...
Change:
"A server that knows the content of a DNS zone from local knowledge, and thus can answer queries about that zone without needing to query other servers."  (Quoted from RFC2182, <del> Section 2.)  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server. Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </del> <ins> Section 2.)  An authoritative server is named in the NS ("name server") record in a zone.  It is a system that responds to DNS queries with information about zones for which it has been configured to answer with the AA flag in the response header set to 1.  It is a server that has authority over one or more DNS zones.  Note that it is possible for an authoritative server to respond to a query without the parent zone delegating authority to that server.  Authoritative servers also provide "referrals", usually to child zones delegated from them; these referrals have the AA bit set to 0 and come with referral data in the Authority and (if needed) the Additional sections. </ins> A name server that only serves authoritative data and ignores requests for recursion.  It will "not normally generate any

Discussion:
Agree with the first one, although I don't care which way it comes out from the RFC Editor. For the second one, I have changed the wording to 'An authoritative server is named in the NS ("name server") record in a zone.' We don't need to stray into which zone has authoritative data; the double use of "authoritative" will confuse the reader without helping with the terminology.
l 179, s/octets which/octets that. This has been changed to violate the that/which conventions of the RFC Editor. l844 (new) the authoritative name server is named in the parent zone but is not authoritative data there (NS is authoritative in the child). This is discussed elsewhere in the document, and I find this addition confusing. I won't hold up pver either of these. The rest looks ok.
Change:
The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField <del> format.  Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. </del> <ins> format.  Values less than 64 are mandatory to understand while other values are optional to understand.  A receiver SHOULD discard the whole EKTField if it contains any message type value that is less than 64 and that is not understood.  Message type values that are 64 or greater but not implemented or understood can simply be ignored. </ins> 2.2.

Discussion:
If anyone has ideas on how to write this is a more clear way, love any suggestions ...
s2.1, MessageType Maybe it’s late but I’m having trouble parsing this sentence: Values less than 64 are mandatory to understand and the whole EKTField SHOULD be discarded if it contains message type value that is less than 64 and is not implemented. Can “and is not implemented” be dropped?
Change:
If any of them is matchable to the new one, and the client neither wants to cancel the old one nor postpone the new one, it can pick <del> a Request-Tag value that is not in use by the other matchable operations for the new operation. </del> <ins> a Request-Tag value (including the absent option) that is not in use by the other matchable operations for the new operation. </ins> Otherwise, it can start the new operation without setting the Request-Tag option on it.

Discussion:
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving. Rationale as in the review response mail: Reference made more precise, "from a single endpopoint" added. Split up into separate sentences for better clarity. That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose. Rephrased to pull in the purpose before the MUST and make that explicit. The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something. (We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update). Added to the initial (now split up) paragraph of that section. Explicitly included as an option now. (Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).
Looks good.
Change:
This document is meant as a supplement to existing Working Group practices.  It provides guidance to Working Group chairs and participants on how they can best use GitHub within the framework <del> established by RFC 2418 RFC2418.  The small number of rules in this document are there to ensure common usage patterns between Working Groups and to avoid issues that have been encountered in the past. </del> <ins> established by RFC 2418 RFC2418.  This document aims to establish norms that reduce the variation in usage patterns between different Working Groups and to avoid issues that have been encountered in the past. </ins> A companion document, GH-CONFIG, describes administrative processes that support the practices described in this document.

Discussion:
For , but not all of it.
Some working groups use GitHub to manage changes to charters or other working group materials, like agendas and presentations for sessions. I'd suggest that no great amount of detail is needed because these aren't the primary focus of the document, but it probably should include at least a passing mention of these uses and acknowledge that they are permitted.
Discussed in Singapore; MT to add text.
Closed in .
How this fits into existing processes is something that needs more thorough investigation if we're publishing an RFC on this.
Discussed in Singapore; no objections, merged, and closing.
Change:
Section 5). The m= line MUST be followed immediately by a "c=" line, as specified <del> in RFC4566, Section 5.7.  Again, as no candidates have yet been gathered, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </del> <ins> in RFC4566, Section 5.7.  Again, as no candidates are available yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0", as defined in I-D.ietf-ice-trickle, Section 5.1. </ins> If the offer supports bundle, all m= sections to be bundled must use the same ICE credentials and candidates; all m= sections not being

Discussion:
NAME I fixed this.
Section 5.2.1 CreateOffer "given that no candidates have yet been gathered" - when people remember the pre-gathered candidate pool, this can be confusing. Suggest adding a note at the top of this section saying that CreateOffer doesn't cause candidate gathering and does not take candidates from the pre-gathered pool, and thus, no candidates are available at the initial call to CreateOffer. All subsequent references to "no candidates have yet been gathered" in this section should be replaced with "no candidates are available". This also affects section 5.3.1 CreateAnswer.
lgtm