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

[Zhen Cao <[e-mail]>]

Hi Christian,

Thanks for the review and comments.  See inline response.

BR,
Zhen

On Mon, Nov 14, 2016 at 11:08 AM, Christian Amsüss
<[e-mail]> wrote:
> 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?

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.

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

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.

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

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

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

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

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

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.

>
> Best regards
> Christian
>
> --
> Christian Amsüss                      | Energy Harvesting Solutions GmbH
> founder, system architect             | headquarter:
> mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
> tel:[phone]                | http://www.energyharvesting.at/
>                                       | ATU68476614