jiebi/CodeConvo huggingface dataset:
Change:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"

Discussion:
6.3.1. <del> Content to be encrypted is encoded in an PrivateContentTBE structure. </del> <ins> Content to be encrypted is encoded in a PrivateContentTBE structure. </ins> The "padding" field is set by the sender, by first encoding the content (via the "select") and the "auth" field, then appending the

contains an object of the following form, with the values used to identify the key and nonce: <del> When decoding an PrivateContentTBE, the application MUST check that </del> <ins> When decoding a PrivateContentTBE, the application MUST check that </ins> the FramedContentAuthData is valid. It is up to the application to decide what "authenticated_data" to

are represented as absolute times, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  Applications MUST define a maximum total lifetime that is acceptable for a LeafNode, and reject any <del> LeafNode where the total lifetime is longer than this duration. </del> <ins> LeafNode where the total lifetime is longer than this duration.  In order to avoid disagreements about whether a LeafNode has a valid lifetime, the clients in a group SHOULD maintain time synchronization (e.g., using the Network Time Protocol RFC5905). </ins> In the case where the leaf node was inserted into the tree via a Commit message, the "parent_hash" field contains the parent hash for

the client, e.g., a proposal, a commit, or a ratchet tree of the group the client is joining, it is RECOMMENDED that the client verifies that the current time is within the range of <del> the "lifetime" field. </del> <ins> the "lifetime" field.  (This check is not mandatory because the LeafNode might have expired in the time between when the message was sent and when it was received.) </ins> Verify that the extensions in the LeafNode are supported by checking that the ID for each extension in the "extensions" field

If encoding as PublicMessage, compute the "membership_tag" value using the "membership_key". <del> If encoding as an PrivateMessage, encrypt the message using the </del> <ins> If encoding as a PrivateMessage, encrypt the message using the </ins> "sender_data_secret" and the next (key, nonce) pair from the sender's handshake ratchet.
Change:
I forgot to update the changelog before I published -03. We should add that to the review criteria. This will at least fix it for -04.

Discussion:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-03 Added ciphersuites and signature schemes (*) Re-ordered fields in UserInitKey to make parsing easier (*) Fixed inconsistencies between Welcome and GroupState (*) Added encryption of the Welcome message (*) </ins> draft-02 Removed ART (*)
Change:
URL Thanks for working on this interesting topic. Thanks for Gorry fairhost for this TSVART review. I have few comments, which I believe if addressed will improve the document. - There is a mismatch between intended status of this spec (PS) and what in the doc header (Informational). I see Lars already have a discuss on it, so supporting it. - The specification says the UPDATE messages SHOULD be periodically sent and expects the applications to decided on the period between UPDATE messages. As I can see there are multiple implementations, can't we also recommend some guidelines and considerations on how to select the period? In some discussions I saw we were talking about hours and months.. - it says - "In general, however, applications should take care that they do not send MLS messages at a rate that overwhelms the transport over which messages are being sent." I am not sure I understand what "overwhelms the transport" means. Are we talking about the congestion control or bandwidth estimation part of transport protocols? Usually the application have no or very vague information about the internal protocol states, in that case how the applications are expected to take care of this? are we suggesting some interaction application rate control?

Discussion:
Update messages SHOULD be sent at regular intervals of time as long as the group is active, and members that don't update SHOULD eventually be removed from the group.  It's left to the application <del> to determine an appropriate amount of time between Updates.  In general, however, applications should take care that they do not send MLS messages at a rate that overwhelms the transport over which messages are being sent. </del> <ins> to determine an appropriate amount of time between Updates.  Since the purpose of sending an Update is to proactively constrain a compromise window, the right frequency is usually on the order of hours or days, not milliseconds. The MLS architecture recommends that MLS be operated over a secure transport (see Section 7.1 of I-D.ietf-mls-architecture).  Such transport protocols will typically provide functions such as congestion control that manage the impact of an MLS-using application on other applications sharing the same network.  Applications should take care that they do not send MLS messages at a rate that will cause problems such as network congestion, especially if they are not following the above recommendation (e.g., sending MLS directly over UDP instead). </ins> Members are removed from the group in a similar way, as shown in remove-flow.  Any member of the group can send a Remove proposal
Change:
Also adds a draft-18 section to cover any edits between now and the next I-D.

