Change:
with "IETF Consensus" are undergoing other changes either as a result of this document or I-D.ietf-tls-rfc4492bis. <ins> IANA [SHALL update/has updated] the reference for these two registries to also refer to this document. </ins> 5. 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 <del> consistently identified in the registry, IANA is to rename entry 35 to "session_ticket (renamed from "SessionTicket TLS")". </del> <ins> consistently identified in the registry, IANA: [SHALL rename/has renamed] entry 35 to "session_ticket (renamed from "SessionTicket TLS")" RFC5077. [SHALL add/has added] a reference to this document in the Reference column for entry 35. </ins> 6. <del> IANA is to update the TLS ExtensionType Values registry as follows: </del> <ins> Experience has shown that the IETF Review registry policy for TLS Extensions was too strict.  Based on WG consensus, the decision was taken to change the 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 ExtensionType Values registry to: </ins> Change the registry policy to: Values with the first byte in the range 0-254 (decimal) are <del> assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC5226. </del> <ins> assigned via Specification Required RFC8126.  Values with the first byte 255 (decimal) are reserved for Private Use RFC8126. </ins> <del> Update the "References" to also refer to this document. </del> <ins> Update the "Reference" to also refer to this document. </ins> Add the following note: <del> Note: Experts are to verify that there is in fact a publicly available standard. </del> <ins> Experts are to verify that there is in fact a publicly available standard. See expert-pool for additional information about the designated expert pool. Despite wanting to "loosen" the registration policies for TLS Extensions, it is still useful to indicate in the IANA registry which extensions the WG recommends be supported.  Therefore, IANA [SHALL update/has updated] the TLS ExtensionType Values registry to: </ins> Add a "Recommended" column with the contents as listed below. This table has been generated by marking Standards Track RFCs as "Yes" and all others as "No".  Future extensions MUST define the <del> value of this column.  A Standards Track document RFC5226 is required to register an extension with the value "Yes". </del> <ins> value of the Recommended column.  A Standards Track document RFC8126 is required to register an extension with the value "Yes". </ins> 7. <del> IANA is to update the TLS Cipher Suite registry as follows: </del> <ins> 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 Suite registry's 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> Change the registry policy to: </del> <ins> See expert-pool for additional information about the designated expert pool. </ins> <del> Values with the first byte in the range 0-254 (decimal) are assigned via Specification Required RFC5226.  Values with the first byte 255 (decimal) are reserved for Private Use RFC2434. </del> <ins> The cipher suite 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 Suite registry as follows: </ins> <del> Add a "Recommended" column to the cipher suite registry.  The </del> <ins> Add a "Recommended" column to the TLS Cipher Suite registry.  The </ins> 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 RFC5226 is required to register a cipher suite with </del> <ins> Track document RFC8126 is required to register a cipher suite with </ins> the value "Yes". <del> Update the reference for this registry to also point to this document. </del> <ins> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2. </ins> <del> The cipher suites that follow are standards track server- authenticated (and optionally client-authenticated) cipher suites which are currently available in TLS 1.2.  The notable exception are the ECDHE AES GCM cipher suites which are not yet standards track prior to the publication of this specification, but this document promotes those 4 cipher suites to standards track (see TO-DO insert reference). RFC EDITOR: Please delete the sentence beginning with "The notable exception ..." after RFC 5289 has been promoted to Proposed Standard. </del> <ins> RFC EDITOR: The previous paragraph is for document reviewers and is not meant for the registry. </ins> The cipher suites that follow are standards track ephemeral pre- shared key cipher suites which are available in TLS 1.2.  RFC6655 is

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.