Original text:
client's appearance in the group, signed by that client: The "public_key" field conains an HPKE public key whose private key <del> is held only by the member occupying this leaf.  The "credential" contains authentication information for this member, as described in credentials. </del>  The "capabilities" field indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are the "extensions" field of the "capabilities" field. The "leaf_node_source" field indicates how this LeafNode came to be <del> added to the tree. </del>  In the case where the leaf was added to the tree based on a pre- published KeyPackage, the "lifetime" field represents the times The client verifies the validity of a LeafNode using the following steps: <del> Verify that the credential in the KeyPackage is valid according to </del>  the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the <del> protocol the KeyPackage is being verified with the following exception: If the KeyPackage is an update to another KeyPackage, the authentication service MUST additionally validate that the set of identities attested by the credential in the new KeyPackage is </del>  acceptable relative to the identities attested by the old credential. Verify the "lifetime" field: <del> When validating a downloaded KeyPackage, the current time MUST be within the "lifetime" range.  A KeyPackage that is expired or not yet valid MUST NOT be sent in an Add proposal. </del>  When receiving an Add or validating a tree, checking the "lifetime" is RECOMMENDED, if it is feasible in a given for the context in which the LeafNode is being validated (as defined in ratchet-tree-node-contents). <del> Verify that the following fields in the KeyPackage are unique among the members of the group (including any other members added in the same Commit): </del>  "public_key" "credential.signature_key"  8.2. In order to provide forward secrecy and post-compromise security, A protocol version and ciphersuite that the client supports, a public key that others can use to encrypt a Welcome message to <del> this client, and </del>  the content of the leaf node that should be added to the tree to represent this client. multiple ciphersuites. The value for "init_key" MUST be a public key for the asymmetric <del> encryption scheme defined by cipher_suite, and it MUST be unique </del>  among the set of KeyPackages created by this client.  Likewise, the "leaf_node" field MUST be valid for the ciphersuite, including both <del> the "hpke_key" and "credential" fields.  The whole structure is </del>  signed using the client's signature key.  A KeyPackage object with an invalid signature field MUST be considered malformed. explicit signal of the intended version to the other members of group when they receive the KeyPackage in an Add proposal. <del> The "capabilities" field in the "leaf_node" allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. </del>  <del> The "leaf_node_source" field of the LeafNode in a KeyPackage MUST be set to "key_package". </del>  11.1. The client verifies the validity of a KeyPackage using the following steps: <del> Verify the LeafNode in the KeyPackage according to the process defined in leaf-node-validation. Verify that the signature on the KeyPackage is valid using the public key in the LeafNode's credential Verify that the ciphersuite and protocol version of the LeafNode </del>  match those in use in the group. <del> 11.2. </del>  <del> The "capabilities" extension indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are supported by a client.  Proposal types defined in this document are considered "default" and thus need not be listed. This extension MUST be always present in a KeyPackage.  Extensions that appear in the "extensions" field of a KeyPackage MUST be included in the "extensions" field of the "capabilities" extension. 11.3. The "lifetime" extension represents the times between which clients will consider a KeyPackage valid.  This time is represented as an absolute time, measured in seconds since the Unix epoch (1970-01-01T00:00:00Z).  A client MUST NOT use the data in a KeyPackage for any processing before the "not_before" date, or after the "not_after" date. Applications MUST define a maximum total lifetime that is acceptable for a KeyPackage, and reject any KeyPackage where the total lifetime is longer than this duration. This extension MUST always be present in a KeyPackage. </del>  <del> 11.4. </del>  Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows

Reviewer comments:
This PR picks up changes from clarifying and cleaning up a few issues around LeafNode.
A big improvement in readability and correctness.

