jiebi/CodeConvo huggingface dataset:
Change:
12.4.3.1. <del> The sender of a Commit message is responsible for sending a single Welcome message to all the new members added via Add proposals.  The Welcome message provides the new members with the current state of the group after the application of the Commit message.  The new </del> <ins> The sender of a Commit message is responsible for sending a Welcome message to each new member added via Add proposals.  The format of the Welcome message allows a single Welcome message to be encrypted for multiple new members.  It is up to the committer to decide how many Welcome messages to create for a given Commit.  The committer could create one Welcome that is encrypted for all new members, a different Welcome for each new member, or Welcome messages for batches of new members (according to some batching scheme that works well for the application).  The processes for creating and processing the Welcome are the same in all cases, aside from the set of new members for whom a given Welcome is encrypted. The Welcome message provides the new members with the current state of the group after the application of the Commit message.  The new </ins> members will not be able to decrypt or verify the Commit message, but will have the secrets they need to participate in the epoch initiated by the Commit message. <del> In order to allow the same Welcome message to be sent to all new </del> <ins> In order to allow the same Welcome message to be sent to multiple new </ins> members, information describing the group is encrypted with a symmetric key and nonce derived from the "joiner_secret" for the new epoch.  The "joiner_secret" is then encrypted to each new member

Discussion:
This initial effort tweaks the sections that talk about generating and processing Welcome messages. There might be other references to a single Welcome per Commit that should be amended for clarity. Someone should audit for those before we merge this PR.
From my reading, it looks like the creator of an epoch must send the exact same message to each new user. However, in some systems, it is more efficient to send a different message to each user, only containing the intended for them, rather than the for all new members. As far as I can tell, no changes are required on the recipient side. I'm running some performance testing, trying to add thousands of members at a time, and the messages are hundreds of kilobytes large. In a federated environment, this could be copied to multiple servers, with the vast majority of that being unnecessary data.
Good point NAME I filed . In the case, you would do something like send a Welcome per home server?
Thanks. With the way that Matrix currently works, it would probably be best to send a separate message per user, since the current endpoint for sending messages directly to devices requires specifying the message separately for each recipient, and implementations (AFAIK) currently don't do deduplication. In the future, it might be possible to do it differently.
NAME shouldn't ResumptionPSKUsage include (255)? enum { reserved(0), application(1), reinit(2), branch(3), (255) } ResumptionPSKUsage;
Fixed in
Change:
The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. <del> 3.4.8.2.4. </del> <ins> 3.4.7.2.4. </ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and

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:
least one RTT and congestion control will also be reset after path migration.  Therefore migration usually has a performance impact. <del> QUIC probing packets, which cannot carry application data, can be sent on multiple paths at once.  Probing packets can be used to perform address validation, measure path characteristics as input for the switching decision, or prime the congestion controller in preparation for switching to the new path. </del> <ins> QUIC probing packets, which can be sent on multiple paths at once, are used to perform address validation as well as measure path characteristics as input for the switching decision.  Probing packets cannot carry application data but may contain padding frames. Endpoints can use information about their receipt as input to congestion control for that path.  Applications could use information learned from probing to inform a decisions to switch paths. </ins> Only the client can actively migrate in version 1 of QUIC.  However, servers can indicate during the handshake that they prefer to

Discussion:
addresses
The text says: “or prime the congestion controller in preparation for switching to the new path.” what does prime mean? and which section explains this function in the QUIC spec?
The idea here is that you can already e.g. estimate RTT or even open the congestion window before you switch. There was already some discussion previously (seePR ) if we want to have this in the document or say more or less. Maybe a question to the rest of the wg (in the next meeting)...?
Unsure about this in this ID: Isn't that suggesting a transport extension/mechanism update... rather than the applicable use?
I don't think it needs an extension. It can simply be done by the client. It's definitely not appropriate to specify a concrete algorithm in this document but it's just listed as one of the things that padding can be used during mitigation.
I'm really unsure about why text about priming is here and where the advice is located. I don't dispute that it can be done, or even that if done appropriately it can help, however it could also be done in a way that might also hinder. If PR 122 removes this word, then this topic can be discussed elsewhere in RFCs.
NAME PR was already merged a long time ago. I was just point at it to say that there has been previous discussion. As the label indicates, we plan to bring the for discussion to the meeting.
CC priming seems like an issue entirely internal to the QUIC implementation. Why should applications know or care about it? I suggest we simply delete this.
I like NAME suggestion.
is my proposal. It doesn't talk about priming/pre-heating anymore but it says what's possible and why this could be interesting for an application.
PR was merged.
Phrasing suggestion.
Change:
resultant shared secret as the premaster secret.  All ECDH calculations are performed as specified in alg_computes. <del> Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used elsewhere in the certificate chain.  (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices.  However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.) </del> <ins> This specification does not impose restrictions on signature schemes used anywhere in the certificate chain.  The previous version of this document required the signatures to match, but this restriction, originating in previous TLS versions is lifted here as it had been in RFC 5246. </ins> 3.

