Re: [core] pubsub and sleepy node proxy

Hi Rahman,

thanks for the concrete suggestions, see below

Rahman, Akbar schreef op 2015-09-17 18:36:
> 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.
<pvds>
will think about this
</pvds>
> 
> - 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.
<pvds>
will look at it; has to do with the history of this work.
</pvds>
> 
> - The link to the PubSub server (section 7) looks tenuous and not that
> convincing to me.
<pvds>
Fully agree, a more appropriate one has been done.
</pvds>
> 
> - 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?
<pvds>
Ehh, they are inter-actions. I suggest to remove the arrows
</pvds>
> 
> 
> Thanks for the good work.
> 
> 
> Akbar

thanks for the feedback,

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