Original text:
This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the value of the Recommended column.  A Standards Track document <del> RFC8126 is required to register an extension with the value "Yes". </del>  9. cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards <del> Track document RFC8126 is required to register a cipher suite with the value "Yes". </del>  The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites 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 <del> required to register an entry with the value "Yes". </del>  IANA [SHALL add/has added] the following note: 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 <del> RFC8126 is required to register an extension with the value "Yes". </del>  To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: "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 <del> Track document RFC8126 is required to register an entry with the value "Yes". </del>  See expert-pool for additional information about the designated expert pool.

Reviewer comments:
Addresses .
Our esteemed Shepherd has pointed out that we need to specify the rules for going from Yes->No. After consulting the list, we settled on "IESG action is REQUIRED for a Yes->No transition."
Closed as part of .

Revised text:
This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the value of the Recommended column.  A Standards Track document  <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> 9. cipher suites that follow in the two tables are marked as "Yes". All other cipher suites are marked as "No".  Future cipher suites MUST define the value of the Recommended column.  A Standards  <ins> Track document RFC8126 is REQUIRED to register a cipher suite with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites 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".  IESG action is REQUIRED for a Yes->No transition. </ins> IANA [SHALL add/has added] the following note: 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  <ins> RFC8126 is REQUIRED to register an extension with the value "Yes". IESG action is REQUIRED for a Yes->No transition. </ins> To provide additional information for the designated experts, IANA [SHALL add/has added] the following note: "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  <ins> Track document RFC8126 is REQUIRED to register an entry with the value "Yes".  IESG action is REQUIRED for a Yes->No transition. </ins> See expert-pool for additional information about the designated expert pool.