Discussion:
TLS 1.1 and earlier required the signature algorithm in the certificate to match that of the public key. TLS 1.2 removed this restriction. Since RFC 4492 predated TLS 1.2 it reflected the same restriction. Here we remove it.
Change:
tcpcrypt Pre-Shared Key Import: Either the handshake protocol or the <del> application directly can supply pre-shared keys for the record protocol use for encryption/decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. </del> <ins> application directly can supply pre-shared keys for use in encrypting (and authenticating) communication with a peer. </ins> <del> Explicit import: QUIC, ESP, OpenVPN </del> <ins> TLS DTLS QUIC ESP IKEv2 OpenVPN tcpcrypt </ins> <del> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard </del> <ins> MinimalT </ins> <del> Non-importable: CurveCP </del> <ins> WireGuard </ins> 5.2.

Discussion:
Oh, and just double-checking: For PSK Export, SRTP and QUIC are a "No"? Because the old text said "TLS (for QUIC), DTLS (for SRTP)".
Yeah, I think that since QUIC and SRTP themselves don't export, but just use the export from inner protocols, this makes sense as is.
Comment from Ekr's review of -10: I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated.
NAME can you help on this one?
Ping NAME
We can do this for the export side of things, too.
Fixed in .
Thanks, looks good! Just suggesting one tweak in the wording for the import text.
Change:
these missing blocks is as follows: The token to use for the response SHOULD be the token that was used <del> in the highest block number received so far with the same Request-Tag </del> <ins> in the last block number received so far with the same Request-Tag </ins> value.  Note that the use of any received token with the same <del> Request-Tag would work, but providing the one used in the highest </del> <ins> Request-Tag would work, but providing the one used in the last </ins> received block number will aid any troubleshooting.  The client will use the token to determine what is the previously sent request to obtain the Request-Tag value to be used.

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:
Trust Anchor built in: from full multi-level WebPKI to the single self-signed certificate used by the Cloud Registrar.  There are many tradeoffs to having more or less of the PKI present in the Pledge, <del> which is addresses in part in I-D.richardson-t2trg-idevid- considerations in sections 3 and 5. </del> <ins> which is addresses in part in I-D.irtf-t2trg-taxonomy-manufacturer- anchors in sections 3 and 5. </ins> 7.4.

Discussion:
This reflects that all YANG activity has been rolled up into draft-ietf-anima-rfc8366bis.
the YANG contains "RFC XXXX: Voucher Profile for Cloud redirected Devices" - it seems the name needs updating and there should be an RFC ednote here saying the reference is "this RFC". Correct?YANG contains this: description "Base the constrained voucher upon the regular one"; This looks like a copy/paste leftover from constrained-voucher; correct that it should be modified? (Would this also bump the YANG version and date then?) YANG description for leaf "est-domain" does not explicitly say the word "EST server" which I think it should. So this URI directs to the EST server in the owner's URL YANG support the use case of combining the voucher-constrained format (that extends base voucher) and the voucher-redirected format (from current draft) ? Would that require yet another new YANG module?
Also, the YANG extensions need to move to RFC8366bis! URL
Change:
Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. <del> Imported Identity: The identity of an Imported PSK as sent on the wire. </del> <ins> Imported Identity: A sequence of bytes used to identify an IPSK. </ins> 4.

Discussion:
This isn't perfect either, but it concentrates on the functional side, namely that we use a sequence of bytes to identify PSKs.
Change:
amount of data. Implementations MUST support buffering at least 4096 bytes of data <del> received in out of order CRYPTO frames.  Endpoints MAY choose to </del> <ins> received in out-of-order CRYPTO frames.  Endpoints MAY choose to </ins> allow more data to be buffered during the handshake.  A larger limit during the handshake could allow for larger keys or credentials to be exchanged.  An endpoint's buffer size does not need to remain

Discussion:
NAME should merge this.
I'm assuming that you checked the others, and therefore surprised we got the others right.
Change:
measurement and use of the latency spin bit is further discussed in QUIC-MANAGEABILITY. <del> The spin bit is an OPTIONAL feature of this version of QUIC.  A QUIC stack that chooses to support the spin bit MUST implement it as specified in this section. </del> <ins> The spin bit is an OPTIONAL feature of this version of QUIC.  An endpoint that does not support this feature MUST disable it, as defined below. </ins> Each endpoint unilaterally decides if the spin bit is enabled or disabled for a connection.  Implementations MUST allow administrators

Discussion:
Rob Wilton said:
This was talked about on the IESG telechat 2020-01-07. The action item is to add clarity for what an endpoint that does not support the spin bit should do. Note that this is distinct from an endpoint that supports spin bit but chooses to disable it. The discussion leaned towards an editorial change to the text in Section 17.4, for instance in paragraph 3. IIUC no other changes are needed to resolve this discuss, but we should confirm this via email.
I don't get this. The following text seems abundantly clear: Or is it this? Where we don't say that optional == disable it? If that is all, I'm going to hold my tongue.
NAME -- this is good now. Thanks!
Change:
The algorithms defined in this document can be found in x-table-hmac. <del> Some recipient algorithms carry the key while others derive a key from secret data.  For those algorithms that carry the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the underlying hash function.  For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. </del> <ins> Some recipient algorithms transport the key, while others derive a key from secret data.  For those algorithms that transport the key (such as AES Key Wrap), the size of the HMAC key SHOULD be the same size as the underlying hash function.  For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. </ins> When using a COSE key for this algorithm, the following checks are made:

