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

[Michael Koster <[e-mail]>]

Hi,

Clarifications below.

Michael

> On Feb 26, 2017, at 11:21 PM, Christian Groves <[e-mail]> wrote:
> 
> 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.
>> 
>> 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.
> [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.

>> 
>> 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"
> 
> [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?
> 
[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?
>> 
>> 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.
> [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.