Change:
Clarify what client should do when receiving a Commit removing itself update Remove example to show removed client receiving the Commit fix typos in Security Considerations
While implementing removals, I came to the conclusion that clients would Currently in the MLS Protocol, when a Commit containing a Remove Proposal is sent to a group, the specification does not provide enough implementation guidance to insure that the removed member is notified of its removal. I can think of three ways a member can determine it has been removed: Require the DS to forward the Commit message containing the removal to all removed members. Require an out-of-band protocol convey this information Create a new MLS message type (ex: Goodbye) specifically to convey removal. Forwarding the Commit message would require only one new normative statement in the MLS protocol document, some similar additional text in the MLS architecture document, and a minor change to the remove example flow diagram in the MLS protocol document. This would be a straightforward clarification. The disadvantage is that forwarding the commit to a removed member can leak other membership changes (ex: the credentials of newly added members, and the potential knowledge of which other members were removed at the same time). Requiring an out-of-band protocol to convey removal information, while possible, leaves a privacy sensitive decision out of scope, while the analogous action is a first-class part of the MLS protocol (Welcomes). Using a new message type (ex: Goodbye) requires new specification work, but allows a message analogous to a Welcome which can inform clients individually they were removed without leaking potentially sensitive information about the new membership of the group they just departed. Note that the architecture document could require that the DS either implement 1 or 2, but leaving too many choices makes interoperability more complicated.
The Commit is the goodbye message. Clients are able to parse it and conclude that they have been removed. I thought that 1. was always implied, what makes you think otherwise?
I assumed this as well, but it is only implied in the spec, and the example flow showing a remove doesn't have an arrow going to the removed client (which would clearly be wrong if it is required). (For good or bad, a lot of implementers code from examples and then go back and check their assumptions in the body of a spec. That is why it is so important to get examples correct.) If we decide that it's an implementation choice (and say that it is also ok to do it out of band for example) then we need to explain that in the architecture document. So, we can 1) Decide that a client MUST always get the Commit removing them; make that explicit in the protocol; fix the example; explain the privacy leak in the Security Considerations; possibly summarize this in the architecture document. 2) Say that a client MUST be informed about their removal in the protocol spec and leave how to convey removals as one of these policy choices for the DS (you could even make sending the Commit a SHOULD); explain more extensively in the architecture document. 3) Address the privacy issue directly by making an explicit Goodbye message.
You introduce the notion of a 'privacy leak' and a 'privacy issue' in your last message, what exactly are you referring to? I think 1. is currently implied and examples should be adjusted if they don't reflect that.
I think the privacy issue NAME is concerned about is something like: If other changes are made in the same Commit that removes a participant, then the removed participant can see those changes. For example, the identities of people added to the group in that commit. It's not totally clear to me what the security objective here is. It seems like the point of informing a member they have been removed via a group message (Commit or Goodbye) would be to prevent the DS from lying to the member about whether they have been removed -- telling them they'd been removed when they hadn't, or vice versa. This honestly isn't something I'm all that worried about, because (a) none of this affects the security of those who remain in the group, and (b) even if you had a message, the DS could suppress it (and thus lie in at least one direction). The best argument that occurs to me is that being removed might (might!) trigger deletion of old keys, thus providing better FS for any outstanding messages in prior epochs in the event the removed member was compromised. (This is unlike the add situation, where we need a protocol message to provide the new joiner with the cryptographic material they need to participate in the group. That cannot be delegated to the DS.) If we had an explicit Goodbye message, we would have a malicious insider risk, in that a group member could generate a Goodbye for someone that was not actually removed. Net of all that, I think something like Rohan's option (2) would be my preference. Mostly punt it to OOB, but note that the Commit COULD be used.
I suspect as much. I'd say that this is only a potential privacy issue because the committer can simply avoid it by issuing two commits. The leaked information about other proposals is also not necessarily sensitive. That being said, I think it would be worth mentioning this in the architecture doc. I think either (1) or (2). would work, where (2) has the added benefit of more flexibility. (3) would indeed be problematic for the reasons you mention.
It sounds like there is weak consensus that a client should be informed either by a Commit or out-of-band. I submitted PR which shows a Commit going to the removed user in the example flow, and provides some guidance to a client about processing a Commit that removes itself. I'll submit a separate PR for the architecture spec that adds this to the list of things you need for a concrete DS / client implementation.
Resolved with

Discussion:
Welcome message from the committer meeting the requirements of reinitialization. <ins> Note that clients need to be prepared to receive a valid Commit message which removes them from the group.  In this case, the client cannot send any more messages in the group and SHOULD promptly delete its group state and secret tree.  (A client might keep the secret tree for a short time to decrypt late messages in the previous epoch.) </ins> 13.4.3. New members can join the group in two ways.  Either by being added by

node in the tree is known only to members of the group that are assigned a leaf in the node's subtree.  This is called the _ratchet tree invariant_ and it makes it possible to encrypt to all group <del> members except one, with a number of ciphertexts that's logarithmic </del> <ins> members except one, with a number of ciphertexts that is logarithmic </ins> in the number of group members. The ability to efficiently encrypt to all members except one allows

an impersonation attack, the attacker would need to compromise the relevant PSK as well as the victim's signature key.  The cost of this mitigation is that the application needs some external arrangement <del> that ensures that the legitimate members of the group to have the </del> <ins> that ensures that the legitimate members of the group have the </ins> required PSKs. 16.3.