Discussion:
Add in response for IANA review on all documents SecDir review by Nancy on -algs GenArt review on -struct
Change:
case, it does not make any changes to the TLS messages, but just blindly forwards them. <ins> If the ClientHello is the result of a HelloRetryRequest, servers MUST abort the connection with an "illegal_parameter" alert if any of the ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, ClientEncryptedSNI.record_digest, or decrypted ClientESNIInner values from the second ClientHello do not match that of the first ClientHello. </ins> 5.3. A server operating in Shared Mode uses PaddedServerNameList.sni as if

Discussion:
Since the client's ESNI key share doesn't change across CHs in response to a HRR, the same AEAD IV would be used to encrypt/decrypt two different messages. This is an attempt to fix that, while also specifying the server-side HRR behavior. (Basically, check that the ESNI contents have not changed.)
Nice catch, Would it make more sense to instead use the KeyShare as a salt in the HKDF?
Or you could include the handshake transcript up to, but not including, the ClientHello. That is the empty string before HRR< but something else after.
That is a little iffy with cookie-only HelloRetryRequests. Those don't change the ClientHello key shares list, so the client would derive the same key + nonce pair. The client would also use the same plaintext so it's fine, but it seems an unnecessarily fragility.
Agreed. I think I prefer the "new DH" version.
Thank you for the changes! LGTM.
Change:
structure, and the ability to search based on patterns ("wildcard searches") as well as specific data elements. <del> Full Vs.  Partial Updates: The data model SHOULD include the </del> <ins> Full vs. Partial Updates: The data model SHOULD include the </ins> ability to allow providers of data to provide the data as a whole, or when updates occur.  For example, a consumer can request a full update on initial engagement, then request to receive deltas

Discussion:
Updates to address 3 of four open issues
Version -09 The document is not consistent if the character following the pithy title is capitalized. A pass needs to be made to fix this.
Hi Jim, I only found 1 straggler in IM-URL there are others please let me know so I can fold it into the -10 draft. Thanks, Nancy
Fixed in Pull request
-version 09 There are two nits that needs to be resolved. Missing 2119 boilerplate Reference to RFC 3444 exists, but is not referred to.
Hi Jim, Will fix in -10 draft..... Thanks, Nancy
Fixed in Pull request
Change:
packets into the network.  If a sender is designed to rely on the timing of peer acknowledgments ("ACK clock"), delaying acknowledgments can cause undesirable bursts of data into the <del> network.  A sender MUST limit such bursts.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can either employ pacing or cause a receiver to send an acknowledgement for at least each initial congestion window of received data. </del> <ins> network.  In keeping with Section 7.7 of QUIC-RECOVERY, a sender can either employ pacing or limit bursts to the initial congestion window. </ins> 8.3.

Discussion:
Another attempt to Removes an unnecessary MUST.
This draft says: RFC9002 only has a SHOULD on pacing. Is it appropriate to change this require in this draft? If not, no normative language should be used here at all.
Change:
zone that have changed (described in RFC1995).  Many systems use non-standard methods for zone transfer outside the DNS protocol. <ins> See "Secondary server". </ins> "An authoritative server which uses zone transfer to retrieve the zone" (Quoted from RFC1996, Section 2.1).  Secondary servers are also discussed in RFC1034.  RFC2182 describes secondary servers in

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:
Description, and Reference, where Value is an integer and the other columns are text strings. <del> 9.11. </del> <ins> 9.12. </ins> The IANA Registries established in this document is defined as "Expert Review".  This section gives some general guidelines for what

Discussion:
Discussion today in COSE on how to do RPK by value in EDHOC. Suggestions to send a COSE_Key or a C509. Additional suggestion from Carsten to use CWT. Several issues in the old GitHub on CWTs, that were not transfered to the new GitHub: URL URL URL Discussion to transfer CWT in kid, in Auxilery data, and as COSE header parameter. Transfering CWT is related to issues , , ,
I made a pull request for this URL I think it is essential that EDHOC supports CWT. CWTs are much more flexible than X.509 / C.509. I think both are needed. The need for CWT has been discussed since 2016. I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them. In Aux Data, in COSE header parameter, or in the kid bstr. For some reason nothing was ever specified. TLS WG is discussing to add support for CWT. URL I think certificates and CWT needs to be included, I am not sure that we need a different format for RPK. Likely CWT or C509 can be used for this purpose.
I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed. My current thoughts. CWT needs to be supported in EDHOC. Most things in CWT is optional, it is likely an optimized enough format for the oportunistic / TOFU use case of "RPK". CWT is also very flexible. When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes. CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys. We should at least remove the new subjectname from the COSEKey part in the EDHOC document. CWT and C509 can be used when subject name is needed. Does "Raw" COSE_Keys that are not CWT even need to be supported? Or would CWT / C509 / X.509 be enough
This change has now been done in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
This has now been addressed.