> On 30 Oct 2015, at 15:51, Michael Richardson <[email protected]> wrote:
> 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. So, the idea in case JN is a DTLS client was that JCE can simply wait with the response to ClientHello, according to its policy and different priorities. But it would be necessary to require differentiation of ClientHello retransmission timeout from other DTLS retransmissions. The main advantage would be that the discovery mechanism of JN is simply a ClientHello, possibly including the session resumption ticket, and no other packets involved. _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
