Subject: [core] draft-groves-core-dynlink-02

From: Michael Koster <[email-masked]>
Date: Sat, 25 Feb 2017 12:16:19 -0800

Hi Christian,

I have been thinking about the use case that we exposed in OCF recently, integrating pubsub and other cloud services into a system of existing server-based sensors.  Currently there is no well defined way to get a sensor device to push changes to a broker or to get an actuator device to subscribe to a topic on a broker. Likewise, there is on way to instruct the broker to observe a resource on a sensor, or to instruct a broker to update an actuator when a topic is published to on the broker.

A binding table, on the devices or on the broker, or both, is a good solution for this and enables the system-wide state update relationships to be maintained in a visible, manageable way.

I have a couple of comments on the current draft.

1. Why don't we use a resource type for the binding table? Its methods and responses conform to a generic link list interface, but the content and side effects are specialized to bindings. I thought we earlier had used rt=core.bnd as a resource type to identify the binding table.

2. We could make the example explicitly name the href of the sensor "switch" and the actuator "light" to help illustrate the directional pattern of observe the link target and update the link context:

   <coap://sensor.example.com/s/switch>;rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60"

3. I think we will need to register the new link attribute names with IANA: "pmin", "pmax", "lth", "gth", "stp", "bind"

4. Speaking of attributes, I don't think "bind" is strictly needed to identify whether to push or pull; that is implied by whether the anchor and href are local or remote. I can conceive of a case where the binding both observes and pushes:

   <coap://example.com/pubsub/switch>;rel="boundto";anchor="coap://example.com/pubsub/light";pmin="10";pmax="60"

We may instead want to identify what operations are used for both source (link target/href) and destination (link context/anchor), perhaps change it to the explicit: src=obs; dst=push with default being observe used on the source and update (push) used on the target. 

Best regards,

Michael

---

From: Christian Groves <[email-masked]>
Date: Mon, 27 Feb 2017 18:21:41 +1100

Hello Michael,

Thanks for the comments. Please see below.

Regards, Christian

On 26/02/2017 7:16 AM, Michael Koster wrote:
> Hi Christian,
>
> I have been thinking about the use case that we exposed in OCF 
> recently, integrating pubsub and other cloud services into a system of 
> existing server-based sensors. Currently there is no well defined way 
> to get a sensor device to push changes to a broker or to get an 
> actuator device to subscribe to a topic on a broker. Likewise, there 
> is on way to instruct the broker to observe a resource on a sensor, or 
> to instruct a broker to update an actuator when a topic is published 
> to on the broker.
>
> A binding table, on the devices or on the broker, or both, is a good 
> solution for this and enables the system-wide state update 
> relationships to be maintained in a visible, manageable way.
>
> 1. Why don't we use a resource type for the binding table? Its methods 
> and responses conform to a generic link list interface, but the 
> content and side effects are specialized to bindings. I thought we 
> earlier had used rt=core.bnd as a resource type to identify the 
> binding table.
[CNG] I had a look through all the previous drafts (including the Shelby 
ones) and didn't see any examples of rt=core.bnd . Core.bnd is only used 
in the context of a interface description. Can you recall where it may 
have been used?
However I can't see why we couldn't formally define a rt=core.bnd . The 
draft is pretty clear that a binding table is a resource.
>
> 2. We could make the example explicitly name the href of the sensor 
> "switch" and the actuator "light" to help illustrate the directional 
> pattern of observe the link target and update the link context:
>

[CNG] OK that makes sense.
> 3. I think we will need to register the new link attribute names with 
> IANA: "pmin", "pmax", "lth", "gth", "stp", "bind"
[CNG] I agree so that we avoid the problem of query parameter 
overloading. I think its part of a larger issue. E.g. 
sect.12.4/draft-ietf-core-resource-directory-09 proposes a new CoAP RD 
specific registry for query parameters. Should the query parameter 
registry be something specific or general for CoAP?

