Original text:
(*) indicates changes to the wire protocol which may require implementations to update.  draft-24 Require that CH2 have version 0303 (*) The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns <del> where other values might be received.  Implementations MAY verify that the legacy_record_version field is 0x0303 and abort the connection if it is not.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </del>  The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or <del> server_write_iv, and the additional data input is empty (zero length).  Derivation of traffic keys is defined in traffic-key- calculation. </del>  The plaintext input to the AEAD algorithm is the encoded <del> TLSInnerPlaintext structure. </del>  The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically,  In order to decrypt and verify, the cipher takes as input the key, <del> nonce, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </del>  If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.

Reviewer comments:
Previous PR plus some cleanup.
Looks good to me, for what it's worth :)
ekr: please merge this so we can get a new version out for the IESG.
NAME can you be more precise about the appendix D text? is the issue that we say "ignored" but then use it as additional_data?
NAME : PTAL

Revised text:
(*) indicates changes to the wire protocol which may require implementations to update. <ins> draft-25 - Add the header to additional data (*) Minor clarifications. IANA cleanup. </ins> draft-24 Require that CH2 have version 0303 (*) The legacy_record_version field is always 0x0303.  TLS 1.3 TLSCiphertexts are not generated until after TLS 1.3 has been negotiated, so there are no historical compatibility concerns  <ins> where other values might be received.  Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. </ins> The length (in bytes) of the following TLSCiphertext.encrypted_record, which is the sum of the lengths of described in Section 2.1 of RFC5116.  The key is either the client_write_key or the server_write_key, the nonce is derived from the sequence number (see nonce) and the client_write_iv or  <ins> server_write_iv, and the additional data input is the record header. I.e., </ins> The plaintext input to the AEAD algorithm is the encoded  <ins> TLSInnerPlaintext structure.  Derivation of traffic keys is defined in traffic-key-calculation. </ins> The AEAD output consists of the ciphertext output from the AEAD encryption operation.  The length of the plaintext is greater than Since the ciphers might incorporate padding, the amount of overhead could vary with different lengths of plaintext.  Symbolically, <ins> Then the encrypted_record field of TLSCiphertext is set to AEADEncrypted. </ins> In order to decrypt and verify, the cipher takes as input the key,  <ins> nonce, additional data, and the AEADEncrypted value.  The output is either the plaintext or an error indicating that the decryption failed.  There is no separate integrity check.  That is: </ins> If the decryption fails, the receiver MUST terminate the connection with a "bad_record_mac" alert.