GroupState is not a group state, renaming to GroupContext (#166)

* GroupState is not a group state, renaming to GroupContext

* GroupContext, update according to Richard's comment

draft-ietf-mls-protocol.md

@@ -135,6 +135,10 @@ shared keys with costs that scale as the log of the group size.
 
 RFC EDITOR PLEASE DELETE THIS SECTION.
 
+draft-06
+
+- Rename the GroupState structure to GroupContext (\*)
+
 draft-05
 
 - Common framing for handshake and application messages (\*)
@@ -916,16 +920,16 @@ and only if the node is blank.
 
 ## Group State
 
-Each member of the group maintains a representation of the
-state of the group:
+Each member of the group maintains a GroupContext object that
+summarizes the state of the group:
 
 ~~~~~
 struct {
     opaque group_id<0..255>;
     uint32 epoch;
     opaque tree_hash<0..255>;
     opaque transcript_hash<0..255>;
-} GroupState;
+} GroupContext;
 ~~~~~
 
 The fields in this state have the following semantics:
@@ -942,7 +946,7 @@ The fields in this state have the following semantics:
 When a new member is added to the group, an existing member of the
 group provides the new member with a Welcome message.  The Welcome
 message provides the information the new member needs to initialize
-its GroupState.
+its GroupContext.
 
 Different group operations will have different effects on the group
 state.  These effects are described in their respective subsections
@@ -1040,7 +1044,7 @@ following information to derive new epoch secrets:
 
 * The init secret from the previous epoch
 * The update secret for the current epoch
-* The GroupState object for current epoch
+* The GroupContext object for current epoch
 
 Given these inputs, the derivation of secrets for an epoch
 proceeds as shown in the following diagram:
@@ -1051,20 +1055,20 @@ proceeds as shown in the following diagram:
                      V
 update_secret -> HKDF-Extract = epoch_secret
                      |
-                     +--> Derive-Secret(., "sender data", GroupState_[n])
+                     +--> Derive-Secret(., "sender data", GroupContext_[n])
                      |    = sender_data_secret
                      |
-                     +--> Derive-Secret(., "handshake", GroupState_[n])
+                     +--> Derive-Secret(., "handshake", GroupContext_[n])
                      |    = handshake_secret
                      |
-                     +--> Derive-Secret(., "app", GroupState_[n])
+                     +--> Derive-Secret(., "app", GroupContext_[n])
                      |    = application_secret
                      |
-                     +--> Derive-Secret(., "confirm", GroupState_[n])
+                     +--> Derive-Secret(., "confirm", GroupContext_[n])
                      |    = confirmation_key
                      |
                      V
-               Derive-Secret(., "init", GroupState_[n])
+               Derive-Secret(., "init", GroupContext_[n])
                      |
                      V
                init_secret_[n]
@@ -1414,29 +1418,29 @@ follows:
    described in {{message-framing}}.
 
 2. Verify that the `epoch` field of enclosing MLSPlaintext message
-   is equal the `epoch` field of the current GroupState object.
+   is equal the `epoch` field of the current GroupContext object.
 
 3. Verify that the signature on the MLSPlaintext message verifies
    using the public key from the credential stored at the leaf in
    the tree indicated by the `sender` field.
 
 4. Use the `operation` message to produce an updated, provisional
-   GroupState object incorporating the proposed changes.
+   GroupContext object incorporating the proposed changes.
 
 5. Use the `confirmation_key` for the new epoch to compute the
    confirmation MAC for this message, as described below, and verify
    that it is the same as the `confirmation` field in the
    GroupOperation object.
 
 6. If the the above checks are successful, consider the updated
-   GroupState object as the current state of the group.
+   GroupContext object as the current state of the group.
 
 The confirmation value confirms that the members of the group have
 arrived at the same state of the group:
 
 ~~~~~
 GroupOperation.confirmation =
-    HMAC(confirmation_key, GroupState.transcript\_hash)
+    HMAC(confirmation_key, GroupContext.transcript\_hash)
 ~~~~~
 
 HMAC {{!RFC2104}} uses the Hash algorithm for the ciphersuite in
@@ -1467,7 +1471,7 @@ group must take two actions:
 2. Send an Add message to the group (including the new member)
 
 The Welcome message contains the information that the new member
-needs to initialize a GroupState object that can be updated to the
+needs to initialize a GroupContext object that can be updated to the
 current state using the Add message.  This information is encrypted
 for the new member using HPKE.  The recipient key pair for the
 HPKE encryption is the one included in the indicated UserInitKey,
@@ -1511,15 +1515,15 @@ are revealed to the new member.
 Since the new member is expected to process the Add message for
 itself, the Welcome message should reflect the state of the group
 before the new user is added. The sender of the Welcome message can
-simply copy all fields from their GroupState object.
+simply copy all fields from their GroupContext object.
 
 [[ OPEN ISSUE: The Welcome message needs to be synchronized in the
 same way as the Add.  That is, the Welcome should be sent only if
 the Add succeeds, and is not in conflict with another, simultaneous
 Add. ]]
 
 An Add message provides existing group members with the information
-they need to update their GroupState with information about the new
+they need to update their GroupContext with information about the new
 member:
 
 ~~~~~
@@ -1548,7 +1552,7 @@ Add message.
 The client joining the group processes Welcome and Add
 messages together as follows:
 
-* Prepare a new GroupState object based on the Welcome message
+* Prepare a new GroupContext object based on the Welcome message
 * Process the Add message as an existing member would
 
 An existing member receiving a Add message first verifies
@@ -1636,7 +1640,7 @@ state as follows:
   last node of the tree
 
 Note that, in step 4, there must be at least one non-null element in
-the tree, since any valid GroupState must have the current member in
+the tree, since any valid GroupContext must have the current member in
 the tree and self-removal is prohibited. The same reasoning
 justifies the existence of a non-blank leaf in the ratchet tree in
 step 5.
@@ -1852,7 +1856,7 @@ this authentication scheme.]]
 
 [[ OPEN ISSUE: Currently, the group identifier, epoch and generation are
 contained as meta-data of the Signature. A different solution could be to
-include the GroupState instead, if more information is required to achieve
+include the GroupContext instead, if more information is required to achieve
 the security goals regarding cross-group attacks. ]]
 
 [[ OPEN ISSUE: Should the padding be required for handshake messages ?