Re: [core] Sleepy devices in CoAP - Requirements

["Dijk, Esko" <[e-mail]>]

Hello Akbar,

thanks for the feedback; here my comments:

*         draft-dijk-core-sleepy-reqs-00

o   The I-D seems to have a majority of requirements that can very realistically be addressed at the COAP application level (which is very good).  But also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g. section 4.3, item 6 - Client location).  Is my observation accurate, and if so should this duality be clearly indicated in the I-D?
-> Yes, there are requirements that influence on several levels, e.g. CoAP level or below that. I think it's good to clearly indicate this. Some requirements can even be irrelevant for a solution in the CoAP space.


o   Do you think that it would be worthwhile to note that there are two classes of sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may have predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) sleep schedules.   Maybe you had captured the concept in the text but it did not stand out for me at least.  At least section 4.7 (item 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me ...
-> Yes, that could be explicitly mentioned, agree. Also a mix between event-driven and timer-driven can be expected, for example in the described 'heartbeat' mechanism.



o   I think we need to support more than just S0 class devices as SEP (section 1.2).  For example, S1 is probably an important class of devices to also support as SEPs.
-> I was assuming S1 is not relevant because regular CoAP can be used with those devices. However, if the "high latency" mentioned for S1 class devices because sufficiently large there may be so much timeouts in CoAP that the protocol effectively stops functioning. In this case we have at least two solution directions to follow:
1) change timing parameters of CoAP protocol (requires the non-sleepy CoAP device to also know about, and use, the new timing parameters)
2) use the same solution as is used for S0 devices.

We should check whether to update the 'sleepy-reqs' I-D with such considerations, or to have these in the 'sleepy-problem-statement' I-D.

*         draft-dijk-core-sleepy-solutions-01

o   It would be nice if you included http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!
-> well, this document is not really a survey but it tries to construct a specific solution with some variations on how to implement the interfaces that are part of that solution.
There could be a similar document made with the solution of rahman-core-sleepy-02 integrated, I think.

Esko
From: Rahman, Akbar [mailto:[e-mail]]
Sent: Monday, June 17, 2013 05:13
To: Dijk, Esko
Cc: [e-mail]
Subject: RE: [core] Sleepy devices in CoAP - Requirements

Dear Esko,


Thanks for the excellent input to the Sleepy Devices space.  I have the following initial feedback on your I-Ds:


*         draft-dijk-core-sleepy-reqs-00

o   The I-D seems to have a majority of requirements that can very realistically be addressed at the COAP application level (which is very good).  But also it has some other requirements that most likely would need to be addressed at some lower level than CoAP (e.g. section 4.3, item 6 - Client location).  Is my observation accurate, and if so should this duality be clearly indicated in the I-D?



o   Do you think that it would be worthwhile to note that there are two classes of sleep patterns for sleepy devices (SEPs)?  Namely, some SEPs may have predictable (e.g. scheduled) sleep cycles and others may have completely unpredictable (e.g. external event driven) sleep schedules.   Maybe you had captured the concept in the text but it did not stand out for me at least.  At least section 4.7 (item 1- Configurable sleep interval) seems to imply only support of fully scheduled sleep cycles to me ...



o   I think we need to support more than just S0 class devices as SEP (section 1.2).  For example, S1 is probably an important class of devices to also support as SEPs.

*         draft-dijk-core-sleepy-solutions-01

o   It would be nice if you included http://tools.ietf.org/html/draft-rahman-core-sleepy-02 in your survey!





Best Regards,


Akbar


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Dijk, Esko
Sent: Wednesday, June 12, 2013 1:59 AM
To: core ([e-mail]<mailto:[e-mail]>)
Subject: [core] Sleepy devices in CoAP - Requirements

Dear all,

as input to last year's discussion on 'sleepy devices' in CoAP I have uploaded an I-D that aims to capture the requirements for sleepy devices.
As discussed in the IETF 83 CoRE meeting, we can create a solution once the requirements are sufficiently clear. The I-D is:
http://tools.ietf.org/html/draft-dijk-core-sleepy-reqs-00

Also I've uploaded a second I-D to provide possible solutions to meet these requirements, based on an architecture that uses a specific type of intermediary to interface to the sleepy devices:
http://tools.ietf.org/html/draft-dijk-core-sleepy-solutions-01

regards,
Esko

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.