Subject: [core] I-D Action: draft-ietf-core-resource-directory-12.txt

From: [email-masked]
Date: Mon, 30 Oct 2017 11:31:48 -0700

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.

        Title           : CoRE Resource Directory
        Authors         : Zach Shelby
                          Michael Koster
                          Carsten Bormann
                          Peter van der Stok
                          Christian Amsüss
	Filename        : draft-ietf-core-resource-directory-12.txt
	Pages           : 64
	Date            : 2017-10-30

Abstract:
   In many M2M applications, direct discovery of resources is not
   practical due to sleeping nodes, disperse networks, or networks where
   multicast traffic is inefficient.  These problems can be solved by
   employing an entity called a Resource Directory (RD), which hosts
   descriptions of resources held on other servers, allowing lookups to
   be performed for those resources.  This document specifies the web
   interfaces that a Resource Directory supports in order for web
   servers to discover the RD and to register, maintain, lookup and
   remove resource descriptions.  Furthermore, new link attributes
   useful in conjunction with an RD are defined.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-resource-directory-12
https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-resource-directory-12

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 31 Oct 2017 10:32:40 +0100

Hello CoRE working group,

> 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:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614