Change:
16.3. <del> Since each Application message contains the group identifier, the epoch and a message counter, a client can receive messages out of order.  If they are able to retrieve or recompute the correct AEAD decryption key from currently stored cryptographic material clients can decrypt these messages. For usability, MLS clients might be required to keep the AEAD key and nonce for a certain amount of time to retain the ability to decrypt delayed or out of order messages, possibly still in transit while a decryption is being done. </del> <ins> Since each application message contains the group identifier, the epoch, and a generation counter, a client can receive messages out of order.  When messages are received out of order, the client moves the sender ratchet forward to match the received generation counter.  Any unused nonce and key pairs from the ratchet are potentially stored so that they can be used to decrypt the messages which were delayed or reordered. 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 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. </ins> 17.

Discussion:
Interim 2022-05-26: Intended to be mostly editorial Leaving open for now Clear to merge in between meetings if folks are comfortable
Interim 2022-06-02: Still clear from last week
The generation numbers should be increased sequentially, gaps should be avoided to avoid unnecessary expensive operations on clients. Clients might also abort if the gap is too large to prevent attacks from malicious insiders.
This is stated in 10.1:
I suspect that what Raphael is worried about is that a malicious insider (someone in possession of the ) could make an MLSCiphertext with set to that would cause the receiver to do HKDF invocations. The attacker doesn't have to incur this cost because they don't need to generate the required key -- the ciphertext can be garbage because the key generation happens before the decryption does. It seems like we could use a paragraph at the end of covering this and the fact that if you want to allow for out-of-order messages, you need to keep the intermediate keys. Since big gaps would force you to store the keys as well as doing the hashing. A figure here might also be helpful.
Couple of friendly amendments, otherwise lgtm. I am going to hold this as slightly more than editorial, given the number of MUSTs that are affected. But I would note for others that the MUSTs that are removed here are all redundant with requirements above.Thanks for picking this up! Just one nit, but looks good otherwise.