Change:
AES CCM cipher suite names; those names are used here without modification. <del> Add the following: </del> <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher suites.  Therefore, IANA [SHALL add/has added] the following warning to the registry: </ins> <del> WARNING: Cryptographic algorithms will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </del> <ins> Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not </ins> advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. <del> Note(1): Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suites cannot be used with TLS 1.3. </del> <ins> IANA [SHALL add/has added] the following note to ensure that those that focus on IANA registries are aware that TLS 1.3 I-D.ietf-tls- tls13 uses the same registry but defines ciphers differently: Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers, and cannot be used for TLS 1.2.  Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3. </ins> <del> Note(2): Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. </del> <ins> IANA [SHALL add/has added] the following notes to document the rules for populating the Recommended column: </ins> <del> Note(3): The designated expert RFC5226 only ensures that the specification is publicly available. </del> <ins> Cipher suites marked as "Yes" are those allocated via Standards Track RFCs.  Cipher suites marked as "No" are not; cipher suites marked "No" range from "good" to "bad" from a cryptographic standpoint. The designated expert RFC8126 only ensures that the specification is publicly available. IANA [SHALL uppdate/has updated] the reference for this registry to also refer to this document. </ins> 8. <del> Add a "Recommended" column with a "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls- rfc4492bis, which is standards track, are not marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS I-D.ietf-tls-tls13.  A Standards Track document RFC5226 is </del> <ins> 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 "Yes" for secp256r1, secp384r1, x25519, and x448 while all others are "No".  These "Yes" groups are taken from Standards Track RFCs.  Not all groups from I-D.ietf-tls-rfc4492bis, which is standards track, are marked as "Yes"; these groups apply to TLS 1.3 I-D.ietf-tls-tls13 and previous versions of TLS.  Future supported groups MUST define the value of this column.  A Standards Track document RFC8126 is </ins> required to register an entry with the value "Yes". <ins> IANA [SHALL add/has added] the following note: Supported Groups marked as "Yes" are those allocated via Standards Track RFCs.  Supported Groups marked as "No" are not; supported groups marked "No" range from "good" to "bad" from a cryptographic standpoint. Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implemention's completeness and some implementers blindly implement cipher supported.  Therefore, IANA [SHALL add/has added] the following warning to the registry: Cryptographic algorithms and parameters will be broken or weakened over time.  Blindly implementing cipher suites listed here is not advised.  Implementers and users need to check that the cryptographic algorithms listed continue to provide the expected level of security. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> The value 0 (0x0000) is to be marked as reserved. 9. <del> IANA is to update the TLS ClientCertificateType Identifiers registry as follows: Change the registry policy to: </del> <ins> Experience has shown that the IETF Consensus registry policy for TLS ClientCertificateType Identifers is too strict.  Based on WG consensus, the decision was taken to change registration policy to Specification Required RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL update/has updated] the TLS Cipher Suite registry's policy as follows: </ins> <del> Values in the range 0-223 are assigned via Specification Required RFC5226.  Values 224-255 are reserved for Private Use. </del> <ins> See expert-pool for additional information about the designated expert pool. </ins> <del> Add the following: </del> <ins> IANA [SHALL add/has added] the following notes: </ins> <del> The designated expert RFC5226 only ensures that the specification </del> <ins> The designated expert RFC8126 only ensures that the specification </ins> is publicly available. <ins> ClientCertificateType Identifers marked as "Yes" are those allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not. </ins> 10. To align with TLS implementations and to align the naming <del> nomenclature for other Handshake message types, IANA is to rename entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)".  IANA is to also add a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </del> <ins> nomenclature with other Handshake message types, IANA: [SHALL rename/has renamed] entry 4 in the TLS HandshakeType registry to "new_session_ticket (renamed from NewSessionTicket)" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 4 in the TLS HandshakeType registry. </ins> 11. <del> IANA is to add the following note to the TLS Exporter Label Registry: </del> <ins> To aid those reviewers who start with the IANA registry, IANA [SHALL add/has added]: The following note to the TLS Exporter Label Registry: </ins> RFC5705 defines keying material exporters for TLS in terms of the TLS PRF.  I-D.ietf-tls-tls13 replaced the PRF with HKDF, thus requiring a new construction.  The exporter interface remains the same, however the value is computed different. <del> IANA is to also to add a "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del> <ins> A "Recommended" column to the TLS Exporter Label registry.  The table that follows has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future exporters MUST define the value of this column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins> <del> IANA is also to add the following note: </del> <ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: </ins> <del> The designated expert RFC5226 ensures that the specification is </del> <ins> The designated expert RFC8126 ensures that the specification is </ins> publicly available.  The expert also verifies that the label is a string consisting of printable ASCII characters beginning with "EXPORTER".  IANA MUST also verify that one label is not a prefix of any other label.  For example, labels "key" or "master secretary" are forbidden. <ins> Exporters Labels marked as "Yes" are those allocated via Standards Track RFCs.  Exporter Labels marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer to this document. </ins> 12. <del> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): </del> <ins> IANA [SHALL add/has added] the following entry to the TLS Alert Registry; the entry was omitted from the IANA instructions in RFC7301): </ins> 13. <del> Add a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC5226 is required to register a certificate type with the value "Yes". </del> <ins> 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 RFC8126 while reserving a small part of the code space for experimental and prviate use.  Therefore, IANA [SHALL add/has added] a "Recommended" column to the registry.  X.509 and Raw Public Key are "Yes".  All others are "No".  A Standards Track document RFC8126 is required to register a certificate type with the value "Yes".  Future Certificate Types MUST define the value of this column.  A Standards Track document RFC8126 is required to register an entry with the value "Yes". See expert-pool for additional information about the designated expert pool. IANA [SHALL add/has added] the following note: Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not. IANA [SHALL update/has updated] the reference for this registry to also refer this document. </ins> 14. To make it clear that (D)TLS 1.3 has orphaned certain extensions <del> (i.e., they are only applicable to version of (D)TLS prior to 1.3), IANA is to add the following to the TLS ExtensionType Values registry: </del> <ins> (i.e., some extensions are only applicable to version of (D)TLS prior to 1.3), IANA [SHALL add/has added] the following note to the TLS ExtensionType Values registry: </ins> The following extensions are only applicable to (D)TLS protocol vesions prior to 1.3: trusted_ca_keys, truncated_hmac, ec_point_formats, srp, status_request_v2, encrypt_then_mac, extended_master_secret, session_ticket, and renegotiation_info. <del> These are not applicable to DTLS 1.3. </del> <ins> These extensions are not applicable to (D)TLS 1.3. </ins> 15. 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 <del> versions prior to 1.3), IANA is to: </del> <ins> versions prior to 1.3), IANA: </ins> <del> Add the following to the TLS Compression Method Identifiers registry RFC3749: </del> <ins> [SHALL add/has added] the following to the TLS Compression Method Identifiers registry RFC3749: </ins> Value 0 (NULL) is the only value in this registry applicable to (D)TLS protocol version 1.3 or later. <del> Add the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </del> <ins> [SHALL add/has added] the following to the TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries RFC5246: </ins> The values in this registry are only applicable to (D)TLS protocol versions prior to 1.3. <del> Update the "References" in the TLS Compression Method Identifiers, TLS HashAlgorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. </del> <ins> [SHALL update/has updated] the "Reference" field in the TLS Compression Method Identifiers, TLS HashAlgorithm and TLS SignatureAlgorithm registries to also refer to this document. </ins> <del> IANA [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </del> <ins> [SHALL update/has updated] the TLS HashAlgorithm Registry to list values 7-223 as "Reserved" and the TLS SignatureAlgorithm registry to list values 4-223 as "Reserved". </ins> 16. <del> Specification Required RFC5226 registry requests are registered after </del> <ins> Specification Required RFC8126 registry requests are registered after </ins> a three-week review period on the (tbd but maybe tls-reg- review@ietf.org) mailing list, on the advice of one or more Designated Experts.  However, to allow for the allocation of values

Discussion:
A pretty major rewrite to incorporate the rationale for changes into individual sections as opposed to having it at the beginning. Also fixing some formatting.