Original text:
privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher). <del> This document defines how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS.  This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. </del>  In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response <del> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3 or higher, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </del>  2.1.1. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with <del> TLS version 1.3 or higher, EAP-TLS SHALL use a resumption mechanism compatible 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 compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in <del> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3 or higher. The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </del>  exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server and encrypting large parts of the TLS handshake including the certificate messages. <del> EAP-TLS peer and server implementations supporting TLS 1.3 or higher MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </del>  xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of RFC7542. As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). <del> When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </del>  EAP-TLS with TLS 1.3 is always used with privacy.  This does not add any extra round-trips and the message flow with privacy is just the correct when EAP-TLS is used with TLS version 1.3 or higher.  For TLS 1.3 the key schedule is described in Section 7.1 of RFC8446. <del> When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in </del>  Section 7.5 of RFC8446). Other TLS based EAP methods can use exporters in a similar fashion by

Reviewer comments:
Explain that the next version of TLS may not be compatible with this document. Remove "or higher" in several sections. This addresses issue
NAME does this commit address Issue ?
As an implementor, I'm not sure what it means to "automatically support" or "not automatically support" something. It's not clear to me what I do with that recommendation. I think it's best to make an explicit statement that That statement gives clear direction on exactly what to do. i.e. there are APIs to "limit the maximum TLS version". So I know what that phrase means. There are no APIs to "not automatically support" something. So I don't know what that phrase means, or what I should do in order to satisfy its' requirements. The rest of the changes are fine.
Thanks, I updated the text.
From Alan's review: Suggestion: remove all "or higher" text. Add in text which says that by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS version to 1.3, unless later versions are explicitly enabled by the administrator.
It would help implementors to understand why this restriction is there. i.e. instead of just saying "use TLS 1.3", it would be good to note something like:

Revised text:
privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).  <ins> This document defines how to use EAP-TLS with TLS 1.3 and does not change how EAP-TLS is used with older versions of TLS.  It does however provide additional guidance on authorization and resumption for EAP-TLS in general (regardless of the underlying TLS version used).  While this document updates EAP-TLS RFC5216, it remains backwards compatible with it and existing implementations of EAP-TLS. This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully imtegrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in RFC5216 the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response  <ins> and EAP-Request packets.  When EAP-TLS is used with TLS version 1.3, the formatting and processing of the TLS handshake SHALL be done as specified in that version of TLS.  This document only lists additional and different requirements, restrictions, and processing compared to RFC8446 and RFC5216. </ins> 2.1.1. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange.  When EAP-TLS is used with  <ins> TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible with that version of TLS. </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 compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3 or higher. The two paragraphs below replaces the corresponding paragraphs in  <ins> Section 2.1.3 of RFC5216 when EAP-TLS is used with TLS 1.3.  The other paragraphs in Section 2.1.3 of RFC5216 still apply with the </ins> exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server and encrypting large parts of the TLS handshake including the certificate messages.  <ins> EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4 in RFC7542) and a client supporting TLS 1.3 MUST NOT send its username in cleartext in the Identity Response.  Following RFC7542, it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g. anonymous@realm) or an encrypted username (e.g., </ins> xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of RFC7542. As the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS).  <ins> When EAP-TLS is used with TLS version 1.3 the EAP-TLS peer and EAP- TLS server SHALL follow the processing specified by the used version of TLS.  For TLS 1.3 this means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition. </ins> EAP-TLS with TLS 1.3 is always used with privacy.  This does not add any extra round-trips and the message flow with privacy is just the correct when EAP-TLS is used with TLS version 1.3 or higher.  For TLS 1.3 the key schedule is described in Section 7.1 of RFC8446.  <ins> When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in </ins> Section 7.5 of RFC8446). Other TLS based EAP methods can use exporters in a similar fashion by