Mališa Vučinić <[email protected]> wrote: >> One doubt I have is how does the JRC send the Observe response to the >> joined node, when the request came over a Join Proxy. Essentially, the >> JRC needs to send the response to the global IPv6 address of the >> joined node, that it never used before, but it is able to construct >> it, as it knows the network prefix and the node identifiers (EUI-64, >> short address). @Christian, is there any problem of doing this in >> terms of CoAP?
> Why not have the joined node, after joining, send a GET with observe to
> the JRC to receive rekeys?
> Hi Peter,
> Would there be any semantical difference to doing that in respect to
doing it
> in the Join Request? If we can do it in 2 messages, why use 4? I see it
more
> as the implementation problem, since JRC+CoAP implementation will need to
> override the IP address of the observing client. In terms of compliance
with
> the security specs, I would say that it's OK, as we use OSCORE, not DTLS
where
> there is a binding of the session with IP addresses.
While I can conceive of updating the OBSERVE registration in the JRC so that
subsequent messages go out to the assigned address, it would seem to be
possibly violate the some amount of laying between applications and coap (and
OSCORE) libraries.
I think we should use FETCH and suggest the OBSERVE option be added, but that
the client MUST be willing to repeat with a GET if the JRC does not return
the OBSERVE option. Given that, I think that we have to document the second
situation.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
