Change:
has renamed entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. <del> [SHALL replace/has replaced] the reference to RFC8447 with a reference to this document in the "Reference" column for entry 35. </del> <ins> [SHALL replace] the references to RFC8447 with a reference to this document in the "Reference" column for entry 35. </ins> 7. <del> Experience has shown that the IETF Review registry policy for TLS extensions was too strict.  Based on WG consensus, the decision was taken to change the registration policy to Specification Required while reserving a small part of the code space for Private Use RFC8126.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry as follows: </del> <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ExtensionType Values registry as follows: </ins> <del> Changed the registry policy to: </del> <ins> Change the registry policy to: </ins> <del> Updated the "Reference" to refer to this document instead of RFC8447. </del> <ins> Add a reference to this document under the reference heading. </ins> <del> See expert-pool for additional information about the designated expert pool. Despite wanting to "loosen" the registration policies for TLS extensions, it is still useful to indicate in the IANA registry which extensions the WG recommends be supported.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry as follows: Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Y", "truncated_hmac" (4) and "connection_id (deprecated)" (53) as "D", and all others as "N".  The "Recommended" column is assigned a value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126.  IESG Approval is REQUIRED for a Y->N, Y->D, and D->Y|N transitions. </del> <ins> Update the "Recommended" column with the changes as listed below. This table has been generated by keeping existing "Y" and "N" entries except for "truncated_hmac" (4), "connection_id (deprecated)" (53), "reserved" (40) and "Reserved" (46) as "D".  A reference to this document SHALL be added to these entries. </ins> <del> IANA [SHALL update/has added] the following notes: The extensions added by I-D.ietf-tls-rfc8446bis are omitted from the above table.  Likewise, extensions defined after RFC8447 are also not listed in the table as those RFCs specify the value of the extension's "Recommended"; extensions points defined after RFC8447 include token_binding, compress_certificate, record_size_limit, pwd_protect, pwd_clear, password_salt, ticket_pinning, tls_cert_with_extern_psk, delegated_credentials, supported_ekt_ciphers, connection_id, external_id_hash, external_session_id, quic_transport_parameters, ticket_request, and dnssec_chain. I-D.ietf-tls-rfc8446bis also uses the TLS ExtensionType Values registry originally created in RFC4366.  The following text is from I-D.ietf-tls-rfc8446bis and is included here to ensure alignment between these specifications. IANA [SHALL update/has updated] this registry to include the "key_share", "pre_shared_key", "psk_key_exchange_modes", "early_data", "cookie", "supported_versions", "certificate_authorities", "oid_filters", "post_handshake_auth", and "signature_algorithms_cert", extensions with the values defined in I-D.ietf-tls-rfc8446bis and the "Recommended" value of "Y". IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column that lists the messages in which the extension may appear.  This column [SHALL be/has been] initially populated from the table in Section 4.2 of I-D.ietf-tls-rfc8446bis with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3. </del> <ins> Update the following note on the recommended column </ins> 8.

Discussion:
It might be clearer to have the document update RFC 8447 instead of obsolete. This would make the changes more targeted and may make the document easier to review and apply to the existing registry. It also contains text for issue
rewrote Extensions section as an update instead of obsolete. Included proposal for recommended note
Obsoleting RFC 8447 means duplicating a lot of text and making changes to it which makes the document have awkward wording and makes the changes difficult to follow. I think it would be clearer if it were an update and just listed the changes. see Extension Types PR
At IETF 115, there was general agreement that this document could be an update as opposed to an obsolete to make it easier on IANA.
Some registries have values that are reserved because the values were "burned". These values are not in private use space but are mid-range, 40 in the ExtensionType registry. Should we mark these as "D"?
I think we should make those as D. Addressed in PR
NAME agreed. Will close this out.
Currently the I-D includes the following note: Note: : If an item is not marked as "Recommended", it does not necessarily mean that it is flawed; rather, it indicates that the item either has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases. Now that we have three values do we need to expand this to also include "D".
Proposed text in PR