Original text:
All trees used in this protocol are left-balanced binary trees.  A binary tree is _full_ (and _balanced_) if its size is a power of two and for any parent node in the tree, its left and right subtrees have <del> the same size.  If a subtree is full and it is not a subset of any other full subtree, then it is _maximal_. </del>  A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest full subtree that could be constructed from the leaves present in the parent's own subtree.  Given a list of "n" items, there is a unique left-balanced binary tree structure with these elements as leaves. <del> In such a left-balanced tree, the "k-th" leaf node refers to the "k-th" leaf node in the tree when counting from the left, starting from 0. </del> (Note that left-balanced binary trees are the same structure that is used for the Merkle trees in the Certificate Transparency protocol I- The leaves of the tree are indexed separately, using a _leaf index_, since the protocol messages only need to refer to leaves in the tree. <del> Like nodes, leaves are numbered left to right.  Note that given the above numbering, a node is a leaf node if and only if it has an even node index, and a leaf node's leaf index is half its node index.  The leaf indices in the above tree are as follows: </del>  0 = A the signature computation comprises all of the fields except for the signature field. <del> KeyPackage objects MUST contain at least two extensions, one of type "supported_versions" and one of type "supported_ciphersuites".  These extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del>  As the "KeyPackage" is a structure which is stored in the Ratchet Tree and updated depending on the evolution of this tree, each time a Commit message is sent and processed.  These states are referred to as "epochs" and are uniquely identified among states of the group by eight-octet epoch values.  When a new group is <del> initialized, its initial state epoch 0x0000000000000000.  Each time a state transition occurs, the epoch number is incremented by one. </del>  [[ OPEN ISSUE: It would be better to have non-linear epochs, in order to tolerate forks in the history.  There is a need to discuss whether

Reviewer comments:
I've put a bunch of little fixes in here. If you disagree with any of these changes, I can back them out or change them. maximal is defined but never used k-th leaf/leaf index is defined in two places; merge definitions change KeyPackage struct definition to reflect that ~2~ 3 extensions are required is also a required extension grammar fix add missing semicolon
One minor thing, otherwise LGTM

Revised text:
All trees used in this protocol are left-balanced binary trees.  A binary tree is _full_ (and _balanced_) if its size is a power of two and for any parent node in the tree, its left and right subtrees have  <ins> the same size. </ins> A binary tree is _left-balanced_ if for every parent, either the parent is balanced, or the left subtree of that parent is the largest full subtree that could be constructed from the leaves present in the parent's own subtree.  Given a list of "n" items, there is a unique left-balanced binary tree structure with these elements as leaves.  (Note that left-balanced binary trees are the same structure that is used for the Merkle trees in the Certificate Transparency protocol I- The leaves of the tree are indexed separately, using a _leaf index_, since the protocol messages only need to refer to leaves in the tree.  <ins> Like nodes, leaves are numbered left to right.  The node with leaf index "k" is also called the "k-th" leaf.  Note that given the above numbering, a node is a leaf node if and only if it has an even node index, and a leaf node's leaf index is half its node index.  The leaf indices in the above tree are as follows: </ins> 0 = A the signature computation comprises all of the fields except for the signature field.  <ins> KeyPackage objects MUST contain at least three extensions, one of type "supported_versions", one of type "supported_ciphersuites", and one of type "lifetime".  The "supported_versions" and "supported_ciphersuites" extensions allow MLS session establishment to be safe from downgrade attacks on these two parameters (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </ins> As the "KeyPackage" is a structure which is stored in the Ratchet Tree and updated depending on the evolution of this tree, each time a Commit message is sent and processed.  These states are referred to as "epochs" and are uniquely identified among states of the group by eight-octet epoch values.  When a new group is  <ins> initialized, its initial state epoch is 0x0000000000000000.  Each time a state transition occurs, the epoch number is incremented by one. </ins> [[ OPEN ISSUE: It would be better to have non-linear epochs, in order to tolerate forks in the history.  There is a need to discuss whether