Re: [core] Do we need a CORE charter item for CoAP support of Sleepy Nodes?

[Zach Shelby <[e-mail]>]

I agree with Peter, and am also skeptical about this work item as it has been discussed so far. 

This is really a problem that needs to be solved within a complete architecture, and we don't really have that architecture here. Other SDOs have or are solving this problem using CoRE mechanisms, for example OMA Lightweight M2M already includes simple sleep (or in general non-reachable CoAP endpoint support) using RD and queueing at a proxy. Not to mention other L2 mechanisms or application layer designs that already solve the problem. 

If we would like to document a setup to support such endpoints, then it should probably done by just documenting something done in a complete architecture for the sake of allowing re-use. We also have existing solutions like Mirror Server that can be used in some cases where that architecture is applicable. Inventing new solutions outside a full architecture and real deployments needs seems like research to me. 

Finally, we just have way too much work on our plate right now in CoRE to even think about taking more on. First, we need to ship Observe and Block to the IESG (and through the whole process), then we have three other work items we've just started on. I would think it is not time to discuss something new until we're pretty stable with those three (close to shipping them e.g.). Taking sleep work on now would just distract us from making progress. 

Zach

On Aug 5, 2013, at 9:35 AM, peter van der Stok <[e-mail]> wrote:

> In contrast to the earlier mails I am personally not convinced we should do (much) work on sleepy nodes.
> In the simplest level 3 communication case, a sleepy node needs intialization of operational parameters, is switched on, and sends regularly data to an IP address.
> More specifically, the IP address can be an MPL multicast address.
> Anything more complex needs to be done with a proxy.
> In my opinion SDOs like OMA, ZigBee, or BACnet, etc. have very different opinions on what such a proxy should do and how to communicate between the sleepy node an the proxy. They are best positioned to define the proxy in the context of their organization.
> 
> In the limit, at IETF, we just need to define a MIB for the initialization of the sleepy node.
> If we want to do more, I think the draft by Matthieu Vial covers the case quite adequately.
> 
> Peter van der Stok
> 
> 
> 
> Pierpaolo Giacomin schreef op 2013-08-04 22:26:
>> On 08/02/2013 05:23 PM, Salvatore Loreto wrote:
>> I do think we should have in CORE a deliverable for CoAP support of
>> Sleepy Nodes,
>> +1
>> we have seen a lot of ideas and mail discussion about this topic one
>> year ago,
>> and the 4 individual submissions (if I am not wrong there are also a
>> couple of the expired drafts on the topic)
>> on the same subject listed by Akbar is a clear sign of interest and
>> energy to work on it
>> cheers
>> /Sal
>> --
>> Salvatore Loreto, PhD
>> www.sloreto.com
>> On 8/1/13 6:02 PM, Rahman, Akbar wrote:
>> Hi,
>> Carsten asked me to send this message out to the WG list as we did not
>> have a chance to discuss the Sleepy Node topic in this IETF due to a
>> lack of time on the agenda.
>> ------------------------------------------------------------------------------
>> We have several current I-Ds in CORE (and LWIG) that discusses the
>> topic of Sleepy Nodes. Among those are:
>> draft-dijk-core-sleepy-reqs-00
>> <https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-reqs/>
>> draft-dijk-core-sleepy-solutions-01
>> <https://datatracker.ietf.org/doc/draft-dijk-core-sleepy-solutions/>
>> draft-hong-lwig-sleepynode-problem-statement-00
>> <https://datatracker.ietf.org/doc/draft-hong-lwig-sleepynode-problem-statement/>
>> draft-rahman-core-sleepy-03
>> <https://datatracker.ietf.org/doc/draft-rahman-core-sleepy/>
>> Hence the following question to the WG:
>> ·Should we have a CORE deliverable for CoAP support of Sleepy Nodes?
>> Please write back with your thoughts!
>> Best Regards,
>> Akbar
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: [phone]
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net