Change:
Some of these editorial comments I find less clear than the original. The code changes and varint are fine. Could you please split this into two more atomic PRs so we can discuss separately?
Feel free to leave comments on the editorial portion of this PR to keep things moving

Discussion:
involved in the group can change from one epoch to the next, and MLS ensures that only the members in the current epoch have access to the epoch secret.  From the epoch secret, members derive further shared <del> secrets for message encryption, group membership authentication, etc. </del> <ins> secrets for message encryption, group membership authentication, and so on. </ins> The creator of an MLS group creates the group's first epoch unilaterally, with no protocol interactions.  Thereafter, the members

A _key schedule_ that describes the chain of key derivations used to progress from epoch to epoch (mainly using the _init_secret_ <del> and _epoch_secret_); and to derive a variety of other secrets (see epoch-derived-secrets) used during the current epoch.  One of these (the _encryption_secret_) is the root of _secret_tree_. </del> <ins> and _epoch_secret_), as well as the derivation of a variety of other secrets (see epoch-derived-secrets), for example: An _encryption secret_ that is used to initialize the secret tree for the epoch. An _exporter secret_ that allows other protocols to leverage MLS as a generic authenticated group key exchange. A _resumption secret_ that members can use to prove their membership in the group, e.g., in the case of branching a subgroup. </ins> A _secret tree_ derived from the key schedule that represents <del> shared secrets used by the members of the group to provide confidentiality and forward secrecy for MLS messages.  Each epoch has a distinct secret tree. </del> <ins> shared secrets used by the members of the group for encrypting and authenticating messages.  Each epoch has a distinct secret tree. </ins> <del> Each member of the group maintains a view of these facets of the group's state.  MLS messages are used to initialize these views and keep them in sync as the group transitions between epochs. </del> <ins> Each member of the group maintains a partial view of these components of the group's state.  MLS messages are used to initialize these views and keep them in sync as the group transitions between epochs. </ins> Each new epoch is initiated with a Commit message.  The Commit instructs existing members of the group to update their views of the ratchet tree by applying a set of Proposals, and uses the updated ratchet tree to distribute fresh entropy to the group.  This fresh <del> entropy is provided only to members in the new epoch, not to members who have been removed, so it maintains the confidentiality of the epoch secret (in other words, it provides post-compromise security with respect to those members). For each Commit that adds member(s) to the group, there is a single corresponding Welcome message.  The Welcome message provides all the new members with the information they need to initialize their views of the key schedule and ratchet tree, so that these views are equivalent to the views held by other members of the group in this </del> <ins> entropy is provided only to members in the new epoch and not to members who have been removed.  Commits thus maintain the property that the the epoch secret is confidential to the members in the current epoch. For each Commit that adds one or more members to the group, there is a single corresponding Welcome message.  The Welcome message provides all the new members with the information they need to initialize their views of the key schedule and ratchet tree, so that these views align with the views held by other members of the group in this </ins> epoch. <del> In addition to defining how one epoch secret leads to the next, the key schedule also defines a collection of secrets that are derived from the epoch secret.  For example: An _encryption secret_ that is used to initialize the secret tree for the epoch. A _confirmation key_ that is used to confirm that all members agree on the shared state of the group. A _resumption secret_ that members can use to prove their membership in the group, e.g., in the case of branching a subgroup. Finally, an _init secret_ is derived that is used to initialize the next epoch. </del> 4.2. There are three major operations in the lifecycle of a group:

the group can send a Remove proposal followed by a Commit message. The Commit message provides new entropy to all members of the group except the removed member.  This new entropy is added to the epoch <del> secret for the new epoch, so that it is not known to the removed </del> <ins> secret for the new epoch so that it is not known to the removed </ins> member.  Note that this does not necessarily imply that any member is actually allowed to evict other members; groups can enforce access control policies on top of these basic mechanism.

4.3. A group has a single linear sequence of epochs.  Groups and epochs <del> are generally independent of one-another.  However, it can sometimes </del> <ins> are generally independent of one another.  However, it can sometimes </ins> be useful to link epochs cryptographically, either within a group or across groups.  MLS derives a resumption pre-shared key (PSK) from each epoch to allow entropy extracted from one epoch to be injected