Draft: draft-ietf-core-dynlink

Commentary: OMA LwM2 M support for additional attributes that should be reflected back into the dynlink draft to avoid fragmentation . Those attributes are called Minimum Evaluation Period ( epmin ) and Maximum Evaluation Period ( epmax ) . The current LwM2 M Core Spec currently has this statement : " The behavior of all Attributes SHOULD follow [ DynLink ] except epmin and epmax , which are only defined in this specification . " The goal would be to change that statement to : " The behavior of all Attributes SHOULD follow [ DynLink ] . " Below is text to consider for the inclusion in the dynlink draft : " The " Minimum Evaluation Period " ( epmin ) and " Maximum Evaluation Period " ( epmax ) values can be used to configure the device to perform reporting evaluations . After the expiry of epmin , the device MAY immediately perform an evaluation per the " Notification Conditions " above . After the expiry of epmax , the device MUST perform an evaluation per the " Notification Conditions " . If both the epmin and epmax attributes are defined , the epmin must be less than the epmax . " These are the table entries from the LwM2 M Core Specification : Minimum Evaluation Period Readable Resource Notes : The Minimum Evaluation Period Attribute indicates the minimum time in seconds the LwM2 M Client MUST wait between two evaluations of reporting criteria . In the absence of this parameter , the Evaluation Minimum Period is not defined . Maximum Evaluation Period Resource Resource Instance Object Object Instance Readable Resource Notes : The Maximum Evaluation Period Attribute indicates the maximum time in seconds the LwM2 M Client MAY wait between two evaluations of reporting criteria . When the Maximum Evaluation Period expires after the previous evaluation , a new evaluation MUST occur . In the absence of this parameter , the Maximum Evaluation Period is not defined . 
 This seems like a good addition to the other conditional attributes we have . I do think some additional clarifications would be necessary . How should the CoAP endpoint ( an origin server , or the LWM2 M client ) handle an incoming Observe request which contains epmin / epmax query parameters , but does not have any other attributes present ? 
 These values only have context when other conditional attributes are present such that a measurement must take place and report potentially generated . If no report would ever be generated , then these parameters that guide when a measurement takes place provide no value . Would you like me to capture the above text somewhere ? How about in each table entry : " This value is ignored if other conditional attributes are not provided " . 
 I 'm not sure we should be " configuring the device " using query parameters on a GET / observe . But maybe the text above is not enough for me to understand what is being " configured " . 
 Checking the content on the , I am wondering if epmin / epmax make sense from REST pov . Query parameters are used to operate on the state of a resource and not to modify the internal mechanisms nor behaviour of the sensor . Thus evaluation periods would be out of the scope of what a query parameter should do IMO . I 'll copy this comment in the too if that 's OK . 
 I equate the definition of epmin / epmax to pmin / pmax as they control when a notification report is / can be generated and have noting to do directly with the behavior of the sensor . pmin / pmax have nothing to do with the state of a resource but only when that state is evaluated / reported . epmin / epmax is similar . 
 Do you perhaps have an example that shows the effects of epmin / epmax ? 
 In the dynlink call yesterday ,  showed an example of where the device wakes up every second to check the value of an observed resource . How does the device know to wake up every second to read that sensor ? That is how the epmin and epmax values are used . 
 I have created pull request to address this issue . I did not create an example as I was n't sure the format that we would wish that example represented . Let 's discuss during the interim meeting . 
 Here is text to consider for the example : As an example of the use of the Conditional Control Attributes , we will detail an observation using pmin , pmax , gt , epmin and epmax . In this use case , we have a temperature sensor that will send a notification whenever the temperature goes above or below 100 degrees ( gt100 ) . It can not report more often than every 5 seconds ( pmin=5 ) . It must report at least every 60 seconds ( pmax=60 ) . In order to control how frequently the server measures the temperature sensor , the client configures the server to avoid measuring it more frequently than 5 seconds ( epmin=5 ) , but the server must measure it at least every 10 seconds ( epmax=10 ) . After a notification is generated ( t=0 ) , the device waits 5 seconds before another notification can be sent due to pmin . After that 5 seconds expires ( t=5 ) , the server decides to perform a measurement of the temperature sensor . If the temperature has not changed from its previous state ( the temperature has remained above 100 or remained below 100 ) , no notification is generated . The server must wait another 5 seconds ( t=10 ) before doing another measurement of the temperature sensor due to the required expiry of the epmin . At that time ( t=10 ) , the server decides that it does not want to do a measurement of the temperature sensor ( an implementation specific decision ) . After an additional 5 seconds ( t=15 ) , the server MUST perform a measurement of the temperature sensor due the expiry of epmax . If the temperature has changed ( the temperature has gone above 100 or gone below 100 ) , a notification is generated . If not , the server returns to the measurement cadence defined by the epmin and epmax attributes . If 60 seconds goes by prior to a notification , a notification is generated because of pmax . 
 This has been accepted into the draft , so the issue can be closed .
