Original text:
16. <del> The primary purpose of the Handshake protocol is to provide an </del>  authenticated group key exchange to clients.  In order to protect <del> Application messages sent among the members of a group, the Application secret provided by the Handshake key schedule is used to derive nonces and encryption keys for the Message Protection Layer according to the Application Key Schedule.  That is, each epoch is equipped with a fresh Application Key Schedule which consist of a tree of Application Secrets as well as one symmetric ratchet per group member. Each client maintains their own local copy of the Application Key Schedule for each epoch during which they are a group member.  They derive new keys, nonces and secrets as needed while deleting old ones as soon as they have been used. Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated with the MLS ciphersuite using the common framing mechanism.  Note that "Authenticated" in this context does not mean messages are known to be sent by a specific client but only from a legitimate member of the group.  To authenticate a message from a particular member, signatures are required.  Handshake messages MUST use asymmetric signatures to strongly authenticate the sender of a message. </del>  16.1. <del> The group members MUST use the AEAD algorithm associated with the negotiated MLS ciphersuite to AEAD encrypt and decrypt their Application messages according to the Message Framing section. The group identifier and epoch allow a recipient to know which group secrets should be used and from which Epoch secret to start computing other secrets and keys.  The sender identifier is used to identify the member's symmetric ratchet from the initial group Application secret.  The application generation field is used to determine how far into the ratchet to iterate in order to reproduce the required AEAD keys and nonce for performing decryption. Application messages SHOULD be padded to provide some resistance against traffic analysis techniques over encrypted traffic.  CLINIC HCJ16 While MLS might deliver the same payload less frequently across a lot of ciphertexts than traditional web servers, it might still provide the attacker enough information to mount an attack.  If Alice asks Bob: "When are we going to the movie ?" the answer "Wednesday" might be leaked to an adversary by the ciphertext length.  An attacker expecting Alice to answer Bob with a day of the week might find out the plaintext by correlation between the question and the length. </del>  The length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  Senders may 16.2. <del> During each epoch senders MUST NOT encrypt more data than permitted </del>  by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead- limits. <del> Note that each change to the Group through a Handshake message will </del>  also set a new "encryption_secret".  Hence this change MUST be applied before encrypting any new application message.  This is required both to ensure that any users removed from the group can no 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>  17.

Reviewer comments:
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.

Revised text:
16.  <ins> The primary purpose of handshake messages are to provide an </ins> authenticated group key exchange to clients.  In order to protect  <ins> application messages sent among the members of a group, the "encryption_secret" provided by the key schedule is used to derive a sequence of nonces and keys for message encryption.  Every epoch moves the key schedule forward which triggers the creation of a new secret tree, as described in secret-tree, along with a new set of symmetric ratchets of nonces and keys for each member. Each client maintains their own local copy of the key schedule for each epoch during which they are a group member.  They derive new keys, nonces, and secrets as needed while deleting old ones as soon as they have been used. The group identifier and epoch allow a recipient to know which group secrets should be used and from which "epoch_secret" to start computing other secrets.  The sender identifier and content type is used to identify which symmetric ratchet to use from the secret tree. The "generation" counter determines how far into the ratchet to iterate in order to produce the required nonce and key for encryption or decryption. </ins> 16.1.  <ins> Application messages MAY be padded to provide some resistance against traffic analysis techniques over encrypted traffic CLINIC HCJ16. While MLS might deliver the same payload less frequently across a lot of ciphertexts than traditional web servers, it might still provide the attacker enough information to mount an attack.  If Alice asks Bob "When are we going to the movie?", then the answer "Wednesday" could be leaked to an adversary solely by the ciphertext length. </ins> The length of the "padding" field in "MLSCiphertextContent" can be chosen at the time of message encryption by the sender.  Senders may 16.2.  <ins> During each epoch, senders MUST NOT encrypt more data than permitted </ins> by the security bounds of the AEAD scheme used I-D.irtf-cfrg-aead- limits.  <ins> Note that each change to the group through a handshake message will </ins> also set a new "encryption_secret".  Hence this change MUST be applied before encrypting any new application message.  This is required both to ensure that any users removed from the group can no 16.3.  <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.