Original text:
tree of Application Secrets as well as one symmetric ratchet per group member. <del> Each client maintains their own local copy of (parts 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. </del>  Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated <del> with the MLS ciphersuite.  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>  11.1. <del> The Application schedule begins with the Application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree. Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </del>  Each node in the tree is assigned a secret.  The root's secret is simply the application_secret of that epoch.  (See key-schedule for

Reviewer comments:
Update change log for draft-07 No conflicting PRs so I did break many lines that were too long. Fix a few minor editorial issues after merging the tree-based application key schedule.

Revised text:
tree of Application Secrets as well as one symmetric ratchet per group member.  <ins> 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. </ins> Application messages MUST be protected with the Authenticated- Encryption with Associated-Data (AEAD) encryption scheme associated  <ins> 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. </ins> 11.1.  <ins> The application key schedule begins with the application secrets which are arranged in an "Application Secret Tree" or AS Tree for short; a left balanced binary tree with the same set of nodes and edges as the epoch's ratchet tree.  Each leaf in the AS Tree is associated with the same group member as the corresponding leaf in the ratchet tree.  Nodes are also assigned an index according to their position in the array representation of the tree (described in tree-math).  If N is a node index in the AS Tree then left(N) and right(N) denote the children of N (if they exist). </ins> Each node in the tree is assigned a secret.  The root's secret is simply the application_secret of that epoch.  (See key-schedule for