Original text:
figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest <del> nor Post-Handshake messages are sent). </del>  2.1.2. 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 Post-Handshake NewSessionTicket messages </del>  (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 TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3.  The two <del> paragraphs below replaces the corresponding paragraphs in </del>  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 exception that SessionID is deprecated. This is a new section when compared to RFC5216 and only applies to TLS 1.3.  RFC4137 offers a proposed state machine for EAP. <del> TLS 1.3 RFC8446 introduces Post-Handshake messages.  These Post- Handshake messages use the handshake content type and can be sent after the main handshake.  Examples of Post-Handshake messages are </del>  NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS <del> Finished, the EAP-TLS server may send any number of Post-Handshake </del>  messages in separate EAP-Requests. To provide a protected success result indication and to decrease the followed: When an EAP-TLS server has successfully processed the TLS client <del> Finished and sent its last handshake message (Finished or a Post- Handshake), it sends an encrypted TLS record with application data 0x00.  The encrypted TLS record with application data 0x00 is a </del>  protected success result indication, as defined in RFC3748.  After <del> sending a EAP-Request that contains the protected success result </del>  indication, the EAP-TLS server must not send any more EAP-Request and may only send an EAP-Success.  The EAP-TLS server MUST NOT send an encrypted TLS record with application data 0x00 alert before it has layer.  To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full <del> handshake.  This document use the term "cached data" to describe such information.  Authorization during resumption MUST be based on such cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data.  Any security </del>  policies for authorization MUST be followed also for resumption.  The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have reduced.  If the

Reviewer comments:
Hi! I performed a second AD review on draft-ietf-emu-eap-tls13. This time on -18. Thank you to the authors, the responsible co-chair, and the WG for all of the work to redesign the -13 protocol in response to the initial IESG review in December 2020. My review feedback consists of my own minimal additional comments and highlights of where previously stated IESG ballot items do not appear to be responded to or addressed. All items appear to be minor. ** Section 2.4. Previously, this text referenced TLS 1.3 or higher necessitating more ambiguous reference to version numbers. However, now the text only notes TLS 1.3. OLD When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) for the TLS version used. For TLS 1.3 the compliance requirements are defined in Section 9 of [RFC8446]. NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. ==[ COMMENT (Ben Kaduk) Section 2.1.4 The two paragraphs below replaces the corresponding paragraphs in 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 exception that SessionID is deprecated. If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with the EAP-TLS server sending an EAP-Success message. If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. Just to walk through the various scenarios here; if the last message of the TLS handshake for a given TLS version is sent by the TLS client, that will go in an EAP-Response, so the server is then able to send EAP-Success directly. On the other hand, if the last TLS handshake message is sent by the server, that will have to go in an EAP-TLS EAP-Request, and so the peer will have to send an empty EAP-TLS response in order for the server to be able to wend EAP-Success? Do we need to have any text here to handle that empty EAP-TLS Eap-Request case? ==[ COMMENT(Alvaro Retana) Is the intention of the Appendix to provide additional formal updates to rfc5216? That is what it looks like to me, but there's no reference to it from the main text. Please either reference the Appendix when talking about some of the other updates (if appropriate) or specifically include the text somewhere more prominent. [Roman] As proposed above, please provide some forward reference. ==[ COMMENT (Éric Vyncke) I find "This section updates Section 2.1.1 of [RFC5216]." a little ambiguous as it the 'updated section' is not identified clearly. I.e., as the sections in RFC 5216 are not too long, why not simply providing whole new sections ? [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216) ==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Regards, Roman
==[ COMMENT (Éric Vyncke) None of us are native English speaker, but "e.g." as "i.e." are usually followed by a comma while "but" has usually no comma before ;-) [Roman] A simple s/e.g./e.g.,/ and s/i.e./i.e.,/ would catch this. Eric is correct that US english i.e. and e.g. is usually followed by a comma. I corrected this in d9f5028 I also run a word spell check on the document. Word does not suggest removing any comma after "but" but rather insert an additional comma after a but. I think this can be left to the RFC editor. The word spell check caught two other grammar errors (s after plural, no s after singular) RFC 8446 does not use capitalization on post-handshake as that is just a name for a set of messages. I corrected these things in
I Made a new PR
Made a commit with NEW When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446].
Section 2.1.4 Changed the text to: The message flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server.
I added a forward reference to the appendix in the introduction
NAME looks like you have got everything covered? are there any comments from Roman which still need to be addressed? should we submit a new version and ask for IETF last call?
I have tried to do everything. Problem with the updates thing. The replace or amend strategy does not really work.... [Roman] I'd propose a simple fix by using (approximate phrases such as) either: This section updates Section xxx of [RFC5216] by amending it with the following text. (for the cases where the intent is to keep the existing text in rfc5216 but add this new text) This section updates Section xxx of [RFC5216] by replacing it with the following text. (for the cases where the intent is to replace an entire section in rfc5216)
NAME We should likely not do to much changes. Maybe we can write something like Amends with the following text. TLS 1.2 specific details in RFC 5216 are replaced. Requirement in the new takes precedence over requirements in the old text.
This review was addressed in earlier submissions. closing

Revised text:
figbase1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest  <ins> nor post-handshake messages are sent). </ins> 2.1.2. 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 </ins> (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 TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS.  Therefore, some normative text in Section 2.1.3 of RFC5216 does not apply for TLS 1.3.  The two  <ins> paragraphs below replace 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 exception that SessionID is deprecated. This is a new section when compared to RFC5216 and only applies to TLS 1.3.  RFC4137 offers a proposed state machine for EAP.  <ins> TLS 1.3 RFC8446 introduces post-handshake messages.  These post- handshake messages use the handshake content type and can be sent after the main handshake.  Examples of post-handshake messages are </ins> NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS.  After sending TLS  <ins> Finished, the EAP-TLS server may send any number of post-handshake </ins> messages in separate EAP-Requests. To provide a protected success result indication and to decrease the followed: When an EAP-TLS server has successfully processed the TLS client  <ins> Finished and sent its last handshake message (Finished or a post- handshake message), it sends an encrypted TLS record with application data 0x00.  The encrypted TLS record with application data 0x00 is a </ins> protected success result indication, as defined in RFC3748.  After  <ins> sending an EAP-Request that contains the protected success result </ins> indication, the EAP-TLS server must not send any more EAP-Request and may only send an EAP-Success.  The EAP-TLS server MUST NOT send an encrypted TLS record with application data 0x00 alert before it has layer.  To perform resumption in a secure way, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full  <ins> handshake.  This document uses the term "cached data" to describe such information.  Authorization during resumption MUST be based on such cached data.  The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data.  Any security </ins> policies for authorization MUST be followed also for resumption.  The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have reduced.  If the