Change:
11.1.6. <ins> An ExternalInitSecret proposal is used by new members that want to join a group by using an external commit.  This propsal can only be used in that context. The field "kem_output" contains the encrypted "external_seed" as described in computing-the-external-init-secret. 11.1.7. </ins> Add and Remove proposals can be constructed and sent to the group by a party that is outside the group.  For example, a Delivery Service might propose to remove a member of a group who has been inactive for

Discussion:
Sofía noted "It is also unclear at some points the notation used for the Diffie-Hellman or Elliptic Curve parameters. Related to this, is unsure if this protocol takes into account the cofactor issues."
What precisely is unclear? X25519 specifies the scalar-clamping that's used to remove the 8-torsion part of the given curve point. And P-256 is a prime curve, so it has no cofactor.
Well, it only says: It does not refer that you are referring to section 'The X25519 and X448 Functions' of the RFC (if so). And actually, I think it is referred to the subsection in that section where is says "To implement the X25519(k, u) and X448(k, u)". It also says: which does not recommend taking into account that "For X25519, in order to decode 32 random bytes as an integer scalar, set the three least significant bits of the first byte and the most significant bit of the last to zero, set the second most significant bit of the last byte to 1 and, finally, decode as little-endian. " (the clamping mechanism). It is a little bit unclear from the text how the generation of the shared secret happens, as it does not point to an specific part of the RFC, nor specify if the encoding/decoding functions are needed. But this is just my read ;) Precisely. But this section is a little bit more defined. Compare: :)
And around unclear: The definition of used to derive the private key, is defined as "The ciphersuite must also specify an algorithm Derive-Key-Pair that maps octet strings with the same length as the output of the hash function to key pairs for the asymmetric encryption scheme.". It is unclear how this algorithm looks in practice. It seems to imply that this function takes any amount of same length octet strings as input (generated as an output of a hash function) and map to create a private key and a public key somehow.It says "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 Curve25519 private key.) The corresponding public key is X25519(SHA-256(X), 9)."

If you don't read the RFC, it is unclear that the "9 is the u-coordinate of the base point and is encoded as a byte with value 9, followed by 31 zero bytes". It also does not specify if the private key should have been generated from randomness.When saying "Encryption keys are derived from shared secrets by taking the first 16 bytes of H(Z), where Z is the shared secret and H is SHA-256.", it seems like 'H(input)' could be defined somewhere else previously. Maybe it should be in place to have a definition section for the different functions, like on the RFC7748 in "3. Notation"?When it says "Generate an ephemeral DH key pair (x, x G) in the DH group specified by the ciphersuite in use", does this refer only to the usage of elliptic curves (as it generates the public key as 'xG'? Maybe if it is DH, it should be noted as 'g^x'? This is just some things that were unclear for me when reading :) Perhaps they are discussed somewhere else. It also depends on how self-contained that document wants to be. Hope this helps :)
Ah, ok. These seem like fair points. I had thought that X25519 specifies that clamping be done on every call to , but I see now that it's done once in the decoding step and then never again. Also that P-256 excerpt was very informative. Thanks!