Original text:
For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA with the NIST curves (P-256, P-384, or P-521), the public key <del> is the output of the uncompressed Elliptic-Curve-Point-to-Octet- String conversion according to SECG. </del>  The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA "new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The <del> "content_type" of the message MUST be "proposal"and the </del>  "proposal_type" of the Proposal MUST be "add". Recipients of an MLSMessage MUST verify the signature with the key 7.8. MLS hashes the contents of the tree in two ways to authenticate <del> different properties of the tree.  This section defines _tree hashes_, and _parent hashes_ are defined in parent-hashes. </del>  Each node in a ratchet tree has a tree hash that summarizes the subtree below that node.  The tree hash of the root is used in the perform an excessive number of key derivations.  For example, a malicious group member could send a message with "generation = 0xffffffff" at the beginning of a new epoch, forcing recipients to <del> perform billions of key derivations. </del>  15. Post-compromise security is provided between epochs by members regularly updating their leaf key in the ratchet tree.  Updating their leaf key prevents group secrets from continuing to be encrypted <del> to previously compromised public keys. </del>  Forward secrecy between epochs is provided by deleting private keys from past versions of the ratchet tree, as this prevents old group provided by deleting message encryption keys once they've been used to encrypt or decrypt a message. <del> Post-compromise security is also provided for new groups by members regularly generating new KeyPackages and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </del>  15.4.

Reviewer comments:
Comment by NAME I personally don't like the underscored words in the html rendering of the document It "blank" the new American spelling of "blanc" ? I find "summarizes" a strange word here. It is not the hash contains a summary one can read. [SECG] has no IETF equivalent? Should it? proposaland -> proposal and I would say "after removing member C" (avoid ambiguity about "every third") I read this wrong the first way, the "," vanishes due to the unscores. Maybe: This section defines tree hashes, the next section defines parent hashes. Or alternatively, leave onlthe the first sentence in 8.8, then put the remainder and next section in two subsections (so 8.8.1 and 8.8.2) Maybe: For example, a malicious group member could otherwise send Maybe: to public keys whose private key was previously compromised. This reads a little odd as "new groups" would have no history and thus no previous compromise.
Filed I think it's important to emphasize the terms being defined, and this seems more readable than a definition list. Note that a hash function is often called a "message digest", in the same sense as the "Weekly github digest" that goes to the mailing list. I think referring to SECG is still pretty state-of-the-art. But apparently RFC 8446 moved on from that, so I updated to use that representation.

Revised text:
For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified in RFC8032.  For ciphersuites using ECDSA with the NIST curves (P-256, P-384, or P-521), the public key  <ins> is represented as an encoded UncompressedPointRepresentation struct, as defined in RFC8446. </ins> The signatures used in this document are encoded as specified in RFC8446.  In particular, ECDSA signatures are DER-encoded and EdDSA "new_member_proposal": The signature key in the LeafNode in the KeyPackage embedded in an External Add Proposal.  The  <ins> "content_type" of the message MUST be "proposal" and the </ins> "proposal_type" of the Proposal MUST be "add". Recipients of an MLSMessage MUST verify the signature with the key 7.8. MLS hashes the contents of the tree in two ways to authenticate  <ins> different properties of the tree.  _Tree hashes_ are defined in this section, and _parent hashes_ are defined in parent-hashes. </ins> Each node in a ratchet tree has a tree hash that summarizes the subtree below that node.  The tree hash of the root is used in the perform an excessive number of key derivations.  For example, a malicious group member could send a message with "generation = 0xffffffff" at the beginning of a new epoch, forcing recipients to  <ins> perform billions of key derivations unless they apply limits of the type discussed above. </ins> 15. Post-compromise security is provided between epochs by members regularly updating their leaf key in the ratchet tree.  Updating their leaf key prevents group secrets from continuing to be encrypted  <ins> to public keys whose private keys had previously been compromised. </ins> Forward secrecy between epochs is provided by deleting private keys from past versions of the ratchet tree, as this prevents old group provided by deleting message encryption keys once they've been used to encrypt or decrypt a message.  <ins> New groups are also at risk of using previously compromised keys (as with post-compromise security), if a member is added to a new group via an old KeyPackage whose corresponding private key has been compromised.  This risk can be mitigated by having clients regularly generate new KeyPackages and upload them to the Delivery Service. This way, the key material used to add a member to a new group is more likely to be fresh and less likely to be compromised. </ins> 15.4.