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

From: Friedhelm Rodermund <[email-masked]>
Date: Wed, 1 Mar 2017 17:41:50 +0100

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 <[email-masked]> 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: 	[email-masked]
> To: 	Christian Groves <[email-masked]>, Christian Groves <[email-masked]>, Weiwei Yang <[email-masked]>
> 
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Mojan Mohajer <[email-masked]>
Date: Tue, 7 Mar 2017 18:45:34 +0100

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:[email-masked]] 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,

Regards,
Friedhelm

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 8 Mar 2017 15:55:56 +1100

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

---

From: Nikos Fotiou <[email-masked]>
Date: Wed, 8 Mar 2017 12:13:21 +0200

Hi all,
I have a naive question. Why all these should be provided by CoAP and 
not by the application layer? IMHO this functionality overloads CoAP 
with semantics. Isn't there the danger to result with a bloated protocol?

Best,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 8 Mar 2017 11:22:47 +0100

Hi Nikos,

Mojan provided examples below to illustrate how the functionality
defined in the draft could be used.

Furthermore, draft-groves-core-bas-00 is an extension to the Dynamic
Resource Linking draft, which itself is an extension to the CoAP Observe
mechanism. CoAP is already published as an RFC and cannot be "bloated"
as such.

Ciao
Hannes

On 03/08/2017 11:13 AM, Nikos Fotiou wrote:
>> 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?
>> 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
>>
>>
>>
>>
>>> 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.
>>>
>>> To:     Christian Groves <[email-masked]>,
>>> Christian Groves <[email-masked]>, Weiwei Yang
>>> <[email-masked]>
>>>
>>>
>>>
>>> URL:           
>>> https://www.ietf.org/internet-drafts/draft-groves-core-bas-00.txt

---

From: Mojan Mohajer <[email-masked]>
Date: Wed, 8 Mar 2017 11:45:00 +0100

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:[email-masked]] 
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,

It would be possible to support your scenarios below utilising bas from the current draft by doing multiple observes on the collection. E.g.

/collection

/collection/temperature

/collection/batterylevel

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:
>      * 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
>
>
>
>

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600

Clearly, each observe request and response stream needs to respect it's own token sequence.

> On Mar 8, 2017, at 4:45 AM, Mojan Mohajer <[email-masked]> wrote:
> 
> 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

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 10:10:31 -0600

In section 2.1
   The current text of [I-D.ietf-core-interfaces] indicates that observe
   may be supported on an item in a collection not on the collection
   itself.  
I don't think we should say that observe isn't supported on collections. 

Observe should be supported for any resource, and by definition "caches" the entire method call (for example GET with all its options) for subsequent responses.

Observe doesn't say what triggers the subsequent responses, which dynlink and bas do specify.

Do I understand it correctly?

Best regards,

Michael

---

From: Christian Groves <[email-masked]>
Date: Thu, 9 Mar 2017 21:13:57 +1100

Hello Nikos,

I agree with Hannes' comments. Plus to me introducing multiple 
application specific ways to perform the same functionality is a form of 
bloat. Having this generic functionality prevents having to define 
multiple ways to do the same thing.

Regards, Christian

On 8/03/2017 9:22 PM, Hannes Tschofenig wrote:
>>> notification message

---

From: Christian Groves <[email-masked]>
Date: Thu, 9 Mar 2017 21:19:02 +1100

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 9 Mar 2017 21:33:45 +1100

Hello Michael,

