Change:
This PR updates two sections to reference generating and sending an message, as not all Commits transmit fresh key material (as discussed in ). This PR also includes light editorial edits for clarity and adds detail around the steps to perform an update. Section 7.7 currently says that "each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path", but section 10.2 says that an UpdatePath is optional. I can update 7.7 as well, if 10.2 is correct.
I went ahead and changed Section 7.7 to specify that MLS commits may optionally transmit updates for consistency with Section 10.2

Discussion:
5.4. <del> When performing a Commit, the generator of the Commit updates its leaf KeyPackage 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 Commit 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, </del> <ins> 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 KeyPackage 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, </ins> path_secret[0] refers to the node directly above the leaf, path_secret[1] for its parent, and so on.  At each step, the path secret is used to derive a new secret value for the corresponding

For example, suppose there is a group with four members: <del> If member B subsequently generates a Commit based on a secret </del> <ins> If member B subsequently generates an UpdatePath based on a secret </ins> "leaf_secret", then it would generate the following sequence of path secrets: <del> After the Commit, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: </del> <ins> After applying the UpdatePath, the tree will have the following structure, where "np[i]" represents the node_priv values generated as described above: </ins> <del> After performing these operations, the generator of the Commit MUST delete the leaf_secret. </del> <ins> After performing these operations, the generator of the UpdatePath MUST delete the leaf_secret. </ins> 5.5. <del> After generating a Commit as described in the prior section, the generator of the Commit must broadcast this update to other members of the group, who apply it to keep their local views of the tree in sync with the sender's.  When a client commits a change to the tree (e.g., to add or remove a member), it transmits a handshake message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group can use these values to update their view of the tree, aligning their copy of the tree to the sender's. To perform an update for a path (a Commit), the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </del> <ins> After generating fresh key material and applying it to ratchet forward their local tree state as described in the prior section, the generator must broadcast this update to other members of the group in a Commit message, who apply it to keep their local views of the tree in sync with the sender's.  More specifically, when a member commits a change to the tree (e.g., to add or remove a member), it transmits a UpdatePath message containing a set of public and encrypted private values for intermediate nodes in the direct path of a leaf.  The other members of the group use these values to update their view of the tree, aligning their copy of the tree to the sender's. To transmit this update, the sender broadcasts to the group the following information for each node in the direct path of the leaf, including the root: </ins> The public key for the node

7.7. <del> As described in commit, each MLS Commit message needs to transmit a KeyPackage leaf and node values along its direct path.  The path contains a public key and encrypted secret value for all intermediate nodes in the path above the leaf.  The path is ordered from the closest node to the leaf to the root; each node MUST be the parent of its predecessor. </del> <ins> As described in commit, each MLS Commit message may optionally transmit a KeyPackage leaf and node values along its direct path. The path contains a public key and encrypted secret value for all intermediate nodes in the path above the leaf.  The path is ordered from the closest node to the leaf to the root; each node MUST be the parent of its predecessor. </ins> The number of ciphertexts in the "encrypted_path_secret" vector MUST be equal to the length of the resolution of the corresponding copath