Change:
might have consensus to leave an items marked as "N" on the basis of it having limited applicability or usage constraints. <del> D: Indicates that the item is discouraged and SHOULD NOT or MUST NOT be used.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. </del> <ins> D: Indicates that the item is discouraged.  This marking could be used to identify mechanisms that might result in problems if they are used, such as a weak cryptographic algorithm or a mechanism that might cause interoperability problems in deployment. Implementers SHOULD consult the linked references associated with the item to determine the conditions under which it SHOULD NOT or MUST NOT be used. </ins> <del> Setting the Recommended item to "Y" or "D" or changing a item whose current value is "Y" or "D" requires Standards Action RFC8126.  Not all items defined in Standards Track RFCs need to be marked as Recommended.  Changing the Recommended status of an item in a Standards Track RFC requires Standards Action RFC8126. </del> <ins> Setting a value to "Y" or "D" in the "Recommended" column requires IETF Standards Action RFC8126.  Any state transition to or from a "Y" or "D" value requires IESG Apporval.  Not all items defined in Standards Track RFCs need to be set to "Y" or "D".  Any item not otherwise specified is set to "N".  The column is blank for values that are unassigned or reserved unless specifically set. </ins> <del> 6. </del> <ins> 3.1. </ins> <del> The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name except for entry 35.  To ensure that the values in the registry are consistently identified in the registry, IANA: </del> <ins> Existing registries have a note on the meaning of the recommended column.  For the registries discussed in the subsequent sections this note is updated with a sentence describing the 'D' vaue as follows: </ins> <del> has renamed entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. [SHALL replace] the references to RFC8447 with a reference to this document in the "Reference" column for entry 35. 7. </del> <ins> 4. </ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ExtensionType Values registry as follows: <del> Change the registry policy to: </del> <ins> Change the registration procedure to: </ins> Add a reference to this document under the reference heading. Update the "Recommended" column with the changes as listed below. <del> 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. Update the following note on the recommended column 8. Experience has shown that the IETF Consensus registry policy for TLS Cipher Suites was too strict.  Based on WG consensus, the decision was taken to change the TLS Cipher Suites registry's registration policy to Specification Required while reserving a small part of the code space for Experimental and Private Use RFC8126.  Therefore, IANA has updated the TLS Cipher Suites registry's policy as follows: See expert-pool for additional information about the designated expert pool. The TLS Cipher Suites registry has grown significantly and will continue to do so.  To better guide those not intimately involved in TLS, IANA [SHALL update/has updated] the TLS Cipher Suites registry as follows: Added a "Recommended" column to the TLS Cipher Suites registry. The cipher suites that follow in the two tables are marked as "Y". All other cipher suites are marked 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 transition. The cipher suites that follow are Standards Track server- authenticated (and optionally client-authenticated) cipher suites that are currently available in TLS 1.2. RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. The cipher suites that follow are Standards Track ephemeral pre- shared key cipher suites that are available in TLS 1.2. RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. The TLS 1.3 cipher suites specified by I-D.ietf-tls-rfc8446bis are not listed here; that document provides for their "Recommended" status. Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some implementers blindly implement cipher suites.  Therefore, IANA has added the following warning to the registry: IANA has added the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 I-D.ietf-tls-rfc8446bis uses the same registry but defines ciphers differently: IANA [SHALL add/has added] the following notes to document the rules for populating the "Recommended" column: IANA [SHALL add/has added] the following notes for additional information: IANA [SHALL update/has updated] the reference for this registry to refer to this document instead of RFC8447. 9. Similar to cipher suites, supported groups have proliferated over time, and some use the registry to measure implementations. Therefore, IANA [SHALL add/has added] a "Recommended" column with a "Y" for secp256r1, secp384r1, x25519, and x448, while all others are "N".  These "Y" groups are taken from Standards Track RFCs; RFC8422 elevates secp256r1 and secp384r1 to Standards Track.  Not all groups from RFC8422, which is Standards Track, are marked as "Y"; these groups apply to TLS 1.3 I-D.ietf-tls-rfc8446bis and previous versions of TLS.  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 transition. IANA [SHALL add/has added] the following notes: Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as a checklist against which to measure an implementation's completeness, and some implementers blindly implement supported group.  Therefore, IANA has added the following warning to the registry: </del> <ins> Entries keep their existing "Y" and "N" entries except for the entries in following table.  A reference to this document SHALL be added to these entries. </ins> <del> IANA [SHALL update/has updated] the reference for this registry to refer to this document instead of RFC8447. </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> The value 0 (0x0000) has been marked as reserved. 10. Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifiers is too strict.  Based on WG consensus, the decision was taken to change the registration policy to Specification Required while reserving some of the code space for Standards Track usage and a small part of the code space for Private Use RFC8126.  Therefore, IANA has updated the TLS ClientCertificateType Identifiers registry's policy as follows: See expert-pool for additional information about the designated expert pool. </del> <ins> 5. </ins> <del> IANA [SHALL add/has added] the following notes: </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> 11. </del> <ins> Change the registration procedure to: </ins> <del> To align with TLS implementations and to align the naming nomenclature with other Handshake message types, IANA: </del> <ins> Add a reference to this document under the reference heading. </ins> <del> has renamed entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" RFC5077. </del> <ins> Update the "Recommended" column with the changes as listed below. Entries keep their existing "Y" and "N" entries except for the entries in following table.  A reference to this document SHALL be added to these entries. </ins> <del> [SHALL replace/has replaced] a reference to RFC8447 with a reference to this document in the "Reference" column for entry 4 in the TLS HandshakeType registry. </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> 12. </del> <ins> 6. </ins> <del> To aid those reviewers who start with the IANA registry, IANA [SHALL add/has added]: </del> <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Supported Groups registry as follows: </ins> <del> The following note to the TLS Exporter Labels registry: </del> <ins> Update the registration policy to include: Add a reference to this document under the reference heading. Entries keep their existing Recommended column "Y" and "N" entries. </ins> <del> A "Recommended" column to the TLS Exporter Labels registry.  The table that follows has been generated by marking Standards Track RFCs as "Y" 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, or D->Y|N transitions. </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> To provide additional information for the designated experts, IANA [SHALL add/has added] the following notes: </del> <ins> 7. </ins> <del> IANA [SHALL update/has updated] the reference for this registry to refer to refer to this document instead of RFC8447. </del> <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS Exporter Labels Registry as follows: </ins> <del> 13. </del> <ins> Update the registration procedure to include: </ins> <del> IANA has added the following entry to the TLS Alerts registry; the entry was omitted from the IANA instructions in RFC7301: </del> <ins> Add a reference to this document under the reference heading. </ins> <del> 14. </del> <ins> Entries keep their existing Recommended column "Y" and "N" entries </ins> <del> Experience has shown that the IETF Consensus registry policy for TLS Certificate Types is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required while reserving a small part of the code space for Private Use RFC8126.  Therefore, IANA has changed the TLS Certificate Types registry as follows: </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> Changed the registry policy to: </del> <ins> 8. </ins> <del> Added a "Recommended" column to the registry.  X.509 and Raw Public Key are "Y".  All others are "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> In order to refect the changes in the Recommended column allocation, IANA SHALL update the the TLS Certificate Types registry as follows: </ins> <del> See expert-pool for additional information about the designated expert pool. </del> <ins> Change the registration procedure to: </ins> <del> IANA [SHALL add/has added] the following note: </del> <ins> Add a reference to this document under the reference heading. </ins> <del> IANA [SHALL update/has updated] the reference for this registry to refer this document instead of RFC8447. </del> <ins> Entries keep their existing Recommended column "Y" and "N" entries. </ins> <del> 15. </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> To make it clear that (D)TLS 1.3 has orphaned certain registries (i.e., they are only applicable to version of (D)TLS protocol versions prior to 1.3), IANA: </del> <ins> 9. </ins> <del> has added the following to the TLS Compression Method Identifiers registry RFC3749: </del> <ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS HashAlgorithm Registry registry as follows: Update the registration procedure to include: Add a reference to this document under the reference heading. </ins> <del> has added the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </del> <ins> Update the TLS HashAlgorithm registry to add a "Recommended" column as follows: Add note on the recommended column with text in rec-note. 10. </ins> <del> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to refer to this document instead of RFC8447. </del> <ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS SignatureAlgorithm registry registry as follows: </ins> <del> has updated the TLS HashAlgorithm registry to list values 7 and 9-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-6 and 9-223 as "Reserved". </del> <ins> Update the registration procedure to include: </ins> <del> has added the following to the TLS ClientCertificateType Identifiers registry RFC5246: </del> <ins> Add a reference to this document under the reference heading. Update the TLS SignatureAlgorithm registry to add a "Recommended" column as follows: Add note on the recommended column with text in rec-note. </ins> <del> Despite the fact that the TLS HashAlgorithm and SignatureAlgorithm registries are orphaned, it is still important to warn implementers of pre-TLS1.3 implementations about the dangers of blindly implementing cryptographic algorithms.  Therefore, IANA has added the following warning to the TLS HashAlgorithm and SignatureAlgorithm registries: </del> <ins> 11. </ins> Though TLS 1.0 and TLS 1.1 were deprecated RFC8996, TLS 1.2 will be <del> in use for some time.  IANA [SHALL update/has updated] the TLS HashAlgorithm, TLS SignatureAlgorithm, and TLS ClientCertificateTypes registries to add a "Recommended" column as follows: TLS HashAlgorithm registry: TLS SignatureAlgorithm registry: TLS ClientCertificateTypes registry: In the TLS HashAlgorithm, TLS SignatureAlgorithm, and TLS ClientCertificateTypes registries, all unassigned and reserved values have a "Recommended" that is blank. </del> <ins> in use for some time.  In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS ClientCertificateTypes registry as follows: </ins> <del> 16. </del> <ins> Update the registration procedure to include: </ins> <del> IANA has added the following warning and note to the TLS SignatureScheme registry: </del> <ins> Add a reference to this document under the reference heading. </ins> <del> IANA [SHALL update/has updated] added the following notes to the TLS PskKeyExchangeMode registry: </del> <ins> Update the TLS ClientCertificateTypes registry to add a "Recommended" column as follows: </ins> <del> 17. </del> <ins> Add note on the recommended column with text in rec-note. </ins> <del> Specification Required RFC8126 registry requests are registered after a three-week review period on the tls-reg-review@ietf.org [1] mailing list, on the advice of one or more designated experts.  However, to allow for the allocation of values prior to publication, the designated experts may approve registration once they are satisfied that such a specification will be published. </del> <ins> 12. </ins> <del> Registration requests sent to the mailing list for review SHOULD use an appropriate subject (e.g., "Request to register value in TLS bar registry"). </del> <ins> In order to refect the changes in the Recommended column allocation, IANA SHALL update the TLS PskKeyExchangeMode registry as follows: </ins> <del> Within the review period, the designated experts will either approve or deny the registration request, communicating this decision to the review list and IANA.  Denials SHOULD include an explanation and, if applicable, suggestions as to how to make the request successful. Registration requests that are undetermined for a period longer than 21 days can be brought to the IESG's attention (using the iesg@ietf.org [2] mailing list) for resolution. </del> <ins> Update the registration procedure to include: </ins> <del> Criteria that SHOULD be applied by the designated experts includes determining whether the proposed registration duplicates existing functionality, whether it is likely to be of general applicability or useful only for a single application, and whether the registration description is clear. </del> <ins> Add a reference to this document under the reference heading. </ins> <del> IANA MUST only accept registry updates from the designated experts and SHOULD direct all requests for registration to the review mailing list. </del> <ins> Entries keep their existing recommended column "Y" and "N" entries. </ins> <del> It is suggested that multiple designated experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly informed review of registration decisions.  In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert SHOULD defer to the judgment of the other Experts. </del> <ins> Update note on the recommended column with text in rec-note. </ins> <del> 18. </del> <ins> 13. </ins> The change to Specification Required from IETF Review lowers the amount of review provided by the WG for cipher suites and supported

Discussion:
Updated introduction and recommended column section. Deleted some irrelevant sections.
Changed from obsolete to update.
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.
These are nits.