Original text:
The plaintext is the concatenation of TLSPlaintext.fragment, TLSPlaintext.type, and any padding bytes (zeros). <del> The AEAD output consists of the ciphertext output by the AEAD </del>  encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert. <del> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion of greater than 255 bytes.  An endpoint that receives a record from its </del>  peer with TLSCipherText.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert.  This limit is derived from the maximum TLSPlaintext length of 2^14 octets + 1 The sequence number is incremented after reading or writing each record.  The first record transmitted under a particular set of <del> traffic keys record key MUST use sequence number 0. </del>  Sequence numbers do not wrap.  If a TLS implementation would need to wrap a sequence number, it MUST either rekey (key-update) or TLSInnerPlaintext.content. The padding sent is automatically verified by the record protection <del> mechanism: Upon successful decryption of a TLSCiphertext.fragment, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </del>  Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not

Reviewer comments:
I forsee some merge conflicts in the future, as there's already and I have plans to rototill this section a bit more than you do here.
This won't conflict with . Git is good at detecting identical changes.

Revised text:
The plaintext is the concatenation of TLSPlaintext.fragment, TLSPlaintext.type, and any padding bytes (zeros).  <ins> The AEAD output consists of the ciphertext output from the AEAD </ins> encryption operation.  The length of the plaintext is greater than TLSPlaintext.length due to the inclusion of TLSPlaintext.type and any padding supplied by the sender.  The length of the AEAD output will If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.  <ins> An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion greater than 255 octets.  An endpoint that receives a record from its </ins> peer with TLSCipherText.length larger than 2^14 + 256 octets MUST terminate the connection with a "record_overflow" alert.  This limit is derived from the maximum TLSPlaintext length of 2^14 octets + 1 The sequence number is incremented after reading or writing each record.  The first record transmitted under a particular set of  <ins> traffic keys MUST use sequence number 0. </ins> Sequence numbers do not wrap.  If a TLS implementation would need to wrap a sequence number, it MUST either rekey (key-update) or TLSInnerPlaintext.content. The padding sent is automatically verified by the record protection  <ins> mechanism: upon successful decryption of a TLSCiphertext.encrypted_record, the receiving implementation scans the field from the end toward the beginning until it finds a non-zero octet.  This non-zero octet is the content type of the message.  This padding scheme was selected because it allows padding of any encrypted TLS record by an arbitrary size (from zero up to TLS record size limits) without introducing new content types.  The design also enforces all-zero padding octets, which allows for quick detection of padding errors. </ins> Implementations MUST limit their scanning to the cleartext returned from the AEAD decryption.  If a receiving implementation does not