>>>>> "Martin" == Martin Stiemerling <martin.stiemerl...@neclab.eu> writes:
Martin> Hi Sam,
Martin> On 08/14/2013 10:16 PM, Sam Hartman wrote:
>>>>>>> "Joseph" == Joseph Salowey (jsalowey) <jsalo...@cisco.com>
>>>>>>> writes:
>>
Joseph> [Joe] Retransmission and timeout behavior for EAP is
Joseph> discussed in the EAP RFC 3748 Section 4.3.
>>
>> Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap)
>> would be really unhappy if EAP method specs started discussing
>> timeouts.
Martin> It is not about the EAP timeouts for whole messages, but
Martin> timeouts for fragments are not defined in RFC 3748 and must
Martin> be defined somewhere, as well as, what happens if timeouts
Martin> are exceeded for fragments.
If an inner method supports fragmentation, then each fragment is a
"whole EAP message," in your terminology quoting RFC 3748.
More particularly, the interface between EAP and a lower layer says that
EAP methods hand EAP a message.
The EAP state machine gets a timeout from the lower layer as defined in
RFC 3748.
The EAP state machine uses the retransmit behavior in RFC 3748.
It's possible that a method has internally fragmented some larger (we'll
call these fragmentables for the moment) messages into the EAP messages
handed to EAP by the method.
If so, then EAP has no way to know whether these are fragments or
whether the method simply doesn't support fragmentation.
At the EAP layer, messages are messages.
The difference between messages and fragmentables is only visible within
a method.
The abstract interface of EAP does not permit methods to influence the
retransmission behavior, nor for messages generated from fragmentation
to have different retransmission behavior than anything else.
I understand that the EAP state machine RFC is informational, but take a
look there; it's quite obvious the sorts of things that will break if
you try and have retransmission behavior discussed in method specs. If
there's something wrong with RFC 3748, fix in an update to that spec and
in updates to the state machines.
However, other than being quite inefficient, I think the retransmission
behavior of EAP is fine.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