Discussion:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-18 Make the document standards track Make the ratchet tree non-malleable (*) Use ExpandWithLabel to derive welcome key (*) Change MLS-Exporter label from "exporter" to "exported" (*) Loosen chain requirements (*) Clarify transcript hash initialization GREASE for MLS registries Move pseudocode out of KDFLabel definition. Rename PrivateContentTBE to PrivateMessageContent Fix DecryptWithLabel argument order for Welcome Responses to IESG reviews Describe varint length check more clearly draft-17 Rename MLSCiphertext and MLSPlaintext to PrivateMessage and PublicMesssage respectively (*) Add label and context to public-key encryption (*) Include leaf index in LeafNodeTBS for better parent-hash guarantees (*) Make ProtocolVersion two bytes (*) Clarify group creation (*) Validate additional properties of unmerged leaves (*) Clarify that the AS needs to vet the signature key Remove "MLS" prefix on structs Credentials should be replaced before expiring Add a section discussing the security of the sender data protection Minor fixes in presentation language. Allow multiple welcomes per commit Remove reference to BasicCredential. Client aware of its own removal in group Create IANA registries for signature and export labels Complete IANA media type registration Make more vendor code points available Update Recommended column definition to match 8447bis Responses to early ARTART review Responses to early OPSDIR review Responses to early TSV-ART review draft-16 Fix GroupInfoTBS (*) Make reference to h2 informative </ins> draft-15 Include ciphersuite in group context (*)
Change:
The current text on initializing the transcript hash is ambiguous. In particular, it never tells you how to compute the first . This PR provides clearer initialization instructions, and a figure that summarizes the transcript hash evolution [2]. [1] To be clear, I think the intent is clear and all current implementations are consistent. The text is just bad. [2] The diagram is a little over-the-top elaborate. I would be OK removing it :)
I generally like the diagram, but the intersection between , and is not clear to me. What is going where? Also shouldn't and also get numbers? And what's the different between the and suffix?
OK, I rotated the diagram 90 degrees and rejiggered things to hopefully be clearer. It now should just barely fit in the .TXT format. What do folks think?
Beautiful!

