Discussion:
[core] I-D Action: draft-ietf-core-resource-directory-12.txt
i***@ietf.org
2017-10-30 18:31:48 UTC
Permalink
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/
Christian Amsüss
2017-10-31 09:32:40 UTC
Permalink
Hello CoRE working group,
Post by i***@ietf.org
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:***@energyharvesting.at | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39 | http://www.energyharvesting.at/
| ATU68476614
Loading...