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