https://www.rfc-editor.org/errata/eid5767

TODO: Implementors should verify that this change makes sense,
and matches their implementations.

TODO: Did not make the suggested changes

3.3.3: "after each successful EAP method" --> "after each successful EAP authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP authentication method"

because there are other references to "EAP method", including
in the abstract.  Further, RFC 3748 uses "EAP method" everywhere
to mean "EAP authentication method", including Section 2.2 [2],
which states:

       EAP methods implement the authentication
       algorithms and receive and transmit EAP messages via the EAP peer
       and authenticator layers.

draft-ietf-emu-rfc7170bis.md

@@ -564,9 +564,9 @@ method, first using machine credentials followed by a second instance
 using user credentials.
 
 EAP method messages are carried within EAP-Payload TLVs defined in
-[](#eap-payload-tlv).  If more than one method is going to be executed in
-the tunnel, then upon method completion, the server MUST send an
-Intermediate-Result TLV indicating the result.  The peer MUST respond
+[](#eap-payload-tlv).  Upon completion of each EAP method in
+the tunnel, the server MUST send an Intermediate-Result TLV
+indicating the result.  The peer MUST respond
 to the Intermediate-Result TLV indicating its result.  If the result
 indicates success, the Intermediate-Result TLV MUST be accompanied by
 a Crypto-Binding TLV.  The Crypto-Binding TLV is further discussed in