Original text:
is the concatenation of that node's parent along with the parent's direct path.  The _copath_ of a node is the node's sibling concatenated with the list of siblings of all the nodes in its direct <del> path.  The _frontier_ of a tree is the list of heads of the maximal full subtrees of the tree, ordered from left to right. </del>  For example, in the below tree: The copath of C is (D, AB, EFG) <del> The frontier of the tree is (ABCD, EF, G) </del> Each node in the tree is assigned a _node index_, starting at zero and running from left to right.  A node is a leaf node if and only if it has an even index.  The node indices for the nodes in the above generated value to provide post-compromise security. The generator of the Commit starts by using the HPKE secret key <del> "leaf_hpke_secret_key" associated with the new leaf ClientInitKey (see initialization-keys) to compute "path_secret[0]" and generate a </del>  sequence of "path secrets", one for each ancestor of its leaf.  That is, path_secret[0] is used for the node directly above the leaf, path_secret[1] for its parent, and so on.  At each step, the path For example, suppose there is a group with four members: If member B subsequently generates a Commit based on a secret <del> "leaf_hpke_secret_key", then it would generate the following sequence of path secrets and node secrets: </del>  After the Commit, the tree will have the following structure, where <del> "ns[i]" represents the node_secret values generated as described above: </del>  5.5. algorithm described above. The recipient SHOULD verify that the received public keys agree <del> with the public keys derived from the new node_secret values. </del>  Merge the updated path secrets into the tree. always has a zero-length hash for this value. For nodes where an updated path secret was computed in step 1, <del> compute the corresponding node secret and node key pair and replace the values stored at the node with the computed values. </del>  For example, in order to communicate the example update described in the previous section, the sender would transmit the following values: The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm <del> specified in credential fielf of ClientInitKeys. </del>  The ciphersuites are defined in section mls-ciphersuites. <del> 6.1.1. </del> Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification.  <del> 6.1.1.1. Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-256(X) (Recall that any 32-octet string is a valid X25519 private key).  The corresponding public key is X25519(SHA-256(X), 9). Implementations SHOULD use the approach specified in RFC7748 to calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of </del>  <del> 6.1.1.2. </del>  <del> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-512(X) truncated to 448 bits (Recall that any 56-octet string is a valid X448 private key).  The corresponding public key is X448(SHA-512(X), 5). </del>  <del> Implementations SHOULD use the approach specified in RFC7748 to </del>  calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic <del> curves, they SHOULD perform the additional checks specified in </del>  Section 7 of <del> 6.1.1.3. </del>  <del> Given an octet string X, the private key produced by the Derive-Key- Pair operation is SHA-256(X), interpreted as a big-endian integer. The corresponding public key is the result of multiplying the standard P-256 base point by this integer. </del>  <del> P-256 ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE1363 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point </del>  represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given

Reviewer comments:
This deals cleanly with groups where the private key size doesn't align neatly with a hash function output size (e.g., X448), and saves a few hash invocations by removing intermediate values. A few editorial changes are included here as well. Depends on .
As discussed on call, folks are comfortable with this. Ready to merge, pending
Please merge when get a chance.

Revised text:
is the concatenation of that node's parent along with the parent's direct path.  The _copath_ of a node is the node's sibling concatenated with the list of siblings of all the nodes in its direct  <ins> path. </ins> For example, in the below tree: The copath of C is (D, AB, EFG)  Each node in the tree is assigned a _node index_, starting at zero and running from left to right.  A node is a leaf node if and only if it has an even index.  The node indices for the nodes in the above generated value to provide post-compromise security. The generator of the Commit starts by using the HPKE secret key  <ins> "leaf_hpke_secret" associated with the new leaf ClientInitKey (see initialization-keys) to compute "path_secret[0]" and generate a </ins> sequence of "path secrets", one for each ancestor of its leaf.  That is, path_secret[0] is used for the node directly above the leaf, path_secret[1] for its parent, and so on.  At each step, the path For example, suppose there is a group with four members: If member B subsequently generates a Commit based on a secret  <ins> "leaf_hpke_secret", then it would generate the following sequence of path secrets: </ins> After the Commit, the tree will have the following structure, where  <ins> "np[i]" represents the node_priv values generated as described above: </ins> 5.5. algorithm described above. The recipient SHOULD verify that the received public keys agree  <ins> with the public keys derived from the new path_secret values. </ins> Merge the updated path secrets into the tree. always has a zero-length hash for this value. For nodes where an updated path secret was computed in step 1,  <ins> compute the corresponding node key pair and replace the values stored at the node with the computed values. </ins> For example, in order to communicate the example update described in the previous section, the sender would transmit the following values: The signature algorithm specified in the ciphersuite is the mandatory algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm  <ins> specified in credential field of ClientInitKeys. </ins> The ciphersuites are defined in section mls-ciphersuites.  Depending on the Diffie-Hellman group of the ciphersuite, different rules apply to private key derivation and public key verification. <ins> For all ciphersuites defined in this document, the Derive-Key-Pair function begins by deriving a "key pair secret" of appropriate length, then converting it to a private key in the required group. The ciphersuite specifies the required length and the conversion. </ins>  <ins> 6.1.1. </ins>  <ins> For X25519, the key pair secret is 32 octets long.  No conversion is required, since any 32-octet string is a valid X25519 private key. The corresponding public key is X25519(SHA-256(X), 9). </ins>  <ins> For X448, the key pair secret is 56 octets long.  No conversion is required, since any 56-octet string is a valid X448 private key.  The corresponding public key is X448(SHA-256(X), 5). </ins>  <ins> Implementations MUST use the approach specified in RFC7748 to </ins> calculate the Diffie-Hellman shared secret.  Implementations MUST check whether the computed Diffie-Hellman shared secret is the all- zero value and abort if so, as described in Section 6 of RFC7748.  If implementers use an alternative implementation of these elliptic  <ins> curves, they MUST perform the additional checks specified in </ins> Section 7 of  <ins> 6.1.1.1. </ins>  <ins> For P-256, the key pair secret is 32 octets long.  For P-521, the key pair secret is 66 octets long.  In either case, the private key derived from a key pair secret is computed by interpreting the key pair secret as a big-endian integer. </ins>  <ins> ECDH calculations for these curves (including parameter and key generation as well as the shared secret calculation) are performed according to IEEE1363 using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the shared secret is the x-coordinate of the ECDH shared secret elliptic curve point </ins> represented as an octet string.  Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given