The text on collections was a left over from before I took over the 
editorship. The text in [I-D.ietf-core-interfaces] is:

      3.6
      <https://tools.ietf.org/html/draft-ietf-core-interfaces-08#section-3.6>.
      Observing Collections

    Resource Observation via [I-D.ietf-core-dynlink 
<https://tools.ietf.org/html/draft-ietf-core-interfaces-08#ref-I-D.ietf-core-dynlink>] using CoAP [RFC7252 <https://tools.ietf.org/html/rfc7252>]
    MAY be supported on items in a collection.  A subset of the
    conditional observe parameters MAY be specified to apply.  In most
    cases pmin and pmax are useful.  Resource observation on a
    collection's items resource MAY report any changes of resource state
    in any item in the collection.  Observation Responses, or
    notifications, SHOULD provide representations of the resources that
    have changed in SenML Content-Format.  Notifications MAY include
    multiple observations of a particular resource, with SenML time
    stamps indicating the observation times.

The text in 2.1 of the BAS draft is just trying a paraphrase that. Did 
you want to clarify that text?

Regards, Christian

On 9/03/2017 3:10 AM, Michael Koster wrote:
> Observe should be supported for any resource, and by definition 
> "caches" the entire method call (for example GET with all its options) 
> for subsequent responses.
>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 9 Mar 2017 12:56:24 +0100

Hello Nikos,

On Wed, Mar 08, 2017 at 12:13:21PM +0200, Nikos Fotiou wrote:
> I have a naive question. Why all these should be provided by CoAP and not by
> the application layer?

I'd see these extensions in a similar fashion as the core-interfaces: it
provides one (suggested but not prescribed) way to use observable CoAP
resources.

> IMHO this functionality overloads CoAP with semantics. Isn't there the
> danger to result with a bloated protocol?

I do agree that in general, parameter names should stay free for
applications to choose.

Even though the Function Set terminology has been abandoned AFAIR,
could we use a if= value (possibly piggy-backing on one of the
core-interfaces or dynlink values) to ensure that the 'bas=' parameter
does not gain meaning (thus becoming practically reserved) for all
resources, but only those that implement it?

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: Michael Koster <[email-masked]>
Date: Thu, 9 Mar 2017 10:06:04 -0600

Yes, the text below should be changed. The description here seems to be a little inconsistent with the definition of observe, in that it suggest you may only need to send the representations for resources that have changed. 

I think my description in the email is more what we want to say, that the collection representation specified in the original request is returned.

We should mention conditional observe on collections in a way that leaves it open for bas

Best regards,

Michael

> On Mar 9, 2017, at 4:33 AM, Christian Groves <[email-masked]> wrote:
> 
> Hello Michael,
> 
> The text on collections was a left over from before I took over the editorship. The text in [I-D.ietf-core-interfaces] is:
> 
> 
>     3.6
>   Resource Observation via [I-D.ietf-core-dynlink <https://tools.ietf.org/html/draft-ietf-core-interfaces-08#ref-I-D.ietf-core-dynlink>] using CoAP [RFC7252 <https://tools.ietf.org/html/rfc7252>]
> The text in 2.1 of the BAS draft is just trying a paraphrase that. Did you want to clarify that text?
> 
> Regards, Christian
> 
>

---

From: Mojan Mohajer <[email-masked]>
Date: Thu, 9 Mar 2017 17:10:37 +0100

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:[email-masked]] 
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

---

From: Christian Groves <[email-masked]>
Date: Fri, 10 Mar 2017 16:26:41 +1100

Hello Christian,

It's something to be discussed in Chicago whether we roll the bas 
parameter into the dynlink draft or to keep it separate.

With regards to the reservation of parameter names if we allow a free 
for all on naming then we'll end up with problems of overlapping 
parameters exactly like we've already had between the resource directory 
and dynlink drafts on the name "lt" achieving two different functions.

I mentioned in the discussion about dynlink on the list about the 
possibility to update the RD draft to create a generic registry for CoAP 
query parameters. I think this could easily be achieved by adding an 
extra column to the table in section 
12.4/draft-ietf-core-resource-directory indicating some sort of 
context/scope e.g. the applicable interface description or resource 
types. Again this is something that CoRE could discuss in Chicago.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 10 Mar 2017 16:38:36 +1100

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

---

From: Christian Amsüss <[email-masked]>
Date: Fri, 10 Mar 2017 09:04:28 +0100

Hello bas & RD planners,

On Fri, Mar 10, 2017 at 04:26:41PM +1100, Christian Groves wrote:
> [...] problems of overlapping parameters [...] "lt" achieving two
> different functions.
> 
> [...] update the RD draft to create a generic registry for CoAP
> query parameters. I think this could easily be achieved by adding an extra
> column to the table in section 12.4/draft-ietf-core-resource-directory
> indicating some sort of context/scope e.g. the applicable interface
> description or resource types.

I think this is a good approach. It should be worded in a way it makes
sure that people can use query parameters as they like, as long as they
don't implement any of the listed if=/rt= values and conflict with those
names; maybe even along the lines of "This registry documents query
parameters used by particular interfaces or resource types. Registering
a specification's query parameters in it allows applications to
simultaneously implement different interfaces without parameter name
conflicts".

It's still problematic w/rt RFC7320 (due to which we don't hardcode /rd
[1]) section 2.4 [2], but should resolve any qualms about CoAP
extensions restricting applications'/owners' freedom to pick their own
query parameters.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/X6Fv5NZYCuPDEPkIcJ0b-0UdA7s
[2]: If I read it correctly, we should allow even pagination etc to
     happen as specified by the server, but that'd require URI template
     or similar capabilities we're probably not ready to mandate in
     constrained clients.

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600

---

From: Michael Koster <[email-masked]>
Date: Wed, 8 Mar 2017 04:51:30 -0600