Draft: draft-ietf-core-dynlink

Commentary: Updated for draft -13
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 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 Notification Attributes MAY be included as query
parameters in an Observe request.
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.
Note: In this draft, we assume that there are finite quantization
effects in the internal or external updates to the value of a
resource; specifically, that a resource may be updated at any time
with any valid value.  We therefore avoid any continuous-time
assumptions in the description of the Conditional Notification
Attributes and instead use the phrase "sampled value" to refer to a
member of a sequence of values that may be internally observed from
the resource state over time.
When present, the minimum period indicates the minimum time, in
seconds, between two consecutive notifications (whether or not the
resource value has changed).  In the absence of this parameter, the
minimum period is up to the server.  The minimum period MUST be
greater than zero otherwise the receiver MUST return a CoAP error
code 4.00 "Bad Request" (or equivalent).
A server MAY report the last sampled value that occured during the
pmin interval, after the pmin interval expires.
When present, the maximum period indicates the maximum time, in
seconds, between two consecutive notifications (whether or not the
resource value has changed).  In the absence of this parameter, the
maximum period is up to the server.  The maximum period MUST be
greater than zero and MUST be greater than, or equal to, the minimum
period parameter (if present) otherwise the receiver MUST return a
CoAP error code 4.00 "Bad Request" (or equivalent).
When present, the change step indicates how much the value of a
resource SHOULD change before triggering a notification, compared to
the value of the previous notification.  Upon reception of a query
including the st attribute, the most recently sampled value of the
resource is reported, and then set as the last reported value
(last_rep_v).  When a subsequent sample or update of the resource
value differs from the last reported value by an amount, positive or
negative, greater than or equal to st, and the time for pmin has
elapsed since the last notification, a notification is sent and the
last reported value is updated to the value sent in the notification.
The change step MUST be greater than zero otherwise the receiver MUST
return a CoAP error code 4.00 "Bad Request" (or equivalent).
The Change Step parameter can only be supported on resources with a
scalar numeric value.
Note: Due to sampling and other constraints, e.g. pmin, the resource
value received in two sequential notifications may differ by more
than st.
This specification defines conditional attributes, which provide for
fine-grained control of notification and state synchronization when
using CoRE Observe RFC7641 or Link Bindings (see bindings).  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 attributes.
Note: In this draft, we assume that there are finite quantization
effects in the internal or external updates to the value representing
the state of a resource; specifically, that a resource state may be
updated at any time with any valid value.  We therefore avoid any
continuous-time assumptions in the description of the conditional
attributes and instead use the phrase "sampled value" to refer to a
member of a sequence of values that may be internally observed from
the resource state over time.
Conditional Notification Attributes define the conditions that
trigger a notification.  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.
The set of Conditional Notification Attributes defined here allow a
client to control how often a client is interested in receiving
notifications and how much a value should change for the new
representation state to be interesting.  One or more Conditional
Notification Attributes MAY be included as query parameters in an
Observe request.
When present, Less Than indicates the lower limit value the resource
value SHOULD cross before triggering a notification.  A notification
is sent when the samples value crosses the specified lower limit
value, relative to the last reported value, and the time fpr pmin has
elapsed since the last notification.  The sampled value is sent in
the notification.  If the value continues to fall no notifications
are generated as a result of lt.  If the value rises above the lower
limit value then a new notification is sent, subject to the pmin
time..
The notification band attribute allows a bounded or unbounded (based
on a minimum or maximum) value range that may trigger multiple
notifications.  This enables use cases where different ranges results
in differing behaviour.  For example: monitoring the temperature of
machinery.  Whilst the temperature is in the normal operating range
only periodic observations are needed.  However as the temperature
moves to more abnormal ranges more frequent synchronization/reporting
may be needed.
When present, Less Than indicates the lower limit value the resource
value SHOULD cross before triggering a notification.  A notification
is sent when the samples value crosses the specified lower limit
value, relative to the last reported value, and the time fpr pmin has
elapsed since the last notification.  The sampled value is sent in
the notification.  If the value continues to fall no notifications
are generated as a result of lt.  If the value rises above the lower
limit value then a new notification is sent, subject to the pmin
time.
When present, the change step indicates how much the value
representing a resource state SHOULD change before triggering a
notification, compared to the old state.  Upon reception of a query
including the st attribute, the current resource state representing
the most recently sampled value is reported, and then set as the last
reported value (last_rep_v).  When a subsequent sampled value or
update of the resource state differs from the last reported state by
an amount, positive or negative, greater than or equal to st, and the
time for pmin has elapsed since the last notification, a notification
is sent and the last reported value is updated to the new resource
state sent in the notification.  The change step MUST be greater than
zero otherwise the receiver MUST return a CoAP error code 4.00 "Bad
Request" (or equivalent).
The Change Step parameter can only be supported on resource states
represented with a scalar numeric value.
Note: Due to sampling and other constraints, e.g. pmin, the change in
resource states received in two sequential notifications may differ
by more than st.
The notification band attribute allows a bounded or unbounded (based
on a minimum or maximum) value range that may trigger multiple
notifications.  This enables use cases where different ranges results
in differing behaviour.  For example, in monitoring the temperature
of machinery, whilst the temperature is in the normal operating
range, only periodic updates are needed.  However as the temperature
moves to more abnormal ranges more frequent state updates may be sent
to clients.
When present, the Edge attribute indicates interest for receiving
notifications of either the falling edge or the rising edge
transition of a boolean resource state.  When the value of the Edge
attribute is 0, the server notifies the client each time a resource
state changes from True to False.  When the value of the Edge
attribute is 1, the server notifies the client each time a resource
state changes from False to True.
The Edge attribute can only be supported on resources with a boolean
value.
Conditional Control Attributes define the time intervals between
consecutive notifications as well as the cadence of the measurement
of the conditions that trigger a notification.  Conditional Control
Attributes can be used to configure the internal server-driven
sampling process for performing measurements of the conditions of a
resource.  One or more Conditional Control Attributes MAY be included
as query parameters in an Observe request.
When present, the minimum period indicates the minimum time, in
seconds, between two consecutive notifications (whether or not the
resource state has changed).  In the absence of this parameter, the
minimum period is up to the server.  The minimum period MUST be
greater than zero otherwise the receiver MUST return a CoAP error
code 4.00 "Bad Request" (or equivalent).
A server MAY update the resource state with the last sampled value
that occured during the pmin interval, after the pmin interval
expires.
When present, the maximum period indicates the maximum time, in
seconds, between two consecutive notifications (whether or not the
resource state has changed).  In the absence of this parameter, the
maximum period is up to the server.  The maximum period MUST be
greater than zero and MUST be greater than, or equal to, the minimum
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.
When present with a value of 1 in a query, the con attribute
indicates a notification MUST be confirmable, i.e., the server MUST
send the notification in a confirmable CoAP message, to request an
acknowledgement from the client.  When present with a value of 0 in a
query, the con attribute indicates a notification can be confirmable
or non-confirmable, i.e., it can be sent in a confirmable or a non-
confirmable CoAP message.
Conditional Notification Attributes and Conditional Control
Attributes 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.
When pmax and pmin are equal, the expected behaviour is that
notifications will be sent every (pmin == pmax) seconds.  However,
these notifications can only be fulfilled by the server on a best
effort basis.  Because pmin and pmax are designed as acceptable
tolerance bounds for sending state updates, a query from an
interested client containing equal pmin and pmax values must not be
seen as a hard real-time scheduling contract between the client and
the server.