Hello Mališa, On Fri, Mar 23, 2018 at 10:12:16AM +0000, Mališa Vučinić wrote: > 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?
observation is fundamentally a hop-to-hop thing (terminated at proxies); both the token and the observation counter are scoped to those hops, and while a minimal proxy may get away with passing them on unmodified, I doubt that that can be used to form a stable mechanism. The topic of a delegated observe has been brought up before[1] (with a focus on nomadic devices), and was not followed up to after initial comments. If minimal-security were to do observations that hops off a proxy observation to a direct one, it'd need a specification similar to that (with its holes filled) to let that observation hop off smoothly. (Whether the observation is FETCH or GET is immaterial here, and in this setting it's a good approximation to say that the difference is that the FETCH allows binary data with a mime type to be part of the request, which would in a GET need to be squished into a query string). As I understand, even richardson-6tisch-minimal-rekey needs to transport that modelled data, so at any rate I can suggest two alternatives to a hopping observation: * Don't observe through the proxy, but establish an observation after the address has been assigned. This incurs cost of two additional packages, but is conceptually simple and straightforward. * Establish a dynlink (formerly bindings) to make the JRC PUT (or PATCH) the node. This would take two additional messages as well (the former pledge requesting a dynlink once it knows its final address, plus its response). This is the less common but more versatile approach to observation. An advantage over plain observation is that it might be possible to establish this link in another way than explicitly requesting it (eg. piggy-backing an "and when you've managed, please keep me posted on /X relative to whatever address I might have then", or by the JRC knowing from somewhere else that such a binding is to be established) 6tisch-minimal-rekey sounds like it is a valid expectation that the nodes will use CoMI; if that is the case and this approach is followed, the PUT/PATCHing that would be the result of a dynlink cold probably be set up implicitly. Best regards Christian [1]: https://mailarchive.ietf.org/arch/msg/core/-emsRTJmyyFHlrNwbJkqGfXQaYw -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
