Change:
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> <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.

Discussion:
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