Original text:
8. The ratchet tree for an epoch describes the membership of a group in <del> that epoch, providing public-key encryption keys that can be used to encrypt to subsets of the group as well as information to </del>  authenticate the members.  In order to reflect changes to the membership of the group from one epoch to the next, corresponding changes are made to the ratchet tree.  In this section, we describe 8.2. <del> A member of an MLS group advances the key schedule to provide forward secrecy and post-compromise security by providing the group with fresh key material to be added into the group's shared secret.  To do so, one member of the group generates fresh key material, applies it to their local tree state, and then sends this key material to other members in the group via an UpdatePath message (see update-paths) . All other group members then apply the key material in the UpdatePath to their own local tree state to derive the group's now-updated shared secret. To begin, the generator of the UpdatePath updates its leaf node and its direct path to the root with new secret values.  The HPKE leaf public key within the KeyPackage MUST be derived from a freshly generated HPKE secret key to provide post-compromise security. The generator of the UpdatePath starts by sampling a fresh random value called "leaf_secret", and uses the leaf_secret to generate their leaf HPKE key pair (see key-packages) and to seed a sequence of "path secrets", one for each ancestor of its leaf.  In this setting, path_secret[0] refers to the leaf's parent, path_secret[1] to the parent's parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding node, from which the node's key pair is derived. </del>  The node secret is derived as a temporary intermediate secret so that each secret is only used with one algorithm: The path secret is used structure, where "lp" and "np[i]" represent the leaf_priv and node_priv values generated as described above: <del> After performing these operations, the generator of the UpdatePath MUST delete the leaf_secret. </del> 8.3. In addition to the path-based updates to the tree described above, it

Reviewer comments:
Changes (apart from editorial): Remove the text about the key schedule. Reason: I found the text confusing, because updating paths provides FS and PCS for the HPKE keys in the ratchet tree, and not directly for the key schedule. Generate the leaf key pair simply as a fresh HPKE key pair, and not from the leafsecret. I couldn't see any benefit of using the leafsecret. I wonder if there is a good reason?
I am concerned that we are asking for a LOT of fresh entropy if (in addition to nonces) we need a crypto-random value every epoch for every group (a Wire client can easily a member of thousands of groups at a time). Do you have a concern about deriving it?
Discussion on the virtual interim: To NAME concern: This allows the base path secret to be derived, e.g., using a KDF, so this doesn't necessarily increase the amount of entropy needed Clear to merge

Revised text:
8. The ratchet tree for an epoch describes the membership of a group in  <ins> that epoch, providing public-key encryption (HPKE) keys that can be used to encrypt to subsets of the group as well as information to </ins> authenticate the members.  In order to reflect changes to the membership of the group from one epoch to the next, corresponding changes are made to the ratchet tree.  In this section, we describe 8.2.  <ins> In order to provide forward secrecy and post-compromise security, whenever a member initiates an epoch change (i.e., commits; see commit), they refresh all HPKE key pairs in the ratchet tree for which they know the secret keys.  More precisely, they refresh the key pairs of their leaf and of all nodes on their leaf's direct path. The member initiating the epoch change generates the fresh key pairs using the following procedure.  The procedure is designed in a way that allows group members to efficiently communicate the fresh secret keys to other group members, as described in update-paths. Generate a fresh HPKE key pair for the leaf. Generate a sequence of path secrets, one for each node on the leaf's direct path as follows.  In this context, "path_secret[0]" is generated for the leaf's parent, "path_secret[1]" is generated for the leaf's grandparent, etc. Compute the sequence of HPKE key pairs "(node_priv,node_pub)", one for each node on the leaf's direct path, as follows. </ins> The node secret is derived as a temporary intermediate secret so that each secret is only used with one algorithm: The path secret is used structure, where "lp" and "np[i]" represent the leaf_priv and node_priv values generated as described above:  8.3. In addition to the path-based updates to the tree described above, it