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

From: Zhen Cao <[email-masked]>
Date: Mon, 14 Nov 2016 10:01:19 +0800

Comments welcome.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Oct 27, 2016 at 4:50 PM
Subject: New Version Notification for draft-cao-core-delegated-observe-00.txt
To: Zhen Cao <[email-masked]>, Rahul Arvind Jadhav
<[email-masked]>

A new version of I-D, draft-cao-core-delegated-observe-00.txt
has been successfully submitted by Zhen Cao and posted to the
IETF repository.

Name:           draft-cao-core-delegated-observe
Revision:       00
Title:          CoAP Delegated Observe
Document date:  2016-10-27
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-cao-core-delegated-observe-00.txt
Status:
https://datatracker.ietf.org/doc/draft-cao-core-delegated-observe/
Htmlized:       https://tools.ietf.org/html/draft-cao-core-delegated-observe-00

Abstract:
   This document discusses the scenarios for "delegated observe", in
   which a subscriber needs to register some resources on behalf of some
   other entities.   This document also presents a CoAP protocol
   extension for the delegated observe operation.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 14 Nov 2016 04:08:59 +0100

Hello Zhen,

thank you for submitting a draft.

I've read through your delegated-observe draft, and have several
questions / suggestions regarding it:

* Regarding the cloud use case: Using an unspecified protocol to
  negotiate this setup (where for example a token would need to be
  exchanged that the in-home dev would then use) strikes me as
  relatively complex for the given task. Have you considered that the
  in-home dev could simply implement a proxy and open a coap-over-tcp
  connection to the cloud server?

  If the cloud server implements a proxy itself, the dev off-home could
  send the same observe request as it locally would, just to the cloud
  server as a forward proxy (which then again uses a second forward
  proxy), and neither a delegate observation nor an additional
  observation negotiation protocol is needed.

* Multicast: Have you considered the applicability of
  draft-ietf-core-dynlink-01 or draft-ietf-core-coap-pubsub-00?

* Multicast: Some protocol would be required for the bulbs to coordinate
  too, because Bulb_2 and Bulb_3 need to agree on a token to identify
  the incoming observation responses.

* Terminology: I find the "delegate" and "delegated" node terms
  confusing (and if it's only because a search for "delegate" also
  matches "delegated"). Maybe "Initiating node" / "Notified node" or any
  other more distinct term could replace at least one of the
  delegate{,d} names.

* Do I understand the graphs correctly that no response is sent to the
  delegate node unless it is itself in the delegated multicast group?

  If so, how is reliable transmission ensured?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Zhen Cao <[email-masked]>
Date: Mon, 14 Nov 2016 13:46:50 +0800

Hi Christian,

Thanks for the review and comments.  See inline response.

BR,
Zhen

>   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.

>   draft-ietf-core-dynlink-01 or draft-ietf-core-coap-pubsub-00?

Delegated observation or subscription could be used to the  dynlink or
pubsub. I just read through the pubsub-00 draft, and I do not think it
supports multicast pubsub as per the current text.

>   the incoming observation responses.

I agree. But sometimes, the token is optional for simple use cases.

>   other more distinct term could replace at least one of the

Thank you.  I am glad to change it in the next version and my presentation.

>   If so, how is reliable transmission ensured?

Good point, not considering this yet.  The difficulty is that how the
Source node tell if the Initiate node is included in the Notified
Group or not.
Simplest solution could be have the delegated observation request
being a confirmable message, solicit an  ACK for the request.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 14 Nov 2016 12:26:30 +0100

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?
> 

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