Draft: draft-ietf-mls-protocol

Commentary: Previously we used [ [ ... ] ] for comments , and the body of the comment was only getting elided because the compiler did n't know what that syntax meant . 
 Please do n't remove the .editorconfig file again ! It 's a for projects to have ! !
Paragraph (version A):
Each of these operations is "proposed" by sending a message of the
corresponding type (Add / Update / Remove).  The state of the group
is not changed, however, until a Commit message is sent to provide
the group with fresh entropy.  In this section, we show each proposal
being committed immediately, but in more advanced deployment cases,
an application might gather several proposals before committing them
all at once.
Paragraph (version A):
When a client A wants to establish a group with B and C, it first
downloads KeyPackages for B and C.  It then initializes a group state
containing only itself and uses the KeyPackages to compute Welcome
and Add messages to add B and C, in a sequence chosen by A.  The
Welcome messages are sent directly to the new members (there is no
need to send them to the group).  The Add messages are broadcast to
the group, and processed in sequence by B and C.  Messages received
before a client has joined the group are ignored.  Only after A has
received its Add messages back from the server does it update its
state to reflect their addition.
Paragraph (version A):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download a KeyPackage for a new client and
broadcast an Add message that the current group can use to update
their state and a Welcome message that the new client can use to
initialize its state.
Paragraph (version A):
To enforce forward secrecy and post-compromise security of messages,
each member periodically updates their leaf secret.  Any member can
update this information at any time by generating a fresh KeyPackage
and sending an Update message followed by a Commit message.  Once all
members have processed both, the group's secrets will be unknown to
an attacker that had compromised the sender's prior leaf secret.
Paragraph (version A):
It is left to the application to determine a policy for regularly
sending Update messages.  This policy can be as strong as requiring
an Update+Commit after each application message, or weaker, such as
once every hour, day...
Paragraph (version B):
Each of these operations is "proposed" by sending a message of the
corresponding type (Add / Update / Remove).  The state of the group
is not changed, however, until a Commit message is sent to provide
the group with fresh entropy.  In this section, we show each proposal
being committed immediately, but in more advanced deployment cases an
application might gather several proposals before committing them all
at once.
Paragraph (version B):
When a client A wants to establish a group with B and C, it first
initializes a group state containing only itself and downloads
KeyPackages for B and C.  For each member, A generates an Add and
Commit message adding that member, and broadcasts them to the group.
It also generates a Welcome message and sends this directly to the
new member (there's no need to send it to the group).  Only after A
has received its Commit message back from the server does it update
its state to reflect the new member's addition.
Paragraph (version B):
Upon receiving the Welcome message and the corresponding Commit, the
new member will be able to read and send new messages to the group.
Messages received before the client has joined the group are ignored.
Paragraph (version B):
Subsequent additions of group members proceed in the same way.  Any
member of the group can download a KeyPackage for a new client and
broadcast an Add message that the current group can use to update
their state, and a Welcome message that the new client can use to
initialize its state.
Paragraph (version B):
To enforce the forward secrecy and post-compromise security of
messages, each member periodically updates their leaf secret.  Any
member can update this information at any time by generating a fresh
KeyPackage and sending an Update message followed by a Commit
message.  Once all members have processed both, the group's secrets
will be unknown to an attacker that had compromised the sender's
prior leaf secret.
Paragraph (version B):
Update messages should be sent at regular intervals of time as long
as the group is active, and members that don't update should
eventually be removed from the group.  It's left to the application
to determine an appropriate amount of time between Updates.
Paragraph (version B):
Initial leaf keys are known only by their owner and the group
creator, because they are derived from an authenticated key exchange
protocol.  Subsequent leaf keys are known only by their owner.