Original text:
mechanism defined in RFC5077 and replaces it with the mechanism defined in resumption-and-psk. negotiated-groups updates RFC4492 by modifying the protocol attributes used to negotiate Elliptic Curves. <del> Because TLS 1.3 changes the way keys are derived it updates RFC5705 as described in exporters it also changes how OCSP messages are </del>  carried and therefore updates RFC6066 and obsoletes RFC6961 as described in section ocsp-and-sct. be more consistent and to remove superfluous messages such as ChangeCipherSpec. <del> Elliptic curve algorithms are now in the base spec and includes new signature algorithms, such as ed25519 and ed448.  TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </del>  Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use concatenated as described in basic-block-size and are also unsigned. The following numeric types are predefined. <del> All values, here and elsewhere in the specification, are stored in network byte (big-endian) order; the uint32 represented by the hex </del>  bytes 01 02 03 04 is equivalent to the decimal value 16909060. 3.5. extension.  Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of <del> TLS SHOULD support TLS 1.2.  Servers should be prepared to receive </del>  ClientHellos that include this extension but do not include 0x0304 in the list of versions. carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's <del> parameters present, then the parameters in the signature MUST be identical to those in the public key. </del>  Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used 4.2.6. The "post_handshake_auth" extension is used to indicate that a client <del> is willing to perform post-handshake authentication post-handshake- authentication.  Servers MUST NOT send a post-handshake </del>  CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the <del> "ticket_age_add" value that was included with the ticket, see NSTMessage modulo 2^32.  This addition prevents passive observers </del>  from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because (ClientHello.random).  The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random. <del> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client CertificateVerify".  It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </del>  For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to a byte string by <del> encoding in big-endian and padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </del>  schedule as specified above. Note that this construction differs from previous versions of TLS

Reviewer comments:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.

Revised text:
mechanism defined in RFC5077 and replaces it with the mechanism defined in resumption-and-psk. negotiated-groups updates RFC4492 by modifying the protocol attributes used to negotiate Elliptic Curves.  <ins> Because TLS 1.3 changes the way keys are derived, it updates RFC5705 as described in exporters.  It also changes how OCSP messages are </ins> carried and therefore updates RFC6066 and obsoletes RFC6961 as described in section ocsp-and-sct. be more consistent and to remove superfluous messages such as ChangeCipherSpec.  <ins> Elliptic curve algorithms are now in the base spec and new signature algorithms, such as ed25519 and ed448, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </ins> Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use concatenated as described in basic-block-size and are also unsigned. The following numeric types are predefined.  <ins> All values, here and elsewhere in the specification, are transmitted in network byte (big-endian) order; the uint32 represented by the hex </ins> bytes 01 02 03 04 is equivalent to the decimal value 16909060. 3.5. extension.  Note that this mechanism makes it possible to negotiate a version prior to TLS 1.2 if one side supports a sparse range. Implementations of TLS 1.3 which choose to support prior versions of  <ins> TLS SHOULD support TLS 1.2.  Servers MUST be prepared to receive </ins> ClientHellos that include this extension but do not include 0x0304 in the list of versions. carried in an X.509 certificate, it MUST use the RSASSA-PSS OID RFC5756.  When used in certificate signatures, the algorithm parameters MUST be DER encoded.  If the corresponding public key's  <ins> parameters are present, then the parameters in the signature MUST be identical to those in the public key. </ins> Indicates algorithms which are being deprecated because they use algorithms with known weaknesses, specifically SHA-1 which is used 4.2.6. The "post_handshake_auth" extension is used to indicate that a client  <ins> is willing to perform post-handshake authentication (post-handshake- authentication).  Servers MUST NOT send a post-handshake </ins> CertificateRequest to clients which do not offer this extension. Servers MUST NOT send this extension. which was provided with the ticket.  The "obfuscated_ticket_age" field of each PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the  <ins> "ticket_age_add" value that was included with the ticket (see NSTMessage), modulo 2^32.  This addition prevents passive observers </ins> from correlating connections unless tickets are reused.  Note that the "ticket_lifetime" field in the NewSessionTicket message is in seconds but the "obfuscated_ticket_age" is in milliseconds.  Because (ClientHello.random).  The initial 64-byte pad clears that prefix along with the server-controlled ServerHello.random.  <ins> The context string for a server signature is: "TLS 1.3, server CertificateVerify" The context string for a client signature is: "TLS 1.3, client CertificateVerify" It is used to provide separation between signatures made in different contexts, helping against potential cross-protocol attacks. </ins> For example, if the transcript hash was 32 bytes of 01 (this length would make sense for SHA-256), the content covered by the digital For finite field groups, a conventional Diffie-Hellman computation is performed.  The negotiated key (Z) is converted to a byte string by  <ins> encoding in big-endian and left padded with zeros up to the size of the prime.  This byte string is used as the shared secret in the key </ins> schedule as specified above. Note that this construction differs from previous versions of TLS