On Thu, Mar 22, 2018 at 5:42 PM peter van der Stok <stokc...@xs4all.nl> wrote:
> > No semantic difference that I know. You expressed a worry about > addressing the joining node from JRC. > Not sure any more, but do you use the IP-in-IP proxy? If yes, > maintaining the encapsulation in all following traffic seems necessary. > No, I do not consider IP-in-IP proxy here. The pledge sends the Join Request to the Join Proxy (CoAP), so the JRC effectively does not know the IPv6 address of the pledge at this time, when the Observe option is included. The Join Response is similarly sent over the Join Proxy (using the Stateless-Proxy mechanism), but my doubt was related to the fact that subsequent Observe responses for rekeying, for example, should not go over the Join Proxy (the pledge joined the network, became a joined node, selected a potentially different parent, etc). In RFC7641, I see the following text as relevant: " The entry in the list of observers is keyed by the client endpoint and the token specified by the client in the request. If an entry with a matching endpoint/token pair is already present in the list (which, for example happens when the client wishes to reinforce its interest in a resource), the server MUST NOT add a new entry but MUST replace or update the existing one." I am tempted to say that this does not prevent us from updating the client endpoint (but not the token) based on implicit knowledge at JRC. Do you agree? -- Mališa
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
