Original text:
which includes both public and private data.  An initial state, including an initial set of participants, is set up by a group creator using the _Init_ algorithm and based on information pre- <del> published by the initial members.  The creator sends the _GroupInit_ </del>  message to the participants, who can then set up their own group state and derive the same shared secret.  Participants then exchange messages to produce new shared states which are causally linked to roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees. <del> The "transcript" field contains the list of "GroupOperation" </del>  messages that led to this state. When a new member is added to the group, an existing member of the When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero <del> vector of length Hash.length. </del>  5.8. object and consider the Handshake message invalid. Use the "confirmation_key" for the new group state to compute the <del> finished MAC for this message, as described below, and verify that it is the same as the "finished_mac" field. </del>  If the the above checks are successful, consider the updated GroupState object as the current state of the group. transcript of group operations, using the transcript hash from the provisional GroupState object:  HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster. the removed leaf An existing participant receiving a Remove message first verifies the <del> signature on the message, then verifies its identity proof against the identity tree held by the participant.  The participant then updates its state as follows: </del>  Update the roster by setting the credential in the removed slot to the null optional value

Reviewer comments:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks

Revised text:
which includes both public and private data.  An initial state, including an initial set of participants, is set up by a group creator using the _Init_ algorithm and based on information pre-  <ins> published by the initial members.  The creator sends the _Init_ </ins> message to the participants, who can then set up their own group state and derive the same shared secret.  Participants then exchange messages to produce new shared states which are causally linked to roster, since this is the number of nodes in a tree with "size" leaves, according to the structure described in ratchet-trees.  <ins> The "transcript_hash" field contains the list of "GroupOperation" </ins> messages that led to this state. When a new member is added to the group, an existing member of the When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero  <ins> vector of length Hash.length, where the Hash algorithm is defined by the ciphersuite. </ins> 5.8. object and consider the Handshake message invalid. Use the "confirmation_key" for the new group state to compute the  <ins> "confirmation" MAC for this message, as described below, and verify that it is the same as the "confirmation" field. </ins> If the the above checks are successful, consider the updated GroupState object as the current state of the group. transcript of group operations, using the transcript hash from the provisional GroupState object: <ins> [[ OPEN ISSUE: The confirmation data and signature data should probably cover the same data as the one we cover with the GroupState. ]] </ins> HMAC RFC2104 uses the Hash algorithm for the ciphersuite in use. Sign uses the signature algorithm indicated by the signer's credential in the roster. the removed leaf An existing participant receiving a Remove message first verifies the  <ins> signature on the message.  The participant then updates its state as follows: </ins> Update the roster by setting the credential in the removed slot to the null optional value