Original text:
This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS <del> server MUST send one or more NewSessionTicket messages (each containing a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </del>  tickets.  The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. <del> The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NesSessionTicket MUST NOT be sent before the client's certificate has been validated.  The NewSessionTicket message MUST NOT include an </del>  "early_data" extension.  If the "early_data" extension is received then it MUST be ignored.  Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible <del> with that version of TLS. </del>  For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS <del> server, the client can use the PSK identity received in the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </del>  handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer whether to offer resumption, ut it is RECOMMENDED that the EAP-TLS peer offer

Reviewer comments:
During dicsussion on close_notify, there was a good dicusssion on the list on why resumption is needed. Some short clarifications on how TLS 1.3 works. E.g. that PSK is not included in the ticket.

Revised text:
This is a new section when compared to RFC5216. To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS  <ins> server MUST send one or more Post-Handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication.  Note that TLS 1.3 RFC8446 limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing </ins> tickets.  The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication.  <ins> The NewSessionTicket can be sent in the same flight as the TLS server Finished or later.  The PSK associated with the ticket depends on the client Finished and cannot be pre-computed in handshakes with client authentication.  The NewSessionTicket message MUST NOT include an </ins> "early_data" extension.  If the "early_data" extension is received then it MUST be ignored.  Servers should take into account that fewer newSessionTickets will likely be needed in EAP-TLS than in the usual TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible  <ins> with that version of TLS.  EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a large number of EAP requests and EAP responses.  Resumption significantly reduces the number of round-trips and enables the EAP-TLS server to omit database lookups needed during a full handshake with client authentication. </ins> For TLS 1.3, resumption is described in Section 2.2 of RFC8446.  If the client has received a NewSessionTicket message from the EAP-TLS  <ins> server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK.  If the EAP-TLS server accepts it, then the security context of the new connection is tied to the original connection and the key derived from the initial </ins> handshake is used to bootstrap the cryptographic state instead of a full handshake.  It is up to the EAP-TLS peer whether to offer resumption, ut it is RECOMMENDED that the EAP-TLS peer offer