Change:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.

Discussion:
no_application_protocol alert defined in RFC7301. Added "Recommended" column to TLS ExtensionType Values, TLS Cipher <del> Suite, and TLS Exporters Label registries.  Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </del> <ins> Suite, TLS Supported Groups, and TLS Exporters Label registries. Initial values marked "Yes" are specified in IETF Standards Track documents; all others are marked "No".  This new column is intended to alter the incorrect perception that getting a code point somehow legitimizes the extension, cipher suite/algorithm, or exporter. </ins> Establish Designated Expert pool rules for Specification Required registries.

IETF Review for the last), are appropriate for these one-byte code points because of their scarcity. <del> This document proposes no changes to the EC Curve Type, EC Point Format, and Supported Groups Registries (see I-D.ietf-tls- rfc4492bis). </del> 3. IANA is to update the names of the following registries to add "TLS"

7. <ins> 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 required to register an entry with the value "Yes". 8. </ins> IANA is to update the TLS ClientCertificateType Identifiers registry as follows:

Note: The designated expert RFC5226 only ensures that the specification is publicly available. <del> 8. </del> <ins> 9. </ins> To align with TLS implementations and to align the naming nomenclature for other Handshake message types, IANA is to rename

this document in the Reference column for entry 4 in the TLS HandshakeType registry. <del> 9. </del> <ins> 10. </ins> The nomenclature for the registry entries in the TLS ExtensionType Values registry correspond to the presentation language field name

consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". <del> 10. </del> <ins> 11. </ins> IANA is to add the following note to the TLS Exporter Label Registry:

IANA is also to add the following note: <del> 11. </del> <ins> 12. </ins> IANA is to add the following entry to the TLS Alert Registry (the entry was omitted from the IANA instructions in RFC7301): <del> 12. </del> <ins> 13. </ins> To make it clear that (D)TLS 1.3 has orphaned certain extensions (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> 13. </del> <ins> 14. </ins> 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

TLS Hash Algorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <del> 14. </del> <ins> 15. </ins> Specification Required RFC5226 registry requests are registered after a three-week review period on the (tbd but maybe tls-reg-

Expert, that Expert SHOULD defer to the judgment of the other Experts. <del> 15. </del> <ins> 16. </ins> The authors are fairly certain that there are no security considerations for this document. <del> 16. </del> <ins> 17. </ins> This document is entirely about changes to TLS-related IANA registries.