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

Christian Groves <cngroves.std@gmail.com> Mon, 27 February 2017 23:59 UTC

Return-Path: <cngroves.std@gmail.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B029127077 for <core@ietfa.amsl.com>; Mon, 27 Feb 2017 15:59:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svSQs-HV58R8 for <core@ietfa.amsl.com>; Mon, 27 Feb 2017 15:59:12 -0800 (PST)
Received: from msh04.myshophosting.com (msh04.myshophosting.com [101.0.86.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C993126DFB for <core@ietf.org>; Mon, 27 Feb 2017 15:59:12 -0800 (PST)
Received: from ppp118-209-135-224.lns20.mel8.internode.on.net ([118.209.135.224]:52112 helo=[192.168.1.22]) by msh04.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <cngroves.std@gmail.com>) id 1ciVC8-003xKe-Pc; Tue, 28 Feb 2017 10:59:08 +1100
To: Michael Koster <michaeljohnkoster@gmail.com>
References: <AAC41ACC-476B-4D5E-83C1-1D76D45ACF70@gmail.com> <0d67976c-c566-ae89-cdcc-ed0828abe3d6@gmail.com> <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com>
From: Christian Groves <cngroves.std@gmail.com>
Message-ID: <44c1dca2-b7ce-3056-d8fb-a6e01a5c7823@gmail.com>
Date: Tue, 28 Feb 2017 10:59:05 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <58FEF934-CB65-4229-919F-508DE261EA1D@gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh04.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - gmail.com
X-Get-Message-Sender-Via: msh04.myshophosting.com: authenticated_id: christian@kunstmade.com.au
X-Authenticated-Sender: msh04.myshophosting.com: christian@kunstmade.com.au
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/geX9VC7ExICka4QXC9uxBUCPiPA>
Cc: "core@ietf.org WG" <core@ietf.org>
Subject: Re: [core] draft-groves-core-dynlink-02
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Feb 2017 23:59:14 -0000

Hello Michael,

Please see below.

Regards, Christian


On 28/02/2017 2:25 AM, Michael Koster wrote:
> Hi,
>
> Clarifications below.
>
> Michael
>
>> On Feb 26, 2017, at 11:21 PM, Christian Groves <cngroves.std@gmail.com> 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.
[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?
>
>>> 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?
[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.

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