On Tue, Apr 10, 2018 at 09:13:23AM +0000, Mališa Vučinić wrote: > > * 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. > > Yep, so two messages to join and two additional messages for the first > rekey to happen.
A bit more: the two messages to join, and two additional messages (GET+Observe, 2.05 "observation accepted and here is the data you already have because there is no re-keying in process right now") to set up the observation for a future re-keying (where later, the re-keying itself is again the 1-2 messages it needs anyway). > > * 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) > > What would be the advantage of establishing a dynlink over specifying in > the minimal-security draft that once the pledge joins, it needs to expose a > /j resource that the JRC may use to update the keying material? This would > essentially be a static link specified in the draft. Do you see any pitfall > with that? Apart from that we should not specify statically named resources in devices' namespaces outside `.well-known/`, I see no problem with that. I wouldn't see it as a matter of being "an advantage of ... over", but more of the dynlink being the theoretical background behind and justifying what happens here; think of it as a form of compressed exchange if you will. > I don't think we have the consensus on the use of CoMI in minimal-security. > We considered it for future work, but at this point I would refrain from > pulling in new specifications.. It might still be convenient to consider, eg. whether a future implementor that *does* use CoMI can just treat your /j resource as an alias to /c/abc0815 and be done with it, because a POST there with the binary data has the desired effect. Best regards Christian -- We are dreamers, shapers, singers, and makers. -- Elric
Description: PGP signature
_______________________________________________ 6tisch mailing list email@example.com https://www.ietf.org/mailman/listinfo/6tisch