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

[Christian Groves <[e-mail]>]

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

>
> 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?

>
> Best regards,
>
> Michael