{please forgive the lateness of this email. Illness, etc.}
As others have said this is a great analysis. Thank you so much!
see inline.case 1A potentially has a significant code-reuse if either MLE or 802.15.9 will be used to establish per-link keys. Despite the conversation in subsequent thread, I'm not convinced that a mere 4 messages will suffice between JA/JCE to perform the mutual authorization required between JCE and JN. Case 1A, might have significant overlaps with the ACP of ANIMA. Malisa Vucinic <[email protected]> wrote: > Option 2 leverages the DTLS implementation that is in any case mandated > by CoAP so it does not necessitate much additional implementation > effort, other than the JA relay application. Another advantage here is So there are several options here, one of which has the JN as a client, a different one would have the JN as a responder. There is additionally a question of whether the DTLS Client/Server direction needs to match the the CoAP direction. I think there is a significant need to permit the JCE to manage the order and bandwidth from the join process. This method is also most in-line with the work the Thread Group has done, but I do not yet know enough about the DTLS extensions they created to make the work the JA does stateless. Maybe once I finish reading (2hr more on this flight, 10h on next one...) I'll be able to say more. -- Michael Richardson -on the road-
pgptyX635vwkC.pgp
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
