Re: [core] Review of draft-koster-core-coap-pubsub-05

[Hannes Tschofenig <[e-mail]>]

Hi Jim,

I agree that there is more text needed on the support of so-called
sleepy nodes.

I may have over-interpreted your remarks about the topic.

Ciao
Hannes


On 08/11/2016 05:22 PM, Jim Schaad wrote:
> 
> 
>> -----Original Message-----
>> From: Hannes Tschofenig [mailto:[e-mail]]
>> Sent: Thursday, August 11, 2016 1:16 AM
>> To: Jim Schaad <[e-mail]>; draft-koster-core-coap-
>> [e-mail]; [e-mail]
>> Subject: Re: [core] Review of draft-koster-core-coap-pubsub-05
>>
>> Hi Jim,
>>
>> let me share my views on this document.
>>
>> On 08/04/2016 05:35 AM, Jim Schaad wrote:
>>> I have a hard time saying that this is ready to be published, but that
>>> is in part because I think that the security aspects that are not
>>> being addressed in the document are important.
>>>
>>>
>>> Section 3.2 - The phrase "and potentially buffer messages" is causing
>>> me problems.  By definition it must buffer the last data value that it
>>> includes.  It would be good at this point to explain exactly why it is
>>> buffering messages here.  I assume that you are talking about the flow
>>> control issues that are discussed later but I don't know this.
>>
>> The reason why the pub/sub broker buffers messages is because the IoT
> device
>> is sleeping most of the time. For that reason, it cannot always forward
> requests
>> from applications immediately.
>>
>> This is functionality called 'queue mode' in LWM2M and other terms have
> been
>> used in other IETF documents.
> 
> I agree that having a 'queue mode' would be a nice feature, but I do not
> believe that this is documented anyplace in this document.  Doing so would
> require some additional text.  The current text says that messages are
> always forwarded when they are received to a client.  If the client happens
> to be asleep then it needs to go back and ask for the current value when it
> wakes up.  
> 
>>
>> In my review I have been wondering why we aren't re-using the concepts
> from
>> LWM2M here.
>>
>> Regarding the "topics": I have read this a bit differently. For me, a node
> has
>> resources and it publishes those. Then, there are applications (Web
> applications,
>> smart phone apps) who sent requests for those resources. These resources
> have
>> to be identified somehow and in LWM2M there is a specific way of
> addressing
>> the standardized resources (and objects), as described in
>> https://www.iab.org/wp-content/IAB-uploads/2016/03/ipso-paper.pdf. Maybe
>> you want to be more generic here but I think it is important that there is
> a
>> standardized structure here and that we are not only talking in the style
> of MQTT
>> topics.
> 
> I do not follow how this came from my review.  Is this an independent item
> or is it following from something that I asked in my review?
> 
> Jim
> 
>>
>>
>> Ciao
>> Hannes
> 
>