jiebi/CodeConvo huggingface dataset:
Change:
based on the origin of flow mapping related information (management plane or control plane). <ins> The following summarizes the set of information that is needed to configure TSN over DetNet MPLS: TSN related configuration information according to the TSN role of the DetNet MPLS node, as per IEEE8021Q, IEEE8021CB and IEEEP8021CBdb. DetNet MPLS related configuration information according to the DetNet role of the DetNet MPLS node, as per I-D.ietf-detnet-mpls. App-Flow identification information to map received TSN Stream(s) to the DetNet flow.  Parameters fo TSN stream identification are defined in IEEE8021CB and IEEEP8021CBdb. This information MUST be provisioned per DetNet flow. </ins> MPLS DetNet Edge nodes are member of both the DetNet domain and the connected TSN network.  From the TSN network perspective the MPLS (DetNet) Edge node has a "TSN relay node" role, so TSN specific

Discussion:
Fixing conformance language Adding more definite references for TSN functions (i.e., Clause numbers)
Change:
The plaintext is the concatenation of TLSPlaintext.fragment, TLSPlaintext.type, and any padding bytes (zeros). <del> The AEAD output consists of the ciphertext output by the AEAD </del> <ins> The AEAD output consists of the ciphertext output from the AEAD </ins> encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will

Discussion:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.
Change:
identified by five-tuple when the address and port of one of the endpoints changes; e.g. due to NAT rebinding or server IP address migration.  An observer keeping flow state can associate a connection <del> ID with a given flow, and can associate a known flow with a new flow when when observing a packet sharing a connection ID and one endpoint address (IP address and port) with the known flow. </del> <ins> ID, if present, with a given flow, and can associate a known flow with a new flow when when observing a packet sharing the same connection ID in the same direction between client and server and sharing one endpoint address (IP address and port) with the known flow. </ins> However, since the connection ID may change multiple times during the lifetime of a flow, and the negotiation of connection ID changes is

Discussion:
This is branched of . NAME said: "However, it needs to specify that the connection ID association needs to be directional. Maybe that is assumed, but it should be stated. And it needs to say that this is unlikely to apply when the connection ID is empty."
NAME I created PR . Does that address this point sufficiently?
Change:
WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as <del> defined in I-D.ietf-core-block. </del> <ins> defined in RFC7959. </ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping).

Discussion:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.
Change:
document.  This document provides a container format for carrying the capability and its context information. <del> 3.2. </del> <ins> 3.3. </ins> The root node could advertise the set of capabilities it supports in the DIO message.  A node could take advantage of the knowledge that

Discussion:
Modified Capabilities section.
NAME - the complete file seems to be changed! Is it because of the ^M issue? Better you can close this PR and raise another one only with the changes. Thanks
Comments for the PR.
Change:
3. <del> This specification uses the tls_flags extension defined in I-D.ietf- tls-tlsflags to allow a client and a server to negotiate support for this extension. </del> <ins> The use of RRC is negotiated via the "rrc" DTLS-only extension.  On connecting, the client includes the "rrc" extension in its ClientHello if it wishes to use RRC.  If the server is capable of meeting this requirement, it responds with a "rrc" extension in its ServerHello.  The "extension_type" value for this extension is TBD1 and the "extension_data" field of this extension is empty.  The client and server MUST NOT use RRC unless both sides have successfully exchanged "rrc" extensions. </ins> <del> The RRC flag is assigned the value (TBD1) and is used in the ClientHello (CH) and the ServerHello (SH). </del> <ins> Note that the RRC extension applies to both DTLS 1.2 and DTLS 1.3. </ins> 4.

Discussion:
Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.
Change:
format-key-config shows a single . <del> The definitions for the identifiers used in HPKE and the semantics of the algorithms they identify can be found in HPKE.  The "Npk" parameter is determined by the choice of HPKE KEM, which can also be found in HPKE. </del> <ins> That is, a consists of the following fields: </ins> 3.2.