>
> 4. Speaking of attributes, I don't think "bind" is strictly needed to 
> identify whether to push or pull; that is implied by whether the 
> anchor and href are local or remote. I can conceive of a case where 
> the binding both observes and pushes:
>
> We may instead want to identify what operations are used for both 
> source (link target/href) and destination (link context/anchor), 
> perhaps change it to the explicit: src=obs; dst=push with default 
> being observe used on the source and update (push) used on the target.
[CNG] Would introducing two attributes instead make it more complicated? 
Effectively we're just representing what is expressed by a single code 
point into 2 code points. Couldn't you cover the above use case by 
having two table entries?

---

From: Michael Koster <[email-masked]>
Date: Mon, 27 Feb 2017 07:25:24 -0800

Hi,

Clarifications below.

Michael

> On Feb 26, 2017, at 11:21 PM, Christian Groves <[email-masked]> wrote:
> 
> Hello Michael,
> 
> [CNG] I had a look through all the previous drafts (including the Shelby ones) and didn't see any examples of rt=core.bnd . Core.bnd is only used in the context of a interface description. Can you recall where it may have been used?
> However I can't see why we couldn't formally define a rt=core.bnd . The draft is pretty clear that a binding table is a resource.

[MJK] Yes, I am proposing that the binding table use the core.ll interface, which is basically a collection resource that exposes core link-format. It can be identified as a binding table by using rt=core.bnd as a resource type, rather than a special interface type. I had intended to make this change when I made core.ll support create, update, and delete operations.

> [CNG] I agree so that we avoid the problem of query parameter overloading. I think its part of a larger issue. E.g. sect.12.4/draft-ietf-core-resource-directory-09 proposes a new CoAP RD specific registry for query parameters. Should the query parameter registry be something specific or general for CoAP?
> 
[MJK] If we want to avoid conflicts, there will need to be some coordination across the document-specific registries. Why not use the IANA CoRE Parameters Registry or some evolution thereof?
> [CNG] Would introducing two attributes instead make it more complicated? Effectively we're just representing what is expressed by a single code point into 2 code points. Couldn't you cover the above use case by having two table entries?
> 
[MJK] I think two attributes are necessary to support the case where both links point to resources under a different netloc, where there is no RESThook or other back channel access method to the resource. The source link will use polling or observe, and the destination link will use push. I also see a use case for defining, in the push binding, whether to use PUT or POST. 

[MJK] Even for the case where the source link is local, there is still a choice of polling vs. reacting to resource state changes. Periodic polling is often required to run some algorithms like PID controllers.

[MJK] I think it can be easily explained using a table listing the cases for local vs. remote and source vs. destination addresses and what the options are.

---

From: Michael Koster <[email-masked]>
Date: Mon, 27 Feb 2017 12:45:47 -0800

> On Feb 27, 2017, at 7:25 AM, Michael Koster <[email-masked]> wrote:
> 

I am proposing to add CRUD functionality to core.ll collections, as described in section 3.4 of CoRE Interfaces, and which is consistent with the current draft of CoRE Resource Directory, section 5.4 (attached) 

   Links in the collection MAY be Read, Updated, Added, or Removed using
   the CoRE Link-Format or JSON Merge-Patch Content-Formats on the
   collection resource.  Reading links uses the GET method and returns
   an array or list containing the link-values of all selected links.
   Links may be added to the collection using POST or PATCH methods.
   Updates to links MUST use the PATCH method and MAY use query
   filtering to select links for updating.  The PATCH method on links
   MUST use the JSON Merge-Patch Content-Format (application/merge-
   patch+json) specified in [RFC7396].
Currently, core.ll only has GET defined (Table 2), but IMO there is no reason not to add the full set of methods including PATCH. THe query parameter selects one or more links for updating, and the merge-patch document is applied to each selected link.