Discussion:
former is used to update the confirmed transcript hash and the latter to update the interim transcript hash. <del> In this notation, "InterimTranscriptHashInput_[epoch]" and "ConfirmedTranscriptHashInput_[epoch+1]" are based on the Commit that initiated the epoch with epoch number "epoch".  (Note that the "epoch" field in this Commit will be set to "epoch - 1", since it is </del> <ins> In this notation, "ConfirmedTranscriptHashInput_[epoch]" and "InterimTranscriptHashInput_[epoch]" are based on the Commit that initiated the epoch with epoch number "epoch.  (Note that the "epoch"field in this Commit will be set to "epoch - 1`, since it is </ins> sent within the previous epoch.) <ins> The transcript hash "ConfirmedTranscriptHashInput_[epoch]" is used as the "confirmed_transcript_hash" input to the "confirmation_tag" field for this Commit.  Each Commit thus confirms the whole transcript of Commits up to that point, except for the latest Commit's confirmation tag. </ins> 8.3. In addition to initializing a new epoch via KDF invocations as
Change:
As discussed in mlswg/mls-implementations . Currently, there are several valid for one tree: the sender can choose ("SHOULD") to omit some (but not all) blank nodes at the right of the tree. This PR changes this: the sender MUST omit all the blank nodes at the right of the tree, and the receiver MUST check that it was done correctly (i.e., the last node of is non-blank).
Right now, the signature on an MLSPlaintext includes the GroupContext for the group. If we are going to allow Add proposals signed by the new member, then this will need to change, because the new member doesn't know the GroupContext. My preference would be to simply remove the GroupContext from the plaintext. The Group ID is already included, so copy/paste protection can be added that way. The other elements of the GroupContext effectively overlap with the Epoch that is already signed.
Haven't thought about this too deeply, but having the full GroupContext in MLSPlaintextTBS means that we know all the members agree on the state of the ratchet tree, the transcript, the extensions. Removing it means we would no longer have agreement on those, right?
We won't have confirmation of agreement as a result of signature verification. The question is whether that is necessary. If the MLSPlaintext was decrypted from an MLSCiphertext, for example, then the successful decryption of the MLSCiphertext implies agreement on all those things. I suppose you could also switch the signature input based on SenderType, but that seems messier.
I'm not so sure that decrypting an MLSCiphertext implies agreement, because the crypto is symmetric. A man-in-the-middle can re-encrypt but not re-sign.

Discussion:
If the tree has "2^d" leaves, then it has "2^(d+1) - 1" nodes.  The "ratchet_tree" vector logically has this number of entries, but the <del> sender SHOULD NOT include blank nodes after the last non-blank node. If a receiver encounters a vector whose length "L" is not of the form "2^(d+1) - 1", then the receiver MUST extend it to the right with blank values until it has such a length, adding the minimum number of blank values possible.  (Obviously, this may be done "virtually", by synthesizing blank nodes when required, as opposed to actually changing the structure in memory.) </del> <ins> sender MUST NOT include blank nodes after the last non-blank node. The receiver MUST check that the last node in "ratchet_tree" is non- blank, and extend it to the right until it has a length of the form "2^(d+1) - 1", adding the minimum number of blank values possible. (Obviously, this may be done "virtually", by synthesizing blank nodes when required, as opposed to actually changing the structure in memory.) </ins> The leaves of the tree are stored in even-numbered entries in the array (the leaf with index "L" in array position "2*L").  The root
Change:
This PR fixes small issues that I noticed while implementing proposal validation and fixing some external join bugs: The pseudocode for determining whether a path is required assumes that all proposals are by-reference. The PR updates the pseudocode to be more general, and also account for proposals by value. There were two references to adding a single leaf to the tree, which are updated to make clear that the tree grows by doubling, not by single leaves. There was no current requirement that an Update proposal have a distinct , so one is added.

Discussion:
"leaf_node_source" is set to "key_package". If the LeafNode appears in an Update proposal, verify that <del> "leaf_node_source" is set to "update". </del> <ins> "leaf_node_source" is set to "update" and that "encryption_key" represents a different public key than the "encryption_key" in the leaf node being replaced by the Update proposal. </ins> If the LeafNode appears in the "leaf_node" value of the UpdatePath in a Commit, verify that "leaf_node_source" is set

Identify the leaf L for the new member: if there are empty leaves in the tree, L is the leftmost empty leaf.  Otherwise, the tree is <del> extended to the right by one leaf node and L is the new leaf. </del> <ins> extended to the right as described in adding-and-removing-leaves and L is assigned the leftmost new blank leaf. </ins> For each non-blank intermediate node along the path from the leaf L to the root, add L's leaf index to the "unmerged_leaves" list

If this is an external commit, assign the sender the leftmost blank leaf node in the new ratchet tree.  If there are no blank <del> leaf nodes in the new ratchet tree, add a blank leaf to the right side of the new ratchet tree and assign it to the sender. </del> <ins> leaf nodes in the new ratchet tree, expand the tree to the right as defined in adding-and-removing-leaves and assign the leftmost new blank leaf to the sender. </ins> Update the sender's direct path in the ratchet tree as described in synchronizing-views-of-the-tree.  Define
Change:
Thanks Carsten! I'll go clear my DISCUSS :)
I see. These didn't cause a problem on my side.

Discussion:
Name: mqtt-topic-filter <del> Description/Specification: Topic Filter as defined in mqtt-defs. </del> <ins> Description/Specification: Topic Filter as defined in scope. </ins> Reference: [[This document]] (scope)

Name: mqtt-permissions <del> Description/Specification: Permissions for MQTT client.  Tperm is a string with a value either "pub" or "sub". </del> <ins> Description/Specification: Permissions for MQTT client as defined in scope.  Tperm is an array of one or more text strings that each have a value of either "pub" or "sub". </ins> <del> Reference: [[This document]] (scope ) </del> <ins> Reference: [[This document]] (scope) </ins> 8.
Change:
Let's assume we're talking about what the AS puts in the token (not the token response). That means that "cnf" always has to be present. The flow where "cnf" is only required in the symmetric case and is optional for the asymmetric case is the use of the "cnf" parameter in the token response, from AS to client.

Discussion:
of-Possession (PoP) token by default. This document follows RFC7800 for PoP semantics for JWTs (CWTs MAY <del> also be used).  The AS includes a "cnf" (confirmation) parameter to </del> <ins> also be used).  The AS includes a "cnf" (confirmation) parameter in </ins> the PoP token, to declare that the Client possesses a particular key and RS can cryptographically confirm that the Client has possession <del> of that key.  The "cnf" parameter is REQUIRED if a symmetric key is used, and MAY be present for asymmetric PoP keys, as described in I- D.ietf-ace-oauth-params. </del> <ins> of that key, as described in I-D.ietf-ace-oauth-params. </ins> Note that the contents of the web tokens (including the "cnf" parameter) are to be consumed by the RS and not the Client (the
Change:
fixed ID reference to ietf-ace-dtls-authorize doing this first so it'll build from makefile (
The correct reference is I-D.ietf-ace-dtls-authorize and not I-D.gerdes-ace-dtls-authorize.

Discussion:
Broker (RS) via the CONNECT control message after the TLS handshake. This is similar to an earlier proposal by Fremantle et al. fremantle14.  Alternatively, the token may be used for the TLS <del> session establishment as described in the I-D.gerdes-ace-dtls- </del> <ins> session establishment as described in the I-D.ietf-ace-dtls- </ins> authorize.  In this case, both the TLS PSK and RPK handshakes MAY be supported.  This may additionally require that the Client transports the token to the Broker before the connection establishment.  To this
Change:
I believe this " if you're happy with it now we're (assumed) targetting MQTT v5.0 we should refer to Clean Start acknowledge that RETAINed messages could be made irrelevant by further publishes
yes, that's much better, thanks! (see e46a8d)
Section 2.5 - The last sentence in the first paragraph could be state more clearly. Specifically there would appear to be some ambiguity on who the associated tokens are attached to. "messages as long as the publisher token for that message remains valid." Might be better.
Better working might to "the retailed message until the token for that message has expired," That avoids the question if all of the tokens have expired or just the one with the message.

Discussion:
2.5. <del> In the case of a Client DISCONNECT, due to the Clean Session flag, the Broker deletes all session state but MUST keep the retained messages.  By setting a RETAIN flag in a PUBLISH message, the </del> <ins> In the case of a Client DISCONNECT, due to the Clean Start flag (or Clean Session flag with MQTT v3.1.1), the Broker deletes all session state but MUST keep the retained messages and token expiry information.  By setting a RETAIN flag in a PUBLISH message, the </ins> publisher indicates to the Broker that it should store the most <del> recent message for the associated topic.  Hence, the new subscribers can receive the last sent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. </del> <ins> recent message for the associated topic.  Hence, new subscribers can receive the most recent message from the publisher of that particular topic without waiting for the next PUBLISH message.  The Broker MUST continue publishing each retained message until the token for that message has expired, or another RETAIN message is published on the associated topic. </ins> In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization
Change:
I added a container to report ACL violation dropped packets. I am not sure how the l3l4info is going to be used. The YANG model was fixed (I think some parens missing). Please check and let me know you agree with these changes. Thanks, Ranga

Discussion:
there is none. The MUD file permits access to a particular Internet service, but <del> the name of that service resolved to something that was not permitted. </del> <ins> the name of that service has not been resolved (or name resolution failed). </ins> The administrator overrode the recommendations in the MUD file.
Change:
Added a default packet classification. Removed the generated txt file ( can always be generated from Makefile). Please reject pull request if you disagree. Thanks.
Reworked yang model. Mostly implemented (except for json serialization).
Reduced the amount of information in the YANG model to something manageable. Mostly implemented (except for some JSON serialization issues). At least it is feasible to implement this. Removed frequency (should be left to administrator - not manufacturer).

Discussion:
array of the MUD file. Second, the "mud" container is augmented with a container that points <del> to where to report and how often. </del> <ins> to where to report. The frequency of reporting is impelementation dependent. Impelemntations are encouraged to report when ever packet drops are noticed at the enforcement point; however, this is not a strict requirement. </ins> This is done as follows:
Change:
WFM
Oops, I'd missed that. I will change that instance as well.
It should not preclude 0, 1 or 2, therefore: s/several/zero or more/
Maybe just "representations of different media types"?

Discussion:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> zero or more different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build

RFCthis <del> Applications that need to combine representations of potentially several media types into one, e.g., EST-CoAP </del> <ins> Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP </ins> N/A
Change:
Sure. Apologies, I had completely misunderstood the gist of your comment (and Carsten's reply).
-> s/message-body/request or response body/
I still don't understand why the only permissible use of this representation format is inside a CoAP payload. Can't I transfer the CBOR structure over HTTP or store it in a file?

Discussion:
This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> several different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> 1. This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of <del> several different media types into a single CoAP RFC7252 message-body with minimal framing overhead, each along with a CoAP Content-Format identifier. </del> <ins> several different media types into a single message, such as a CoAP RFC7252 request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier. </ins> This simple and efficient binary framing mechanism can be employed to create application specific request and response bodies which build
Change:
Carsten adds:
Yes. (Where is the rest of that change?)
As we speak there's no PR, only this issue.
NAME would you mind writing the missing text? I'm not comfortable messing around with media type registration procedures :-)

Discussion:
Applications that need to combine representations of zero or more different media types into one, e.g., EST-CoAP <del> N/A </del> <ins> The syntax and semantics of fragment identifiers specified for "application/multipart-core" is as specified for "application/ cbor".  (At publication of this document, there is no fragment identification syntax defined for "application/cbor".) </ins>