Revised text:
client's appearance in the group, signed by that client: The "public_key" field conains an HPKE public key whose private key  <ins> is held only by the member occupying this leaf (or in the case of a LeafNode in a KeyPackage object, the issuer of the KeyPackage).  The "credential" contains authentication information for this member, as described in credentials. </ins> The "capabilities" field indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are the "extensions" field of the "capabilities" field. The "leaf_node_source" field indicates how this LeafNode came to be  <ins> added to the tree.  This signal tells other members of the group whether the leaf node is required to have a "lifetime" or "parent_hash", and whether the "group_id" is added as context to the signature.  Whether these fields can be computed by the client represented by the LeafNode depends on when the LeafNode was created. For example, a KeyPackage is created before the client knows which group it will be used with, so its signature can't bind to a "group_id". </ins> In the case where the leaf was added to the tree based on a pre- published KeyPackage, the "lifetime" field represents the times The client verifies the validity of a LeafNode using the following steps:  <ins> Verify that the credential in the LeafNode is valid according to </ins> the authentication service and the client's local policy.  These actions MUST be the same regardless of at what point in the  <ins> protocol the LeafNode is being verified with the following exception: If the LeafNode is an update to another LeafNode, the authentication service MUST additionally validate that the set of identities attested by the credential in the new LeafNode is </ins> acceptable relative to the identities attested by the old credential. Verify the "lifetime" field:  <ins> When validating a LeafNode in a KeyPackage before sending an Add proposal, the current time MUST be within the "lifetime" range.  A KeyPackage containing a LeafNode that is expired or not yet valid MUST NOT be sent in an Add proposal. </ins> When receiving an Add or validating a tree, checking the "lifetime" is RECOMMENDED, if it is feasible in a given for the context in which the LeafNode is being validated (as defined in ratchet-tree-node-contents).  <ins> Verify that the following fields in the LeafNode are unique among the members of the group (including any other members added in the same Commit): </ins> "public_key" "credential.signature_key" <ins> Verify that the extensions in the leaf node are supported.  The ID for each extension in the "extensions" field MUST be listed in the field "capabilities.extensions" of the LeafNode. </ins> 8.2. In order to provide forward secrecy and post-compromise security, A protocol version and ciphersuite that the client supports, a public key that others can use to encrypt a Welcome message to  <ins> this client, (an "init key") and </ins> the content of the leaf node that should be added to the tree to represent this client. multiple ciphersuites. The value for "init_key" MUST be a public key for the asymmetric  <ins> encryption scheme defined by "cipher_suite", and it MUST be unique </ins> among the set of KeyPackages created by this client.  Likewise, the "leaf_node" field MUST be valid for the ciphersuite, including both  <ins> the "public_key" and "credential" fields.  The whole structure is </ins> signed using the client's signature key.  A KeyPackage object with an invalid signature field MUST be considered malformed. explicit signal of the intended version to the other members of group when they receive the KeyPackage in an Add proposal.  <ins> The field "leaf_node.capabilities" indicates what protocol versions, ciphersuites, protocol extensions, and non-default proposal types are supported by the client.  (Proposal types defined in this document are considered "default" and not listed.)  This information allows MLS session establishment to be safe from downgrade attacks on the parameters described (as discussed in group-creation), while still only advertising one version / ciphersuite per KeyPackage. The field "leaf_node.leaf_node_source" of the LeafNode in a KeyPackage MUST be set to "key_package". </ins>  <ins> Extension included in the "extensions" or "leaf_node.extensions" fields MUST be included in the "leaf_node.capabilities" field. </ins> 11.1. The client verifies the validity of a KeyPackage using the following steps:  <ins> Verify that the ciphersuite and protocol version of the KeyPackage </ins> match those in use in the group.  <ins> Verify the "leaf_node" field of the KeyPackage according to the process defined in leaf-node-validation. </ins>  <ins> Verify that the signature on the KeyPackage is valid using the public key in "leaf_node.credential". </ins>  <ins> 11.2. </ins> Within MLS, a KeyPackage is identified by its hash (see, e.g., joining-via-welcome-message).  The "external_key_id" extension allows