Subject: [core] draft-ietf-core-dynlink -- New Use Case

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 3 Jan 2017 20:52:43 +0100

Hi Christian, Hi all,

Friedhelm and I had recently been wondering about the following use case
and whether others in the group also see it as worthwhile to include in
the core-dynlink draft.

Here is the story:

core-dynlink describes attributes to reduce the amount of notifications
that are sent to an observer. The approach is quite simple: The observer
expresses interest in a resource and conveys the attributes, such as
pmin, pmax, to rate limit notifications.

When the resource changes then the subject, as RFC 7641 calls it, sends
the current value of the resource.

This is very useful functionality.

However, imagine that you want to obtain data about many different
resources and you utilize a data model (like in LWM2M) where resources
are organized in a hierarchical fashion. For example, you may want to
obtain a set of resources if the value of one of the resources changes.

To be more specific, imagine a system that convey data during an alarms
in an industrial facility: once a high temperature alarm is triggered
the system will most likely want a snapshot of the system state (to
quickly perform an analysis).

What do you think?

Ciao
Hannes

---

From: Christian Groves <[email-masked]>
Date: Sat, 7 Jan 2017 00:27:23 +1100

Hello Hannes,

I've been thinking about a similar use case whilst updating dynlink, so 
I'd agree with you that such functionality would be a worthwhile 
addition to dynlink.

The question is which method would be the appropriate way to implement 
such functionality?

A possible way to do this would be to use a linked batch (or batch) 
interface (cl.4.3/draft-ietf-core-interfaces). The client would 
construct a resource using the linked batch interface for the 
information/resources that it requires. A GET on the collection would 
return all the information.

However the current text of draft-ietf-core-interfaces indicates that 
observe may be supported on an item in a collection not on the 
collection itself. To get around this we could introduce an "item" query 
attribute that is only used on collection (e.g. batch, linked-batch) 
resources  which enables the use of the parameters from dynlink on a 
collection. The "item" attribute points to one item in the collection.

e.g.  given the links:
    Req: GET /.well-known/core
    Res: 2.05 Content (application/link-format)
    </s/>;rt="simple.sen";if="core.b",
    </s/lt>;rt="simple.sen.lt";if="core.s",
    </s/temp>;rt="simple.sen.tmp";if="core.s";obs,
    </s/humidity>;rt="simple.sen.hum";if="core.s",

A Req: GET /s?item=tmp&gt=37
            Token: 0x4a
            Observe: 0
would produce the following when temp exceeds 37:
    Res: 2.05 Content (application/senml+json)
    {"e":[
       { "n": "/s/light", "v": 123, "u": "lx" },
       { "n": "/s/temp", "v": 38, "u": "degC" },
       { "n": "/s/humidity", "v": 80, "u": "%RH" }],
    }

For me this seems like the easiest approach as the observation 
attributes are kept together and doing a GET on the collection seems 
logically right because you want all the information of the collection 
resource.  However there might be other methods?

Regards, Christian

On 4/01/2017 6:52 AM, Hannes Tschofenig wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core