Re: [core] Fwd: New Version Notification for draft-cao-core-delegated-observe-00.txt

[Christian Amsüss <[e-mail]>]

Hi Zhen,

On Mon, Nov 14, 2016 at 01:46:50PM +0800, Zhen Cao wrote:
> > * [...]the in-home dev could simply implement a proxy and open a
> >   coap-over-tcp connection to the cloud server?
> 
> The in-home dev is nomadic, and it initiates the observe while at
> home, so that it can fetch the information when it is off.  So,
> opening a coap-o-tcp connection is not appropriate solution.

I see -- it says so in the text, but I misinterpreted the diagram. This
is how I would draw it:

               dev            Cloud            dev
Sensor       in-home          Server         off-home
  |              |              |                
  |   Delegated  |              |                
  |<--Observe  --|              |                
  |              |              |                
  |--------Notification-------->|                 
  |              |              |                
  |               \ dev gets moved out of home \
  |                             |               |
  |                             |<-- GET--------|
  |                             |----- ACK----->|

                     Figure 1: Delegation to Cloud

This setup seems very brittle to me because it can't be restablished
once the observation breaks for any reason (eg. on an intermittent
connection outage), so I'd like to explore possible alternatives that
are less ephemeral:

* resource directory with the dev in-home as commissioning tool: Use
  case 3.1 of draft-ietf-core-resource-directory-09 describes how the
  sensor could register itself with the cloud server (and not only a
  single observation, but it can of course limit the cloud server's
  access). The UDP "connection" in which it registers doubles as a
  channel through which the cloud server can send requests (including
  observations) to the sensor.

  I'm not sure whether the RD draft already contains a way for
  dev-in-home to actively instruct sensor to furtheron register with a
  particular RD (commissioning tools as described there talk to the RD
  directly, thereby breaking the UDP connection; my best guess would be
  that dev-in-home announces <coap://cloud.server/rd>;rt="core.rd"), but
  I'm sure that can be clarified.

  This is broader than delegate observation, but it uses patterns that
  already in active use.

* push dynlinks: Instead of negotiating a token with the cloud server,
  the dev-in-home negotiates a URL there (say /~user/temp).

  It then does a POST to coap:////sensor/bnd/ with
  <coap://cloud.server/~user/temp>;rel="boundto";anchor="/temp";bind="push"
  , and the sensor can start sending a PUT with the value whenever a new
  value is available.

  When the dev is in-home again, it can check whether the dynlink is
  still present or modify it by manipulating the /bnd/ (or wherever the
  device has an if=core.bnd) resource again.


Some more notes:

* The examples in A.1 show the 2.05 responses with 'Header: GET'. The
  hex numbers afterward resemble those in the rfc7641 examples, but
  there the number is the full encoded header (eg. 0x4101 = (ver = 1) <<
  22, (type non = 0 << 20), (tkl = 1) << 16, (code GET = 1) << 0).

  When interpreted as message IDs, the initial notification to the
  target node has no reason to share the message ID with the original
  GET (those are scoped to endpoints).

* The cloud server would not only need to agree on a token with the
  dev at in-home time, but the complete request headers. That
  information is needed for the cloud server to re-register its interest
  in the resource or to cancel the observation.

* The d-o option is used in responses as a sequence number. What is the
  advantage of using the delegated option here over the observe option?

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom