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

We are dreamers, shapers, singers, and makers.
  -- Elric

Attachment: signature.asc
Description: PGP signature

6tisch mailing list

Reply via email to