This specification defines Link Bindings, which provide dynamic
linking of state updates between resources, either on an endpoint or
between endpoints, for systems using CoAP (RFC7252).  This
specification also defines Conditional Notification Attributes that
work with Link Bindings or with CoAP Observe (RFC7641).
This specification defines Link Bindings, which provide dynamic
linking of state updates between resources, either on an endpoint or
between endpoints, for systems using CoAP (RFC7252).  This
specification also defines Conditional Notification and Control
Attributes that work with Link Bindings or with CoAP Observe
(RFC7641).
This specification introduces the concept of a Link Binding, which
defines a new link relation type to create a dynamic link between
resources over which state updates are conveyed.  Specifically, a
Link Binding is a unidirectional link for binding the states of
source and destination resources together such that updates to one
are sent over the link to the other.  CoRE Link Format
representations are used to configure, inspect, and maintain Link
Bindings.  This specification additionally defines Conditional
Notification Attributes for use with Link Bindings and with CoRE
Observe RFC7641.
This specification introduces the concept of a Link Binding, which
defines a new link relation type to create a dynamic link between
resources over which state updates are conveyed.  Specifically, a
Link Binding is a unidirectional link for binding the states of
source and destination resources together such that updates to one
are sent over the link to the other.  CoRE Link Format
representations are used to configure, inspect, and maintain Link
Bindings.  This specification additionally defines Conditional
Notification and Control Attributes for use with Link Bindings and
with CoRE Observe RFC7641.
This specification defines Conditional Notification Attributes, which
provide for fine-grained control of notification and state
synchronization when using CoRE Observe RFC7641 or Link Bindings (see
bindings).  Conditional Notification Attributes define the conditions
that trigger a notification.
This specification defines Conditional Notification and Control
Attributes, which provide for fine-grained control of notification
and state synchronization when using CoRE Observe RFC7641 or Link
Bindings (see bindings).  Conditional Notification Attributes define
the conditions that trigger a notification.  Conditional Control
Attributes define the cadence of the measurement of the conditions
that trigger a notification.
When resource interfaces following this specification are made
available over CoAP, the CoAP Observation mechanism RFC7641 MAY also
be used to observe any changes in a resource, and receive
asynchronous notifications as a result.  A resource marked as
Observable in its link description SHOULD support these Conditional
Notification Attributes.
The set of parameters defined here allow a client to control how
often a client is interested in receiving notifications and how much
a resource value should change for the new representation to be
interesting.
Conditional Notification Attributes SHOULD be evaluated on all
potential notifications from a resource, whether resulting from an
internal server-driven sampling process or from external update
requests to the server.
When resource interfaces following this specification are made
available over CoAP, the CoAP Observation mechanism RFC7641 MAY also
be used to observe any changes in a resource, and receive
asynchronous notifications as a result.  A resource marked as
Observable in its link description SHOULD support these Conditional
Notification and Control Attributes.
The set of Notification Attributes defined here allow a client to
control how often a client is interested in receiving notifications
and how much a resource value should change for the new
representation to be interesting.  The set of Control Attributes
defined here allow a client to control how often the server performs
a measurement of the conditions.
One or more Control Attributes MAY be included as query parameters in
an Observe request.
Conditional Notification Attributes SHOULD be evaluated on all
potential notifications from a resource, whether resulting from an
internal server-driven sampling process or from external update
requests to the server.  Conditional Control Attributes are used to
configure the internal server-driven sampling process for performing
measurements of the conditions of a resource.
Pmin, pmax, st, gt, lt and band may be present in the same query.
Howver, they are not defined at multiple prioritization levels.  The
server sends a notification whenever any of the parameter conditions
are met, upon which it updates its last notification value and time
to prepare for the next notification.  Only one notification occurs
when there are multiple conditions being met at the same time.  The
reference code below illustrates the logic to determine when a
notification is to be sent.
When present, the minimum evaluation period indicates the minimum
time, in seconds, the client recommends to the server to wait between
two consecutive measurements of the conditions of a resource since
the client has no interest in the server doing more frequent
measurements.  When the minimum evaluation period expires after the
previous measurement, the server MAY immediately perform a new
measurement.  In the absence of this parameter, the minimum
evaluation period is not defined and thus not used by the server.
The server MAY use pmin, if defined, as a guidance on the desired
measurement cadence.  The minimum evaluation period MUST be greater
than zero otherwise the receiver MUST return a CoAP error code 4.00
"Bad Request" (or equivalent).
When present, the maximum evaluation period indicates the maximum
time, in seconds, the server MAY wait between two consecutive
measurements of the conditions of a resource.  When the maximum
evaluation period expires after the previous measurement, the server
MUST immediately perform a new measurement.  In the absence of this
parameter, the maximum evaluation period is not defined and thus not
used by the server.  The maximum evaluation period MUST be greater
than zero and MUST be greater than the minimum evaluation period
parameter (if present) otherwise the receiver MUST return a CoAP
error code 4.00 "Bad Request" (or equivalent).
Pmin, pmax, st, gt, lt and band may be present in the same query.
However, they are not defined at multiple prioritization levels.  The
server sends a notification whenever any of the parameter conditions
are met, upon which it updates its last notification value and time
to prepare for the next notification.  Only one notification occurs
when there are multiple conditions being met at the same time.  The
reference code below illustrates the logic to determine when a
notification is to be sent.
The use of the notification band minimum and maximum allow for a
synchronization whenever a change in the resource value occurs.
Theoretically this could occur in-line with the server internal
sample period or the configuration of epmin and epmax values for
determining the resource value.  Implementors SHOULD consider the
resolution needed before updating the resource, e.g. updating the
resource when a temperature sensor value changes by 0.001 degree
versus 1 degree.
When a server has multiple observations with different measurement
cadences as defined by the epmin and epmax values, the server MAY
evaluate all observations when performing the measurement of any one
observation.