At one point we discussed putting this into a separate document that can be referenced from both RD and CoRE Interfaces, but it seems to belong more in interfaces, where collections are described.

Is there a place I could make a pull request to for a proposed update to Section 4.1 of the CoRE Interfaces document? I am in the middle of updating the description in CoRE RD and could do this relatively quickly.

Also have some proposed tweaks to align b and lb interface definitoins with OCF, but that is a separate proposal.

Best regards,

Michael

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 27 Feb 2017 22:12:49 +0100

On 27 Feb 2017, at 21:45, Michael Koster <[email-masked]> wrote:
> 
> The PATCH method on links

I’m not a big fan of requiring constrained nodes to do JSON.
(Time for Peter and me to finish the CBOR merge-patch…)

The way merge-patch and query parameters work together probably needs some explanation and some examples.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Mon, 27 Feb 2017 13:54:33 -0800

Yes, we MUST NOT require JSON... 

I will create some examples of query selection and merge-patch updates, and further explanation, as we will need it in RD anyway.

Best regards,

MIchael

> On Feb 27, 2017, at 1:12 PM, Carsten Bormann <[email-masked]> wrote:
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Feb 2017 10:59:05 +1100

Hello Michael,

Please see below.

Regards, Christian

> [MJK] Yes, I am proposing that the binding table use the core.ll interface, which is basically a collection resource that exposes core link-format. It can be identified as a binding table by using…
[CNG] OK I didn't realise that you wanted to remove the binding 
interface in favour of using the link list interface. I think its good 
to reuse than to create specialised interfaces. Is there anyone who 
would complain with this change?
> [MJK] If we want to avoid conflicts, there will need to be some coordination across the document-specific registries. Why not use the IANA CoRE Parameters Registry or some evolution thereof?
[CNG] Yes exactly. However do we need document specific registries? We 
could 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.

> [MJK] I think it can be easily explained using a table listing the cases for local vs. remote and source vs. destination addresses and what the options are.
[CNG] Maybe its best to draw up the table with the options first. I 
agree there's options for source and destination. What I was trying to 
say is that rather than having to parse two parameters it may be better 
to have one that has a value that is a "key" to a particular combination 
in the table.

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Feb 2017 11:21:29 +1100

Hello Michael,

The abstracts contains the link to the github repository:

Interfaces -> https://github.com/core-wg/interfaces

Dynlink -> https://github.com/core-wg/dynlink

The latest versions are up there now.

Regards, Christian

On 28/02/2017 7:45 AM, Michael Koster wrote:
>
>> On Feb 27, 2017, at 7:25 AM, Michael Koster 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> [MJK] Yes, I am proposing that the binding table use the core.ll 
>> interface, which is basically a collection resource that exposes core 
>> link-format. It can be identified as a binding table by using 
>> rt=core.bnd as a resource type, rather than a special interface type. 
>> I had intended to make this change when I made core.ll support 
>> create, update, and delete operations.
>
> I am proposing to add CRUD functionality to core.ll collections, as 
> described in section 3.4 of CoRE Interfaces, and which is consistent 
> with the current draft of CoRE Resource Directory, section 5.4 (attached)
>
> Currently, core.ll only has GET defined (Table 2), but IMO there is no 
> reason not to add the full set of methods including PATCH. THe query 
> parameter selects one or more links for updating, and the merge-patch 
> document is applied to each selected link.
>
> At one point we discussed putting this into a separate document that 
> can be referenced from both RD and CoRE Interfaces, but it seems to 
> belong more in interfaces, where collections are described.
>
> Is there a place I could make a pull request to for a proposed update 
> to Section 4.1 of the CoRE Interfaces document? I am in the middle of 
> updating the description in CoRE RD and could do this relatively quickly.
>
> Also have some proposed tweaks to align b and lb interface definitoins 
> with OCF, but that is a separate proposal.
>
> Best regards,
>
> Michael
>
>
>