Original text:
(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension <del> (I-D.ietf-tls-tls13, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (I-D.ietf-tls-tls13, Section 4.3.2), it indicates the support for compressed client certificates. </del>  By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from <del> intercepting it, that is, TLS version 1.3 I-D.ietf-tls-tls13 and higher. </del>  7. 7.1. Create an entry, compress_certificate(27), in the existing registry <del> for ExtensionType (defined in I-D.ietf-tls-tls13), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </del>  7.2. Create an entry, compressed_certificate(25), in the existing registry <del> for HandshakeType (defined in RFC5246). </del>  7.3. over the open Internet. The procedures for requesting values in the Specification Required <del> space are specified in I-D.ietf-tls-iana-registry-updates. </del> 

Reviewer comments:
When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.

Revised text:
(compress_certificate(27)), which can be used to signal the supported compression formats for the Certificate message to the peer. Whenever it is sent by the client as a ClientHello message extension  <ins> (RFC8446, Section 4.1.2), it indicates the support for compressed server certificates.  Whenever it is sent by the server as a CertificateRequest extension (RFC8446, Section 4.3.2), it indicates the support for compressed client certificates. </ins> By sending a compress_certificate extension, the sender indicates to the peer the certificate compression algorithms it is willing to use that adopt certificate compression.  Because of that, the extension is only supported in the versions of TLS where the certificate message is encrypted in a way that prevents middleboxes from  <ins> intercepting it, that is, TLS version 1.3 RFC8446 and higher. </ins> 7. 7.1. Create an entry, compress_certificate(27), in the existing registry  <ins> for ExtensionType (defined in RFC8446), with "TLS 1.3" column values being set to "CH, CR", and "Recommended" column being set to "Yes". </ins> 7.2. Create an entry, compressed_certificate(25), in the existing registry  <ins> for HandshakeType (defined in RFC8446). </ins> 7.3. over the open Internet. The procedures for requesting values in the Specification Required  <ins> space are specified in RFC8447. </ins>