[core] resource-directory-12: Request for reviews, annotated Change Log

Christian Amsüss <c.amsuess@energyharvesting.at> Tue, 31 October 2017 09:32 UTC

Return-Path: <c.amsuess@energyharvesting.at>
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 A3A4613F6FB; Tue, 31 Oct 2017 02:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 55a64X3HCi_3; Tue, 31 Oct 2017 02:32:50 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ED01395F0; Tue, 31 Oct 2017 02:32:49 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7C7D54830E; Tue, 31 Oct 2017 10:32:45 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [10.13.13.231]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 80A462A; Tue, 31 Oct 2017 10:32:41 +0100 (CET)
Received: from hephaistos.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6286657; Tue, 31 Oct 2017 10:32:41 +0100 (CET)
Received: (nullmailer pid 12829 invoked by uid 1000); Tue, 31 Oct 2017 09:32:40 -0000
Date: Tue, 31 Oct 2017 10:32:40 +0100
From: Christian Amsüss <c.amsuess@energyharvesting.at>
To: core@ietf.org
Cc: draft-ietf-core-resource-directory@ietf.org
Message-ID: <20171031093240.wfwdhs7dwkfofheh@hephaistos.amsuess.com>
References: <150938830831.7809.14214960601515419982@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7rqtqwgn2fqpj2c3"
Content-Disposition: inline
In-Reply-To: <150938830831.7809.14214960601515419982@ietfa.amsl.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/7iTDNIm4f-x7JUzv_Jxp0SkcED4>
Subject: [core] resource-directory-12: Request for reviews, annotated Change Log
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 31 Oct 2017 09:32:58 -0000

Hello CoRE working group,

On Mon, Oct 30, 2017 at 11:31:48AM -0700, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Constrained RESTful Environments WG of the IETF.

With the document nearing completion, the authors would like to ask the
working group for reviews on the submitted draft.


Even though the document contains a change log, some changes were big
enough to deserve some more explanation, so we'd like to provide the WG
with some further notes and examples with the changelog entries:

----

   o  clarified where relative references are resolved, and how context
      and anchor interact

   o  new appendix on the interaction with RFCs 6690, 5988 and 3986

In particular, we now preserve the full resolved statements from Link
Format documents submitted to the RD, including the context and link
relations. This means that at resource lookup, clients need to be able
to understand the anchor= attribute.

Key example:

| Req: GET /rd-lookup/res?rt=temperature
|
| Res: 2.05 Content
| </sensors/temp>;rt="temperature";if="sensor";anchor="coap://[2001:db8::123]"

Example of a more complex original statement:

| Req: GET /rd-lookup/res?rel=describedby
|
| Res: 2.05 Content
| <http://example.com/temp-info.html>;rel="describedby";anchor="coap://[2001:db8::123]/sensors/temp"

----

   o  lookup interface: group and endpoint lookup return group and
      registration resources as link targets

This removes the need for a dedicated "list all groups/endpoints"
interface on the registration side.

Key example:

| Req: GET /rd-lookup/ep?et=power-node
|
| Res: 2.05 Content
| </rd/1234>;con="coap://[2001:db8::127]";ep="node5";et="power-node";ct="40";lt="600",
| </rd/4521>;con="coap://[2001:db8::129]";ep="node7";et="power-node";ct="40";lt="600";d="floor-3"

Note that as with all URIs in the RD, none of the concrete paths is
prescribed. Were a different implementation used, the same example could
be:

| Req: GET /~resdir/ep-lookup?et=power-node
|
| Res: 2.05 Content
| </~resdir/+reg/node5>;con="coap://[2001:db8::127]";ep="node5";et="power-node";lt="600",
| </~resdir/+reg/floor-3/node7>;con="coap://[2001:db8::129]";ep="node7";et="power-node";lt="600";d="floor-3"

This also allows an unambiguous syntax for putting registered endpoints
into groups:

| Req: POST /rd-group?gp=lights&con=coap://[ff35:30:2001:db8::1]
| Payload:
| </rd/1234>,</rd/4521>
|
| Res: 2.01 Created
| Location: /rd-group/12

----

   o  updated chapter "Finding a Resource Directory"; now distinguishes
      configuration-provided, network-provided and heuristic sources

Endpoints can be pre-configured to use a particular way to find their
RD, be it per IP uni-, multi- or anycast, DNS name or DNS-SD service.

Endpoints without explicit configuration look for an RD location that
comes with the network (eg. from SLAAC); in absence thereof, heuristics
for finding an RD are described (multicast discovery, ask the 6LBR).

----

Further changes:

   o  added Content Model section, including ER diagram

   o  removed domain lookup interface; domains are now plain attributes
      of groups and endpoints

   o  improved text on: atomicity, idempotency, lookup with multiple
      parameters, endpoint removal, simple registration

   o  updated LWM2M description

   o  lookup interface: search parameters work the same across all
      entities

   o  removed all methods that modify links in an existing registration
      (POST with payload, PATCH and iPATCH)

   o  removed plurality definition (was only needed for link
      modification)

   o  enhanced IANA registry text
   
   o  state that lookup resources can be observable

   o  More examples and improved text


Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:c.amsuess@energyharvesting.at  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614