Change:
6.7.1.1.1. <del> ACP IPsec implementations MUST comply with RFC8221 (and its updates), with the following modifications to simplify hardware accelerated ACP IPsec implementation requirements by eliminating requirements for legacy or cryptographically weak options. ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload that may not be encrypted by itself when carrying legacy management protocol traffics as well as hop-by- hop GRASP, which is designed to rely on the ACP for confidentiality of hop-by-hop distributed information.  Therefore, IPsec MUST support ESP and MUST NOT use AH.  For ESP, ENCR_NULL MUST NOT be used for ACP secure channels. </del> <ins> ACP IPsec implementations MUST comply with RFC8221 (and its updates). The following additional guidance is provided The ACP MUST NOT use any NULL encryption option due to the confidentiality of ACP payload.  All other MUST and SHOULD algorithms specified by RFC8221 (and replacement documents) are to be supported. The order of the proposals is not specified by RFC8221.  The first protocol offered which is supported by both ends is generally chosen, and so this document recommends listing the higher performance protocols first. The ENCR_AES_GCM_16 is listed as a MUST in RFC8221 and is often the faster protocol, so it is to be listed first. If an ACP node can perform ENCR_AES_CBC, or ENCR_AES_CCM_8 at higher performance than ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305, then those should be listed first in the policy. ENCR_AES_GCM_16 is preferred, but: There is no unconditional requirement against ENCR_AES_CBC use. </ins> <del> Only ENCR_AES_GCM_16 is REQUIRED as an encryption algorithm for ACP secure channels with ESP. If an ACP node can perform ENCR_AES_CBC, ENCR_AES_CCM_8 at higher performance than ENCR_AES_GCM_16 or ENCR_CHACHA20_POLY1305 at equal or higher performance than ENCR_AES_GCM_16 then that ACP node SHOULD support such an encryption algorithm and prefer it in the IKEv2 negotiation if its performance is higher than that of ENCR_AES_GCM_16.  Otherwise there are no normative requirements against either of these options.  These requirements are overriding the MUST/SHOULD/SHOULD requirements of RFC8221 for these three algorithms for the following reasons: There is no unconditional requirement against ENCR_AES_CBC because ENCR_AES_GCM_16 is assumed to be feasible with less cost/higher higher performance in modern devices hardware accelerated implementations compared to ENCR-AES_CBC. AES-GCM is an authenticated encryption with associated data (AEAD) cipher mode, so no ESP authentication algorithm requirement is needed (unless further encryption algorithms are supported), further simplifying ACP IPsec implementations. there is no requirement to interoperate with legacy equipment in ACP secure channels, so a single MTI encryption algorithm for IPsec in ACP secure channels is sufficient for interoperability. There is no unconditional requirement against ENCR_AES_CCM_8 because it is currently not likely that it would be preferrable in ACP secure channels for more constrained IoT devices over options such as DTLS.  In RFC8221 this algorithm is more desirable, because of solutions relying only on IPsec without such non-IPsec alternatives. There is no unconditional requirement against ENCR_CHACHA20_POLY1305 because there is currently no mechanism in the ACP to migrate all secure channels in an ACP domain to a different preferred encryption algorithm in the case of future discovered crypto weaknesses of AES.  Once such mechanisms are defined, ENCR_CHACHA20_POLY1305 would be a good encryption algorithm, but due to the transitive traffic through ACP secure channels only when this does not result in an unexpected drop in performance. When using AES for encryption, keys less than 256 bits MUST NOT be used, and 256-bit keys MUST be supported. Once there are updates to RFC8221, these should accordingly be reflected in updates to these ACP requirements, for example if ENCR_AES_GCM_16 was to be superceeded in the future. </del> <ins> ENCR_AES_GCM_16 is assumed to be feasible with less cost/higher higher performance in modern devices hardware accelerated implementations compared to ENCR-AES_CBC. AES-GCM is an authenticated encryption with associated data (AEAD) cipher mode, so no ESP authentication algorithm requirement is needed (unless further encryption algorithms are supported), further simplifying ACP IPsec implementations. there is no requirement to interoperate with legacy equipment in ACP secure channels, so a single MTI encryption algorithm for IPsec in ACP secure channels is sufficient for interoperability. RFC8221 allows for 128-bit or 256-bit AES keys.  This document mandates that only 256-bit AES keys MUST be supported. When RFC8221 is updated, ACP implementations will need to consider legacy interoperability, and the IPsec WG has generally done a very good job of taking that into account in its recommendations. </ins> 6.7.1.1.2. <del> IKEv2 for ACP secure channels MUST support the requirements of RFC8247 (as necessary to support the above described modified RFC8221 requirements for IPsec via ESP).  Because IKEv2 for ACP secure channels is sufficient to be implemented in control plane software as opposed to ESP (which may need to be implemented in accelerated forwarding plane for sufficient performance), there are no restrictions on the requirements of RFC8247 for ACP secure channels. Instead, the following paragraphs describe additional or stricter requirements necessary for the authentication of ACP secure channels in IKEv2 via ACP domain certificates. IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP) MUST be supported (in addition to 2048-bit MODP).  ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. </del> <ins> RFC8247 provides a baseline recommendation for mandatory to implement ciphers, integrity checks, pseudo-random-functions and Diffie-Hellman mechanisms.  Those recommendations, and the recommendations of subsequent documents apply well to the ACP.  Because IKEv2 for ACP secure channels is sufficient to be implemented in control plane software, rather than in ASIC hardware, this documents makes no changes to the recommendations. This document does establish a policy statement as permitted by RFC8247 for the specific case of ACP traffic. The IKEv2 Diffie-Hellman key exchange group 19 (256-bit random ECP), listed as a SHOULD, is to be configured, as long as with the 2048-bit MODP (group 14).  The ECC provides a similar security level to finite-field (MODP) key exchange with a shorter key length, so is generally preferred absent other considerations. </ins> IKEv2 authentication MUST use the ACP domain certificates.  The Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be supported (see IKEV2IANA for this and other IANA IKEv2 parameter names used in this text).  If certificate chains are used, all <del> intermediate certificates up to, but not including the locally provisioned trust anchor certificate must be signaled. </del> <ins> intermediate certificates up to, and including the locally provisioned trust anchor certificate must be signaled.  While the top-trust anchor will never be used by a properly configured peer, it can provide a significant amount of useful information to debug an ACP network.  There is some small concern that it might provide useful information to an attacker about who the network is, the other certificates that are sent already clearly indicate this information. </ins> A certificate payload with the ACP certificate MUST be included during IKEv2 authentication to support the ACP domain membership

Discussion:
I've done some slight editing of your text for readability. I have removed text that is repeating RFC8247 and RFC8221 poorly, leveraging those documents better. I have made a change to say that trust anchor certificates should be sent. (Believe me, without that, it makes debugging really difficult)