Hello Malisa:

Thanks for the answer! Please see my comments inline.
> El 2 nov 2015, a las 12:00, Malisa Vucinic <[email protected]> escribió:
> 
> Hello Rafa,
> 
> Thanks for your pointer. I am not sure though that we are fully aligned on 
> the meaning of ‘code reuse’.

> What I mean there is that we ideally want to reuse the code that already 
> makes part of the firmware image, i.e. is part of the network stack, in order 
> to minimize portions of the code that end up in firmware but get used only 
> once.

Yes, I think we are aligned. That is why we proposed EAP over CoAP (you reuse 
CoAP). And as Robert mentioned certain EAP methods can re-use source code.

On the other hand, I have some doubts this source code will be used only once.

> 
> Also, I am not sure how you got the impression that “EAP overhead” implies an 
> insurmountable obstacle when it clearly depends on the method.

I felt from the comments (my apologies if I was wrong) that EAP was somehow 
discarded due to the “EAP overhead”. That is why I made this clarification. But 
I agree with you, it depends on the method.

> Could you elaborate on the 14-byte figure, I am not sure I follow you there?

EAP-AKA has two messages + EAP Success : EAP-Req/AKA (4 bytes header EAP + 1 
the type) +  EAP-Resp/AKA (4 bytes header EAP +1 the type) + EAP success(4 
bytes) = 14 overhead with respect to running “AKA" without EAP. 

Hope this helps.

Best Regards.

> 
> Regards,
> Mališa
> 
> 
>> On 01 Nov 2015, at 19:17, Rafa Marin Lopez <[email protected]> wrote:
>> 
>> Hi Malisa:
>> 
>> As additional comment:
>> 
>> In http://sourceforge.net/projects/panatiki/ you can find an PANA client we 
>> implemented for Contiki OS that we have tested in different platforms. We 
>> have also an implementation for mbed platform. I’ll soon provide a link for 
>> EAP over CoAP implementation for Contiki OS and mbed too.
>> 
>> Additionally it has been mentioned the "EAP overhead”, as something that may 
>> sound like an insurmountable obstacle. However, for example, EAP-AKA implies 
>> three messages, two related with EAP-AKA and the final EAP Success which is 
>> four byte length. EAP Req/id and Resp/id is not mandatory in EAP. The 
>> overhead in this example is 14 bytes with respect to the KMP without EAP, 
>> which, a priori, does not seem to me a terrible thing.
>> 
>> Best Regards.
> 

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email protected]
-------------------------------------------------------




_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to