Re: [core] WG Last Call on draft-ietf-core-conditional-attributes

[Klaus Hartke <[e-mail]>]

Hi all,

here is my review of draft-ietf-core-conditional-attributes-05.

The draft presents a protocol extension of "Observing Resources in
CoAP" [RFC7641].  RFC7641 is itself a protocol extension of CoAP
[RFC7252], which enables a CoAP client to retrieve the state of a
resource at a CoAP server (in the form of a resource state
representation) and to keep this retrieved state in sync with the
actual state at the server. The semantics of this mechanism are pretty
much the same as polling the source, but behaves more efficiently by
using a notification mechanism under the hood where the server chooses
the best strategy under the principle of eventual consistency ("If the
resource does not undergo a new change in state, eventually all
registered observers will have a current representation of the latest
resource state.")

According to itself, "Conditional Attributes for Constrained RESTful
Environments" [draft-ietf-core-conditional-attributes-05] aims to give
clients more fine-grained control over how the server generates
notifications. To make it short, this aim is fundamentally at odds
with how RFC7641 works: The notification mechanism in RFC7641 is a
protocol detail that operates under the hood to provide the
functionality of keeping the retrieved resource state in sync with
actual resource state. The Conditional Attributes defined by the draft
interfere with the generation of notifications, so that this
functionality is in its generality no longer given: The client no
longer receives a representation of the actual resource state through
the notifications.

I therefore believe that this draft should not become an RFC in its
current form.

However, I think that the draft actually just got the formulation of
its aim wrong. Rather than interfering with under what conditions and
in what way the server generates notifications, the draft should
define how the server updates resource state and how the client can
influence this.

A simple good way is resource state projection. For example, if the
state is a numeric value, it is possible to project a new state from
the resource state using e.g. the min or max function. This new state
can then be observed by the client. And the best way for the client to
let the server project the resource state in this way is to
parameterize the resource with a query string. A possible Conditional
Attribute could therefore be "max=X". This makes the observed resource
state the result of the calculation max(X,Y) where X is the query string
value and Y is the actual resource state.

Another way is that the server doesn't even change the state of the
resource unless certain condition(s) are met. For example, whenever
the server wants to change the state of a resource with a numeric
value, it compares the new value to the old one, and it skips changing
state if the difference doesn't exceed a threshold. This threshold
value can also be specified by a client using a query string. This
results in exactly the same behavior as some of the existing
attributes, just not in terms of sending notifications but changing
resource state!

Overall I think it would be straightforward to redefine almost all
attributes in one of these two ways. An exception is an attribute like
pmax, which makes a server send notifications that it wouldn't have to
send with RFC7641. Such a change in protocol cannot be achieved by
changing the way resource states are updated. Instead, the draft
should describe it for what it is: a protocol extension. And for
protocol extensions, we use options in CoAP.

Best regards,
Klaus