Original text:
Add and Commit message adding that member, and broadcasts them to the group.  It also generates a Welcome message and sends this directly to the new member (there's no need to send it to the group).  Only <del> after A has received its Commit message back from the server does it update its state to reflect the new member's addition. Upon receiving the Welcome message, the new member will be able to read and send new messages to the group.  However, messages sent before they were added to the group will not be accessible. </del>  Subsequent additions of group members proceed in the same way.  Any member of the group can download a KeyPackage for a new client and used.  array-based-trees and link-based-trees provide some details on how to implement the tree operations required for MLS in these representations.  MLS places no requirements on implementations' <del> internal representations of ratchet trees.  An implementation MAY use </del>  any tree representation and associated algorithms, as long as they produce correct protocol messages. When decoding an MLSCiphertextContent, the application MUST check that the MLSContentAuthData is valid.  6.3.2. The "sender data" used to look up the key for content encryption is Concrete algorithms for these operations on array-based and link- based trees are provided in array-based-trees and link-based-trees. <del> The concrete algorithms are non-normative.  An implementation MAY use </del>  any algorithm that produces the correct tree in its internal representation. Applications SHOULD define a policy on how long to keep unused nonce and key pairs for a sender, and the maximum number to keep.  This is <del> in addition to ensuring that these nonce and key pairs are promptly deleted when the epoch ends.  Applications SHOULD also define a policy limiting the maximum number of steps that clients will move the ratchet forward in response to a new message.  Messages received with a generation counter that's too much higher than the last message received would then be rejected.  This avoids causing a denial-of-service attack by requiring the recipient to perform an excessive number of key derivations.  For example, a malicious group member could send a message with "generation = 0xffffffff" at the beginning of a new epoch, forcing recipients to perform billions of key derivations. </del>  15. between two security levels (roughly 128-bit and 256-bit).  Within the security levels clients can choose between faster X25519/X448 curves and FIPS 140-2 compliant curves for Diffie-Hellman key <del> negotiations.  Additionally clients that run predominantly on mobile processors can choose ChaCha20Poly1305 over AES-GCM for performance reasons.  Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is not paired with FIPS 140-2 compliant curves.  The security level of symmetric encryption algorithms and hash functions is paired with the security level of the curves. </del>  The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519

Reviewer comments:
Comment by NAME Citation needed? I think most phones have AES(_GCM) in hardware too ? Also compared to HPKE operations and the times for epoch/group reinit, does this performance really matter? (eg waking up from sleep to increment the epoch would make the symmetric encryption cost pretty irrelevant. I would remove this sentence.
I'll remove the "mobile processors" bit and phrase it a little more evenhandedly ("can choose ChaCha or GCM"), but I think it's fair to say that there might be environments where ChaCha/Poly is more performant than AES-GCM.
Thanks. I do think you might be right that "there are", but I also do not think "mobile" is that :)
Comment by NAME This sentence with a hidden MUST is stuck between a sentence with MAY and a sentence with SHOULD. Perhaps make the MUST explicit ?
This is already well covered in the discussion, but I can add a cross-reference.
I meant just rephase the sentence so it contains "MUST delete when the epoch ends"
Comment by NAME That is quite some information that must be publicly available to allow external Add requests. This leaks information, eg same epoch means the group membership did not change, etc etc. I hope this will appear in the Security Considerations later :)
I suppose between this and , we should add a subsection to the Security Considerations on metadata privacy.
I'm not sure actually resolves this?
Oops, that's correct NAME Had it in my notes among the others.
Comment by NAME Isn't there technically also limits to how much one AEAD key and one nonce can be used to encrypt a (very very) large message? I guess this could not happen, but is there some formal message size limit in MLS ? (looking at the vectors at the start, limits could be higher than 2^64 ?)
Comment by NAME Another weird MAY here. Again, I would just lowercase it as this is just a pointer to a human decision, not a 2119 based protocol enforcement.
Comment by NAME Figure 10 claims to have seven members, but I count 8, namely Y,T,X,A,B,E,F and G (not counting W, the root)
Actually, it only has five! A, B, E, F, and G. Recall that members are at the leaves of the tree.
Ah right :)
Comment by NAME This MAY is super weird. Is it allowed to implement in such a way that they to NOT produce correct protocol messages? :-) Remove the entire sentence or lowercase the MAY?
Comment by NAME What server? The Delivery Service ?
Comment by NAME Should this be "prospective member" or "invitee" ? They haven't joined yet, have they?
From the perspective of the group, they are joined. Once the Commit adding the new member is processed and the new epoch starts, that member is able to access the group's secrets. The only thing "provisional" about the membership is that the new member hasn't initialized their local state. We use "new member" consistently to mean the subject of an Add proposal, and I don't think this is a big enough distinction to merit more terminology.
Another way to look at it is that keying information from the new member is already incorporated into the group, therefore they are a member and not a provisional member.
Ah yes. Perhaps a single line explaining this at the quoted location could be useful, but is not required

