Re: [core] New Version Notification for draft-groves-core-bas-00.txt

Hello Mojan,

I can add something in the next version. I'm not sure whether i'll get 
to it before the document deadline for Chicago though.

With regards to time=x+14400 and pmin, if the client sets pmin=14400 
that's the behaviour it should expect. BTW if the client wants further 
notifications below the 40% mark then it would be better off using the 
band parameters defined in draft-groves-core-obsattr. The lth and gth 
only trigger when the value goes through the threshold.

Regards, Christian

On 10/03/2017 3:10 AM, Mojan Mohajer wrote:
> Hello Michael & Christian,
> Thanks for the clarifications. If you decide to include an example scenario like the one we've been discussing in the future drafts, it may be worth showing separate responses from the server with correct tokens to emphasise this.
> It may also be worth indicating the expected behaviour when pmin is specified as observe parameter on a sub-resource in a collection when there is more than one observes request as per previous example:
>
> 1. GET /collection?bas=temp & gth=21.2 cel, pmax=86400 (Token: 0x01, Observe: 0)
> 2. GET /collection?bas=battery_level, st=2, lth=40, pmin=14400, pmax=604800 (Token: 0x02, Observe: 0)
>
> time=x : temperature goes over the specified threshold and the server reports the values of sub-resources in the collection (temp, battery level, signal strength)
> time=x+400:  battery level drops below 40% or changes by 2% or more.
>
> If pmin for battery level reporting is taken to start from time x, then the step change or battery level dropping below specified threshold will not generate a report from the server for another 14000 seconds, i.e. till time=x+14400. Not sure if this behaviour will be in-line with clients' expectations.
> Best Regards,
> Mojan
>
>
> -----Original Message-----
> From: Christian Groves [mailto:cngroves.std@gmail.com]
> Sent: 09 March 2017 10:19
> To: Mojan Mohajer; Friedhelm Rodermund
> Cc: core
> Subject: Re: [core] New Version Notification for draft-groves-core-bas-00.txt
>
> Hello Mojan,
>
> As Michael points out the server would have to respect the tokens in the Observe request. E.g. if /collection?bas=temp results in a notification then Token: 0x01 would be used.
>
> Regards, Christian
>
>
> On 8/03/2017 9:45 PM, Mojan Mohajer wrote:
>> Hello Christian,
>> Yes, I can see the current proposals actually caters for the example scenario. Thanks for pointing this out.
>> I guess in this example after CoAP server receives the second observe request it can use either Token 0x01 or 0x02 when notifying the resources in the collection back to the client and client can match it to its observe requests as appropriate.
>> Best Regards,
>> Mojan
>>
>> -----Original Message-----
>> From: Christian Groves [mailto:cngroves.std@gmail.com]
>> Sent: 08 March 2017 04:56
>> To: Mojan Mohajer; Friedhelm Rodermund
>> Cc: core
>> Subject: Re: [core] New Version Notification for
>> draft-groves-core-bas-00.txt
>>
>> Hello Mojan,
>>
>> Thanks for your comments and additional scenarios.
>>
>> It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g.
>>
>> Given the following link structure:
>>
>> /collection
>>
>> /collection/temperature
>>
>> /collection/batterylevel
>>
>> /collection/signalstrength
>>
>> Two observations would be enough to satisfy the scenario below.
>>
>> 1. GET /collection?bas=temp, gth=21.2 cel, pmax=86400 (Token: 0x01,
>> Observe: 0)
>>
>> 2. GET /collection?bas=battery level, st, lth, pmin & pmax (Token:
>> 0x02,
>> Observe: 0)
>>
>> The signal strength, battery level and temperature would be returned at each notification because the entire collection is returned upon meeting the observation parameters.
>>
>> Does this suffice?
>>
>> Having more complicated logic where there's an interaction between the resources (e.g. a notification due to battery level would satisfy the temperature "once a day" criteria) is envisaged to be handled by the FETCH method described in the draft.
>>
>> Regards, Christian
>>
>>
>> On 8/03/2017 4:45 AM, Mojan Mohajer wrote:
>>> Hello Christian, et al
>>> The "bas" attribute looks extremely useful and certainly addresses a number important use cases. It can also perhaps be extended to cover a more generic use case where each resource within the reported collection can have its own separate set of observation parameters. For example, a typical scenario could be to monitor a temperature sensor, device battery level that the sensor is physically attached to and  measured radio signal strength when device accesses cellular network. Each of these monitored resources can/should have independent observation parameters such as:
>>>       * Measured temperature value is reported when it exceeds a set threshold, or at least once a day (gth=21.2 celsius; pmax=86400)
>>>       * Battery level to be reported based on st, lth, pmin and pmax observation parameters such as notification is sent when it drops below a certain % or there is a marked step change which could indicate unusual/unauthorised activity. In the absence of the first two conditions it should be reported at least once a week or at most once a day?
>>>        * Measured radio signal strength to be included in every
>>> notification message My reading of “bas” attribute is that it can only be applied to one resource in the collection and cannot be used to specify different observation parameters on each resource within the collection as highlighted in the above use case.
>>> Best Regards,
>>> Mojan
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: core [mailto:core-bounces@ietf.org] On Behalf Of Friedhelm
>>> Rodermund
>>> Sent: 01 March 2017 16:42
>>> To: Christian Groves
>>> Cc: core
>>> Subject: Re: [core] New Version Notification for
>>> draft-groves-core-bas-00.txt
>>>
>>> Thanks Christian,
>>>
>>> I agree it would be very valuable to support this use case.
>>>
>>> Regards,
>>> Friedhelm
>>>
>>>
>>>> On 24 Feb 2017, at 01:42, Christian Groves <cngroves.std@gmail.com> wrote:
>>>>
>>>> Hello all,
>>>>
>>>> FYI I've submitted a draft addressing the use case discussed on the list allowing the value of one resource to trigger the notification of other resources.
>>>>
>>>> It proposes to use a collection that would allow binding/observe attributes on a sub-resource (item). Once the criteria is met then the value of the collection is returned. The batch and/or linked batch interfaces are used to control the resources that are returned.
>>>>
>>>> There's also a discussion of a more complex use case utilising the FETCH method.
>>>>
>>>> Like the other attributes the goal would be to have this as part of draft-ietf-core-dynlink.
>>>>
>>>> Comments?
>>>>
>>>> Regards, Christian
>>>>
>>>>
>>>>
>>>> -------- Forwarded Message --------
>>>> Subject: 	New Version Notification for draft-groves-core-bas-00.txt
>>>> Date: 	Mon, 20 Feb 2017 20:41:27 -0800
>>>> From: 	internet-drafts@ietf.org
>>>> To: 	Christian Groves <christian.groves@mail01.huawei.com>, Christian Groves <Christian.Groves@mail01.huawei.com>, Weiwei Yang <tommy@huawei.com>
>>>>
>>>>
>>>>
>>>> A new version of I-D, draft-groves-core-bas-00.txt has been
>>>> successfully submitted by Christian Groves and posted to the IETF
>>>> repository.
>>>>
>>>> Name:		draft-groves-core-bas
>>>> Revision:	00
>>>> Title:		Binding Attribute Scope
>>>> Document date:	2017-02-21
>>>> Group:		Individual Submission
>>>> Pages:		7
>>>> URL:            https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-groves-core-bas/
>>>> Htmlized:       https://tools.ietf.org/html/draft-groves-core-bas-00
>>>>
>>>>
>>>> Abstract:
>>>>      This document specifies an additional CoAP binding attribute that
>>>>      allows binding attributes to be scoped to an item (sub-resource) in a
>>>>      collection resource.  This allows synchronisation of multiple
>>>>      resources in a collection based on the value of one resource.
>>>>
>>>>                                                                                     
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission until the htmlized version and diff are available at tools.ietf.org.
>>>>
>>>> The IETF Secretariat
>>>>
>>>> .
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> core@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/core
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>>>
>>>
>>
>
>