Draft: draft-ietf-mls-protocol

Commentary: 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
Paragraph (version A):
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
the same size.  If a subtree is full and it is not a subset of any
other full subtree, then it is _maximal_.
Paragraph (version A):
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.
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.
Paragraph (version B):
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
the same size.
Paragraph (version B):
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
The group thus evolves from one cryptographic state to another 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
initialized, its initial state epoch 0x0000000000000000.  Each time a
state transition occurs, the epoch number is incremented by one.
Paragraph (version B):
The group thus evolves from one cryptographic state to another 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
initialized, its initial state epoch is 0x0000000000000000.  Each
time a state transition occurs, the epoch number is incremented by
one.