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

[Christian Groves]

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-***@ietf.org
To: Christian Groves <***@mail01.huawei.com>, Christian
Groves <***@mail01.huawei.com>, Weiwei Yang <***@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

.

[Friedhelm Rodermund]

Thanks Christian,

I agree it would be very valuable to support this use case.

Regards,
Friedhelm

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

[Mojan Mohajer]

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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

[Christian Groves]

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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Nikos Fotiou]

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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Hannes Tschofenig]

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

Post by Nikos Fotiou
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

Post by Mojan Mohajer
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
* 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-----
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

Post by Christian Groves
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
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Groves]

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

Post by Hannes Tschofenig
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

Post by Nikos Fotiou
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

Post by Mojan Mohajer
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
* 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-----
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

Post by Christian Groves
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
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hello Nikos,

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 Groves]

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

Post by Christian Groves
Hello Nikos,

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
_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Amsüss]

Hello bas & RD planners,

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

[Mojan Mohajer]

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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Michael Koster]

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

Post by Mojan Mohajer
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

[Michael Koster]

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

[Christian Groves]

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

Post by Michael Koster
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

[Michael Koster]

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

Post by Christian Groves
Hello Michael,
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

Post by Michael Koster
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

[Christian Groves]

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

Post by Mojan Mohajer
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-----
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.
/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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Mojan Mohajer]

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

Post by Mojan Mohajer
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-----
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.
/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)
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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core

[Christian Groves]

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

Post by Mojan Mohajer
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.
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-----
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

Post by Mojan Mohajer
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-----
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.
/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)
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

Post by Mojan Mohajer
Hello Christian, et al
* 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-----
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

Post by Christian Groves
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
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
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
https://www.ietf.org/mailman/listinfo/core

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core