Re: [core] pubsub and sleepy node proxy

Hi Peter,

I'm sorry for the delayed response.  Somehow I missed this in my Inbox and only noticed it when I was going over the reflector mailing list records.  My specific suggestions are:

- Yes, it will be good to give more design motivation in your draft.

- Eliminate the tight dependence to 6LoWPAN technology as it is a CoAP application protocol and can be run on any underlying IP network.  I'm not sure if your main motivation for the 6LoWPAN link was due to your L2 security assumptions in Section 9.  But it seems like an artificially restrictive dependence.

- The link to the PubSub server (section 7) looks tenuous and not that convincing to me.

- Editorial - The arrows between the Proxy and Sleepy Node are all 1 directional in Figure 1.  But I understood from the text that, for example, WRITE, should be a bi-directional between Proxy and Sleepy Node (i.e. a WRITE from a Configuring node to the Proxy node should ultimately result in a WRITE to the sleepy node from the Proxy).  Did I understand correctly?

Thanks for the good work.

Akbar

-----Original Message-----
From: peter van der Stok [mailto:stokcons@xs4all.nl]
Sent: Wednesday, September 09, 2015 6:19 AM
To: Rahman, Akbar <Akbar.Rahman@InterDigital.com>
Cc: consultancy@vanderstok.org; Michael Koster <Michael.koster@arm.com>; Core <core@ietf.org>
Subject: RE: [core] pubsub and sleepy node proxy

Hi Akbar,

After reading the arkko-core-sleepy draft I do have some concrete questions for you:

Do you want the following additions to the proxy:
- a http endpoint
- storage of historical values
- numbering of messages by sleepy node to estimate the reliability and to order them
- Use of NON messages from sleepy to proxy

In the arkko draft there is considerable motivation of design choices.
Do you want more design motivation in the our zotti-core-sleepy draft?

Is there anything specific I did not pick up?

Thanks for your reaction,

Peter

Rahman, Akbar schreef op 2015-09-03 06:45:
> Hi Peter,
>
>
> I am still reading the pubsub draft, but did want to give support for
> your sleepy node draft (draft-zotti-core-sleepy-nodes-03).  The sleepy
> node proxy concept that you describe will be useful in many scenarios.
>  One related comment that I did have on your draft is that it seems a
> bit fixated on the 6LoWPAN scenario.  But as we have discussed many
> times during IETF meetings and on various mailing lists, the sleepy
> node scenario is useful beyond 6LoWPAN deployments (e.g.
> https://tools.ietf.org/html/draft-arkko-core-sleepy-sensors-01 ).
> So I think it would be useful if you clarified that in your draft.
>
>
> Best Regards,
>
>
> Akbar
>
> -----Original Message-----
> From: core [mailto:core-bounces@ietf.org] On Behalf Of peter van der
> Stok
> Sent: Monday, August 31, 2015 3:06 AM
> To: Michael Koster <Michael.koster@arm.com>; Core <core@ietf.org>
> Subject: [core] pubsub and sleepy node proxy
>
> Hi Michael,
>
> Looking at the pubsub draft and at our sleepy node proxy draft, I come
> to the conclusion that there are good arguments to maintain both.
>
> Following the reasoning of Matthieu Vial, there are already a good
> arguments for the sleepy node (SN) proxy (aka mirror server) to exist
> next to the RD.
> Namely:
> Where an end-point can delegate its links to the RD for discovery, an
> end-point can delegate the links AND the associated resource values to
> the SN-proxy.
> The SN-proxy resources have the same lifetime as SN resources.
> The SN-proxy resource values are directly linked to the resources of a
> given SN.
>
> In contrast the pubsub handles anonymous values. The origin can be
> added but that means adding attributes to the topics.
> The pubsub handles the more abstract topics, where the SN-proxy is
> concerned with the resources.
> The lifetime of the values in the pubsub server is not directly linked
> to the lifetime of the originating resources.
>
> For me these are the arguments that motivate the existence of the
> pubsub draft next to the sleepy node draft.
>
> Looking forward to your reaction.
>
> Greetings
> Teresa and Peter
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core