Discussion:
We previously only had figures, which are sort of illustrative only, they don't really work as normative specification. The content of these really needs to have words that describe what was intended. The definition for the request was already sort-of there, so what I've added is a tiny bit repetitive, but I think that it's OK in this case to have the descriptions at different levels of specificity. The big error here was that the length field in the key configuration was impossible to decipher. We never said whether it was length in bytes (what has been implemented) or length in number of items. The bounds on the field length were not helpful here as they were not correct in any way. I've corrected this value, but would appreciate a sanity check. No one identified this as a problem in the reviews. I guess that means that the QUIC format is clear and understandable. Maybe I should have made it less so. The TLS format is consistently misunderstood, which I used to think was a disadvantage...
Change:
(ICANN).  The names operational community selects the IANA Functions Operator for the global DNS root zone.  At the time this document is published, that operator is Public Technical <del> Identifiers (PTI).  The name servers that serve the root zone are provided by independent root operators.  Other zones in the global DNS have their own policies for administration. </del> <ins> Identifiers (PTI).  (See <https://pti.icann.org/> for more information about PTI operating the IANA Functions.)  The name servers that serve the root zone are provided by independent root operators.  Other zones in the global DNS have their own policies for administration. </ins> Types of data that can be associated with names -- A name can have zero or more resource records associated with it.  There are

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:
11.1. <ins> Rewrite the Identity section in more conventional offer/answer format. Clarify rules on changing identities. 11.2. </ins> Update discussion of IdP security model Replace "domain name" with RFC 3986 Authority

Discussion:
NAME I looked at the deletion issue and I don't think it's worth leaving it in as an exception, because you'd have to DTLS re-handshake anyway.
Change:
Definition: <del> 3.5. Importance: Extra This event indicates that the estimated Path MTU was updated.  This happens as part of the Path MTU discovery process. </del> 4. TBD

Discussion:
Updates as that had some problems: used instead of for CDDL type in some of the definitions (not in others)... Made a separate category for the event. It's debatable imo whether it belongs in or , but it shouldn't be its own thing. In general, I feel was approved/merged too soon and this type of things should be checked for future PRs of a similar type.
Changes look good to me. First of all, sorry for messing up the type name. I'm not sure I agree that it was merge too soon though, was open for 3 months, and was approved by one of the editors. Sometimes it's better to make progress instead of not moving at all, even if some cleanup is necessary later.
NAME no problem, I mess up way worse than that :) Let me rephrase that to just "approved" too soon then, instead of "merged" too soon (which is again perfectly understandable with Lucas not used to watching for that type of issue, just wanted to indicate future approvals should).
From the discussion in , it seems better to keep this consistent with other events. Also noticed I forgot to prefix the event with Connectivity and add it to the CDDL list on the bottom...
Sorry if that's a stupid question, but why do we have an and a field here? I thought you can only set it once. Originally posted by NAME in URL
This is a fair question. This is most likely a copy-paste from one of the events (can't find evidence that this was once called StreamTypeUpdated though...) For updates this makes sense, but if the StreamType is only ever set once after becoming known, it would be better to change the definition to e.g., (note, is from ) :
Change:
places a limit on the maximum size of DATAGRAM frames, that limit can be further reduced by the max_packet_size transport parameter and the Maximum Transmission Unit (MTU) of the path between endpoints. <del> DATAGRAM frames cannot be fragmented, therefore application protocols need to handle cases where the maximum datagram size is limited by other factors. </del> <ins> DATAGRAM frames cannot be fragmented; therefore, application protocols need to handle cases where the maximum datagram size is limited by other factors. </ins> 5.1.

Discussion:
could also do s/,/; but whatever.
I'm not qualified to handle this level of copy-editing, this sounds like something best suited for the RFC editor.
Change:
client may fetch a chain of CA certificates that could be used to validate the certificate in the original resource. <del> The "directory" link relation is present on all resources other than the directory and indicates the directory URL. </del> <ins> The "index" link relation is present on all resources other than the directory and indicates the directory URL. </ins> The following diagram illustrates the relations between resources on an ACME server.  For the most part, these relations are expressed by

Discussion:
As they are all fulfilled by the endpoint and are unnecessary. The relation is removed as the SCT will be provided by the CA via the certificate or a OCSP response, if it doesn't provide these then the client should be able to retrieve the SCT itself from the logs it expects to find the certificate in (or submit it itself). Also removes a paragraph about Certificate Transparency from the 'Downloading the Certificate' section as it is irrelevant to the section and discusses operations of the CA unrelated to the ACME protocol. Additionally changes the relation which is not registered with a URI extension using the ACME URN namespace .
Looks good. Was posted on the list two weeks ago, with no objections, so merging.
Change:
Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that issuance and redemption events be separated over time, <del> such as through the use of tokens with an empty redemption context, or be separated over space, such as through the use of an anonymizing proxy when connecting to the Origin. </del> <ins> such as through the use of tokens that correspond to token challenges with an empty redemption context (see redemption), or be separated over space, such as through the use of an anonymizing proxy when connecting to the Origin. </ins> 4.2.

Discussion:
The definition of the redemption/issuance/attestation contexts seem to exist primarily to support the different unlinkability goals in the document. Let's take the redemption one, which is defined as: A digression on perspective Note that "Client visible" is probably ambiguous here; it could mean information about the client that is visible (though to whom?) or information that is visible to the client. This suggests that your goal is establish a point of reference or perspective for these: in this case, the relevant perspective is that of an Origin. But this was not my main point... The corresponding unlinkability definition says: This is a little confusing, because you might conceive of the defines the context as enclosing a single interaction between the Client and Origin, but this implies that a context encompasses multiple interactions with either the same client or different clients (all of which are indistinguishable). That makes the definition of the context seem like it lacks something. Does this refer to the information that is provided within that context that might be used to identify a client, from the perspective of the server? Finally, there is mention of an "an empty redemption context" in Section 3.1. I had no idea how to interpret this claim. Does empty refer to the set of clients? The set of interactions? The information provided in that context?
The empty redemption context comment is talking about the field of the challenge being empty / zero-length.
Basically, yeah, this is the idea. Perhaps framing it this way would be a more clear description. NAME regarding "empty redemption context," maybe we just say "an empty token challenge redemption context," or something, to make it clear that this is referring to the challenge field described in Section 3.1?
Change:
10. <del> IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in RFC5246, for connection_id(TBD1) as described in the table below.  IANA is requested to add an extra column to the TLS ExtensionType Values registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. </del> <ins> This document requests three actions by IANA. 10.1. IANA is requested to add an extra column to the "TLS ExtensionType Values" registry to indicate whether an extension is only applicable to DTLS and to include this document as an additional reference for the registry. 10.2. IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, for connection_id(TBD1) as described in the table below. </ins> Note: The value "N" in the Recommended column is set because this extension is intended only for specific use cases.  This document

Discussion:
Tom Petch's review: URL
URL Some editorial quirks s.2 lacks the boiler plate of RFC8174 s.3 I found this unclear until I had understood it all (or perhaps I do not understand it) "URL again, alternately, to use a zero-length CID)." This suggests that a zero length CID is valid in Application Data which later text seems to contradict; otherwise I cannot see what this is saying. " If DTLS peers have negotiated the use of a CIDs using the ClientHello and the ServerHello messages " arguably sending a zero CID and receiving a zero CID is a successful Hello negotiation perhaps " If DTLS peers have negotiated the use of a non-zero CID in at least one direction, using the ClientHello and the ServerHello messages" "The DTLS peers determine whether incoming and outgoing messages need.." seems not to cater for unidirectional CIDs; perhaps "The DTLS peers determine whether incoming or outgoing, or both, messages need.. " s.4 /always recieve CIDs/always receive CIDs/ s.5.1 "the with Encrypt-then-MAC processing described in [RFC7366]." I do not understand why 'with' is needed s.5.2 ditto s.8 /this aspects SHOULD refuse/these aspects SHOULD refuse/ s.10 I would find this clearer as three sections for the three IANA actions new column for ExtensionType new value for ExtensionType new value for ContentType " IANA is requested to allocate an entry to the existing TLS "ExtensionType Values" registry, defined in [RFC5246],.." well no; whatever you think of RFC8447 the name has changed " IANA is requested to allocate an entry to the existing "TLS ExtensionType Values" registry, defined in [RFC5246],.." or, if you are picky (which I am not), IANA is requested to allocate an entry to the existing "TLS "ExtensionType Values" registry, defined in [RFC5246], and renamed by RFC8447 An extra column is added but I cannot see what value should be placed in that column for existing entries. "The tls12_cid ContentType is only applicable to DTLS 1.2." Good information but I struggle to see what IANA will do with it; I see nowhere for it to go. Tom Petch >
Change:
For example, suppose there is a group with four members: <del> If member B subsequently generates a Commit based on a secret </del> <ins> If member B subsequently generates an UpdatePath based on a secret </ins> "leaf_secret", then it would generate the following sequence of path secrets: <del> After the Commit, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: </del> <ins> After applying the UpdatePath, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: </ins> <del> After performing these operations, the generator of the Commit MUST delete the leaf_secret. </del> <ins> After performing these operations, the generator of the UpdatePath MUST delete the leaf_secret. </ins> 5.5. <del> After generating a Commit as described in the prior section, the generator of the Commit must broadcast this update to other members of the group, who apply it to keep their local views of the tree in sync with the sender's.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these values to update their view of the tree, aligning their copy of the tree to the sender's. To perform an update for a path (a Commit), the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </del> <ins> After generating fresh key material and applying it to ratchet forward their local tree state as described in the prior section, the generator must broadcast this update to other members of the group in a Commit message, who apply it to keep their local views of the tree in sync with the sender's.  More specifically, when a member commits a change to the tree (e.g., to add or remove a member), it transmits a UpdatePath message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. To transmit this update, the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </ins> The public key for the node

Discussion:
This PR updates two sections to reference generating and sending an message, as not all Commits transmit fresh key material (as discussed in ). This PR also includes light editorial edits for clarity and adds detail around the steps to perform an update. Section 7.7 currently says that "each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path", but section 10.2 says that an UpdatePath is optional. I can update 7.7 as well, if 10.2 is correct.
I went ahead and changed Section 7.7 to specify that MLS commits may optionally transmit updates for consistency with Section 10.2
Change:
the sender_data_key from the keyschedule.  It is encoded as an object of the following form: <ins> MLSSenderData.sender is assumed to be a "member" sender type.  When constructing an MLSSenderData from a Sender object, the sender MUST verify Sender.sender_type is "member" and use Sender.sender for MLSSenderData.sender. </ins> The Additional Authenticated Data (AAD) for the SenderData ciphertext computation is its prefix in the MLSCiphertext, namely:

Discussion:
Action item from Singapore: it seems better to specify directly in the message if we have an external sender instead of using reserved ranges.
Here's the Weekly Digest for : - - Last week 3 issues were created. Of these, 0 issues have been closed and 3 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 7 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 3 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustinsilhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :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 .
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged.

:purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - 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:
HelloRetryRequest and otherwise abort the handshake with an "illegal_parameter" alert. <ins> The value of selected_version in the HelloRetryRequest "supported_versions" extension MUST be retained in the ServerHello, and a client MUST abort the handshake with an "illegal_parameter" alert if the value changes. </ins> 4.2. A number of TLS messages contain tag-length-value encoded extensions

Discussion:
Issue 1: supportedversions is required in TLS 1.3 SH. Issue 2: supportedversions.selected_version must be identical in HRR and SH
NAME please submit a PR to add yourself to acknowledgements
Thanks for the fixup.