I am the assigned ART directorate reviewer for this document. These comments were written primarily for the benefit of the ART area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes a secure group messaging architecture. It also gives recommendations for building group messaging systems. General notes. The document is well written and easy to read. However, I believe that the architecture part of the document (up too Section 5) is too concise and provides only very high level view. I believe the document would benefit if more details were provided (e.g the description of double ratchet as the cryptographic foundation of the MLS protocol, what is commit message and proposal message, etc.) I also think that the part of the document that describes functional requirements is not generic enough and is written having the current version of the MLS protocol in mind (it contains references to the internals of the current protocol version, like LeafNode, external_senders, external_pub, application_id, required_capabilities, etc., which may change or go away in the next version). I believe that references to the concrete protocol internals should be avoided, or these internals should be explained. Issues. 1. Section 5.10 describes the compatibility with future Versions of MLS. In particular it states: When multiple versions of MLS are available, the negotiation protocol guarantees that the version agreed upon will be the highest version supported in common by the group. and In MLS 1.0, the creator of the group is responsible for selecting the best ciphersuite supported across clients. I think this is problematic for the clients that join group later. Consider the situation when a newer version of the protocol is available and some clients are upgraded, but most are not yet. If the upgraded clients (that support both versions) form a new group, then they select the highest version of the protocol. After that no other clients, that are not yet upgraded (which still form majority), can join this group. The same situation is with ciphersuites (and it is unclear what is "the best ciphersuite", how to compare them). I think there must be an option for the group in situation when all the members support several protocol versions (or several ciphersuites) to change the version (or ciphersite) on the fly (if this is ever possible and doesn't lead to the degradation of security) if incoming clients don't support the currently selected ones. This should also include "external joins", probably the published information about the group should be constructed in such a way that clients having different capabilities may read it. I understand that this would complicate the protocol, but otherwise its usability would suffer. 2. Section 5.1 describes membership changes. In particular, it states (at least as I read it), that there is no way for a member to unilaterally leave the group; they must be removed by a remaining member. I find this limitation very frustrating. I believe, that any member should always have a possibility to leave the group, otherwise the group starts looking like a sect - one may freely enter, but can never leave at their will, unless authorised by other members. In my understanding this limitation follows from the cryptographic construction of the MLS protocol. If this is the case, then more recommendations should be given how the applications can deal with this limitation, so that users retain the right to leave - e.g. drop all incoming messages, don't send updates etc. Of course these are all protocol hacks... 3. It is not clear from the document (at least for me), whether the type of DS (Strongly Consistent or Eventually Consistent) is tied to the the clients that use it. It is clear that clients behave differently with different types of DS. But the described architecture is highly flexible and can accommodate different types of DS. My question - can the type of DS change for the existing group (e.g. the operator upgrades the DS software and the new version provides different capabilities)? In this case all the clients should be able to learn the current type of DS and should always support both types. Nits. 1. There must not be references in an abstract. I would also recommend to make the abstract shorter (as per IESG recommendations, that an abstract should be one or two paras in length). 2. The document contains BCP14 words, but doesn't contain references to RFC 2119 and 8174. In addition, the document contains several instances of the word "*RECOMMENDATION:*". I believe the uppercase words are reserved for BCP14, but this is not BCP14 word. I think it would be better to explain this word in the newly added section (in particular, what is the part of the system these recommendations should be applied to). In addition there are both "*RECOMMENDATION:*" and "** RECOMMENDATION:**". Is it just a typo or does double asterisks make the recommendation stronger? 3. Section 4.2 is a bit inconsistent with Section 6 with regard to the message delivery only to specific clients. The former mentions Welcome message as an example of this necessity (so I assume that some other messages can also be delivered only to specific clients), while the latter mentions only Welcome messages, with no "e.g." (so I assume that only these messages can be delivered only to specific clients). 4. There are two "Informative References" sections - 8 and 10.2. I suggest to move all the content of Section 8 to Section 10.2 (and also change appearance to [XXXX]). 5. Section 7.1 states: Any secure channel can be used as a transport layer to protect MLS messages such as QUIC, TLS, WireGuard or TOR. I read this as a requirement that only secure transport protocols may be used for MLS messages. However, later in this section there are assumptions that insecure transport may also be used (although not recommended). I think this is inconsistent - if only secure transport are allowed, then there is no point to discuss using of insecure one (other than providing some reasoning for the requirement).