Revised text:
Add and Commit message adding that member, and broadcasts them to the group.  It also generates a Welcome message and sends this directly to the new member (there's no need to send it to the group).  Only  <ins> after A has received its Commit message back from the Delivery Service does it update its state to reflect the new member's addition. Once A has updated its state, the new member has processed the Welcome, and any other group members have processed the Commit, they will all have consistent representations of the group state, including a group secret that is known only to the members the group. The new member will be able to read and send new messages to the group, but messages sent before they were added to the group will not be accessible. </ins> Subsequent additions of group members proceed in the same way.  Any member of the group can download a KeyPackage for a new client and used.  array-based-trees and link-based-trees provide some details on how to implement the tree operations required for MLS in these representations.  MLS places no requirements on implementations'  <ins> internal representations of ratchet trees.  An implementation may use </ins> any tree representation and associated algorithms, as long as they produce correct protocol messages. When decoding an MLSCiphertextContent, the application MUST check that the MLSContentAuthData is valid. <ins> It is up to the application to decide what "authenticated_data" to provide and how much padding to add to a given message (if any).  The overall size of the AAD and ciphertext MUST fit within the limits established for the group's AEAD algorithm in [!I-D.irtf-cfrg-aead- limits]. </ins> 6.3.2. The "sender data" used to look up the key for content encryption is Concrete algorithms for these operations on array-based and link- based trees are provided in array-based-trees and link-based-trees.  <ins> The concrete algorithms are non-normative.  An implementation may use </ins> any algorithm that produces the correct tree in its internal representation. Applications SHOULD define a policy on how long to keep unused nonce and key pairs for a sender, and the maximum number to keep.  This is  <ins> in addition to ensuring that these secrets are deleted according to the deletion schedule defined in deletion-schedule.  Applications SHOULD also define a policy limiting the maximum number of steps that clients will move the ratchet forward in response to a new message. Messages received with a generation counter that's too much higher than the last message received would then be rejected.  This avoids causing a denial-of-service attack by requiring the recipient to perform an excessive number of key derivations.  For example, a malicious group member could send a message with "generation = 0xffffffff" at the beginning of a new epoch, forcing recipients to perform billions of key derivations. </ins> 15. between two security levels (roughly 128-bit and 256-bit).  Within the security levels clients can choose between faster X25519/X448 curves and FIPS 140-2 compliant curves for Diffie-Hellman key  <ins> negotiations.  Clients may also choose ChaCha20Poly1305 or AES-GCM, e.g., for performance reasons.  Since ChaCha20Poly1305 is not listed by FIPS 140-2 it is not paired with FIPS 140-2 compliant curves.  The security level of symmetric encryption algorithms and hash functions is paired with the security level of the curves. </ins> The mandatory-to-implement ciphersuite for MLS 1.0 is "MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519" which uses Curve25519