Original text:
MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS <del> with applicaiton protocols. </del>  This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a 1.2. <del> TLS 1.3 was originally specified in RFC8446.  This document is solely an editorial update.  It contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was neccessary. </del>  1.3. the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the <del> "post_handshake_auth" extension (see post_handshake_auth).  Servers which are authenticating with an external PSK MUST NOT send the </del>  CertificateRequest message either in the main handshake or request <del> post-handshake authentication.  Future specifications MAY provide an extension to permit this. </del>  4.4. closing the connection by sending a "close_notify" is more appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving <del> implementations should continue to read data from the peer until a </del>  "close_notify" is received, though they MAY log or otherwise record them. the values are referred to as "main" secrets.  This mismatch is a result of renaming the values while retaining compatibility. <del> [[OPEN ISSUE: Replace the strings with hex value?]] </del> The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore

Reviewer comments:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker

Revised text:
MUST specify how TLS works with their application protocol, including how and when handshaking occurs, and how to do identity verification. I-D.ietf-uta-rfc6125bis provides useful guidance on integrating TLS  <ins> with application protocols. </ins> This document defines TLS version 1.3.  While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a 1.2.  <ins> TLS 1.3 was originally specified in RFC8446.  This document is a minor update to TLS 1.3 that retains the same version number and is backward compatible.  It tightens some requirements and contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was necessary.  This document makes the following specific technical changes: Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by RFC8996. Removes ambiguity around which hash is used with PreSharedKeys and HelloRetryRequest. Require that clients ignore NewSessionTicket if they do not support resumption. Upgrade the requirement to initiate key update before exceeding key usage limits to MUST. Limit the number of permitted KeyUpdate messages. Restore text defining the level of "close_notify" to "warning". Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored. Add a "general_error" generic alert. In addition, there have been some improvements to the security considerations, especially around privacy. </ins> 1.3. the CertificateRequest message in the main handshake, though they MAY send it in post-handshake authentication (see post-handshake- authentication) provided that the client has sent the  <ins> "post_handshake_auth" extension (see post_handshake_auth).  In the absence of some other specification to the contrary, servers which are authenticating with an external PSK MUST NOT send the </ins> CertificateRequest message either in the main handshake or request  <ins> post-handshake authentication.  RFC8773 provides an extension to permit this, but has not received the level of analysis as this specification. </ins> 4.4. closing the connection by sending a "close_notify" is more appropriate.  This alert MUST be followed by a "close_notify". This alert generally has AlertLevel=warning.  Receiving  <ins> implementations SHOULD continue to read data from the peer until a </ins> "close_notify" is received, though they MAY log or otherwise record them. the values are referred to as "main" secrets.  This mismatch is a result of renaming the values while retaining compatibility.  The general pattern here is that the secrets shown down the left side of the diagram are just raw entropy without context, whereas the secrets down the right side include Handshake Context and therefore