Change:
NAME let me know what you think.
I.e., if you actually deploy on the Internet with these experimental code points, and you run into someone using the same code point, you're going to have a bad day. For widespread experiments, we should really be using temporary reservations of some kind instead.
NAME NAME How about we add the following note everywhere we added private use: NOTE: : As specified in {{RFC5226}}, assignments made in the Private Use space "are not generally useful for broad interoperability." It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available.
LGTM.
Addressed by .

Discussion:
6. <del> The instructions in this document add a recommended column to many of </del> <ins> The instructions in this document add a Recommended column to many of </ins> the TLS registries to indicate parameters that are generally recommended for implementations to support.  Adding a recommended parameter to a registry or updating a parameter to recommended status

Update the "Reference" to also refer to this document. <del> Add the following note: </del> <ins> Add the following notes: </ins> Experts are to verify that there is in fact a publicly available standard. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> See expert-pool for additional information about the designated expert pool.

RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. <ins> The following is from I-D.ietf-tls-tls13 and is included here to ensure aligment between these specifications. I-D.ietf-tls-tls13 also uses the TLS ExtensionType Registry originally created in RFC4366.  IANA has updated it to reference this document.  The registry and its allocation policy is listed below: 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_certs", extensions with the values defined in this document and the Recommended value of "Yes". IANA [SHALL update/has updated] this registry to include a "TLS 1.3" column which 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-tls13 with any extension not listed there marked as "-" to indicate that it is not used by TLS 1.3. </ins> 9. Experience has shown that the IETF Consensus registry policy for TLS

RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. <del> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers </del> <ins> Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers </ins> blindly implement cipher suites.  Therefore, IANA [SHALL add/has added] the following warning to the registry:

marked "No" range from "good" to "bad" from a cryptographic standpoint. <del> CCM_8 cipher suites are not marked as Recommended.  These cipher </del> <ins> CCM_8 cipher suites are not marked as recommended.  These cipher </ins> suites have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environments. <ins> IANA [SHALL add/has added] the following notes for additional information: </ins> The designated expert RFC8126 only ensures that the specification is publicly available. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> IANA [SHALL update/has updated] the reference for this registry to also refer to this document.

The designated expert RFC8126 only ensures that the specification is publicly available. <del> Despite the following behavior being crazy, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers blindly implement cipher supported.  Therefore, IANA [SHALL add/has </del> <ins> Despite the following behavior being misguided, experience has shown that some customers use the IANA registry as checklist against which to measure an implementation's completeness and some implementers blindly implement groups supported.  Therefore, IANA [SHALL add/has </ins> added] the following warning to the registry: Cryptographic algorithms and parameters will be broken or weakened

The designated expert RFC8126 only ensures that the specification is publicly available. <ins> As specified in RFC8126, assignments made in the Private Use space are not generally useful for broad interoperability.  It is the responsibility of those making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use). For widespread experiments, temporary reservations are available. </ins> ClientCertificateType Identifiers marked as "Yes" are those allocated via Standards Track RFCs.  ClientCertificateTypes marked as "No" are not.