[Emu] RFC 7170 Erratum 5844

2020-01-22 Thread Eliot Lear
If we accept erratum 5845, then it seems only natural that we should accept 
this erratum as well.

> Section 3.3.1 says:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  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.
> 
> It should say:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> Notes:
> 
> Description of whether Intermediate-Result TLV is supposed to be used in the 
> case where only a single inner EAP authentication method is used. Section 
> 3.3.1 says "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", Section 3.3.3 says "The Crypto-Binding TLV and 
> Intermediate-Result TLV MUST be included to perform cryptographic binding 
> after each successful EAP method in a sequence of one or more EAP methods", 
> 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform 
> cryptographic binding after each successful EAP method in a sequence of EAP 
> methods", Annex C.3 shows an example exchange with a single inner EAP 
> authentication method with use of Intermediate-Result TLV.
> 
> It looks like the majority of the places discussion this topic implies that 
> there is going to be an Intermediate-Result TLV after each inner EAP 
> authentication method and the text in 3.3.1 is the only clear case of 
> conflicting (or well, at least misleading if one were to claim it does not 
> explicitly say MUST NOT for the one inner EAP authentication method case). As 
> such, I'd conclude the Intermediate-Result TLV is indeed going to be 
> exchanged after each EAP authentication method and the proposed text change 
> to 3.3.1 covers that.


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] RFC 7170 Erratum 5845

2020-01-22 Thread Eliot Lear
Hi Jouni and all,

Getting back to 7170 errata.

You wrote:
> Section 3.3.1 says:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  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.
> 
> It should say:
> 
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
> 
> Notes:
> 
> Description of whether Intermediate-Result TLV is supposed to be used in the 
> case where only a single inner EAP authentication method is used. Section 
> 3.3.1 says "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", Section 3.3.3 says "The Crypto-Binding TLV and 
> Intermediate-Result TLV MUST be included to perform cryptographic binding 
> after each successful EAP method in a sequence of one or more EAP methods", 
> 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform 
> cryptographic binding after each successful EAP method in a sequence of EAP 
> methods", Annex C.3 shows an example exchange with a single inner EAP 
> authentication method with use of Intermediate-Result TLV.
> 
> It looks like the majority of the places discussion this topic implies that 
> there is going to be an Intermediate-Result TLV after each inner EAP 
> authentication method and the text in 3.3.1 is the only clear case of 
> conflicting (or well, at least misleading if one were to claim it does not 
> explicitly say MUST NOT for the one inner EAP authentication method case). As 
> such, I'd conclude the Intermediate-Result TLV is indeed going to be 
> exchanged after each EAP authentication method and the proposed text change 
> to 3.3.1 covers that.
> 
> 

Given the example in Section C.3, odd as it seems, is there any reason not to 
accept this erratum?

Eliot


signature.asc
Description: Message signed with OpenPGP
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu