draft-ietf-core-resource-directory-18.txt   draft-ietf-core-resource-directory-19.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft ARM Internet-Draft ARM
Intended status: Standards Track M. Koster Intended status: Standards Track M. Koster
Expires: June 23, 2019 SmartThings Expires: July 15, 2019 SmartThings
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
P. van der Stok P. van der Stok
consultant consultant
C. Amsuess, Ed. C. Amsuess, Ed.
December 20, 2018 January 11, 2019
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-18 draft-ietf-core-resource-directory-19
Abstract Abstract
In many M2M applications, direct discovery of resources is not In many M2M applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which contains employing an entity called a Resource Directory (RD), which contains
information about resources held on other servers, allowing lookups information about resources held on other servers, allowing lookups
to be performed for those resources. The input to an RD is composed to be performed for those resources. The input to an RD is composed
of links and the output is composed of links constructed from the of links and the output is composed of links constructed from the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 23, 2019. This Internet-Draft will expire on July 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6
3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7
3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8 3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8
3.4. Link-local addresses . . . . . . . . . . . . . . . . . . 12 3.4. Link-local addresses and zone identifiers . . . . . . . . 12
3.5. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12 3.5. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12
3.6. Use Case: Home and Building Automation . . . . . . . . . 13 3.6. Use Case: Home and Building Automation . . . . . . . . . 13
3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 13 3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 13
4. Finding a Resource Directory . . . . . . . . . . . . . . . . 14 4. Finding a Resource Directory . . . . . . . . . . . . . . . . 14
4.1. Resource Directory Address Option (RDAO) . . . . . . . . 16 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 16
5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 17 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 17
5.1. Payload Content Formats . . . . . . . . . . . . . . . . . 18 5.1. Payload Content Formats . . . . . . . . . . . . . . . . . 18
5.2. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 18 5.2. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Registration . . . . . . . . . . . . . . . . . . . . . . 21 5.3. Registration . . . . . . . . . . . . . . . . . . . . . . 21
5.3.1. Simple Registration . . . . . . . . . . . . . . . . . 25 5.3.1. Simple Registration . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 10 skipping to change at page 3, line 10
7. Security policies . . . . . . . . . . . . . . . . . . . . . . 40 7. Security policies . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Secure RD discovery . . . . . . . . . . . . . . . . . . . 41 7.1. Secure RD discovery . . . . . . . . . . . . . . . . . . . 41
7.2. Secure RD filtering . . . . . . . . . . . . . . . . . . . 41 7.2. Secure RD filtering . . . . . . . . . . . . . . . . . . . 41
7.3. Secure endpoint Name assignment . . . . . . . . . . . . . 42 7.3. Secure endpoint Name assignment . . . . . . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8.1. Endpoint Identification and Authentication . . . . . . . 42 8.1. Endpoint Identification and Authentication . . . . . . . 42
8.2. Access Control . . . . . . . . . . . . . . . . . . . . . 43 8.2. Access Control . . . . . . . . . . . . . . . . . . . . . 43
8.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 43 8.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 43
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 43 9.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 44
9.2. IPv6 ND Resource Directory Address Option . . . . . . . . 44 9.2. IPv6 ND Resource Directory Address Option . . . . . . . . 44
9.3. RD Parameter Registry . . . . . . . . . . . . . . . . . . 44 9.3. RD Parameter Registry . . . . . . . . . . . . . . . . . . 44
9.3.1. Full description of the "Endpoint Type" Registration 9.3.1. Full description of the "Endpoint Type" Registration
Parameter . . . . . . . . . . . . . . . . . . . . . . 46 Parameter . . . . . . . . . . . . . . . . . . . . . . 46
9.4. "Endpoint Type" (et=) RD Parameter values . . . . . . . . 46 9.4. "Endpoint Type" (et=) RD Parameter values . . . . . . . . 46
9.5. Multicast Address Registration . . . . . . . . . . . . . 47 9.5. Multicast Address Registration . . . . . . . . . . . . . 47
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Lighting Installation . . . . . . . . . . . . . . . . . 47 10.1. Lighting Installation . . . . . . . . . . . . . . . . . 47
10.1.1. Installation Characteristics . . . . . . . . . . . . 47 10.1.1. Installation Characteristics . . . . . . . . . . . . 48
10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 49 10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 49
10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 51 10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 51
10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52 10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52
10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 53 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 53
10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55
10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 55 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 55
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 55 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 55
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 64
13.1. Normative References . . . . . . . . . . . . . . . . . . 63 13.1. Normative References . . . . . . . . . . . . . . . . . . 64
13.2. Informative References . . . . . . . . . . . . . . . . . 64 13.2. Informative References . . . . . . . . . . . . . . . . . 64
Appendix A. Groups Registration and Lookup . . . . . . . . . . . 66 Appendix A. Groups Registration and Lookup . . . . . . . . . . . 66
Appendix B. Web links and the Resource Directory . . . . . . . . 68 Appendix B. Web links and the Resource Directory . . . . . . . . 67
B.1. A simple example . . . . . . . . . . . . . . . . . . . . 68 B.1. A simple example . . . . . . . . . . . . . . . . . . . . 68
B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 68 B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 68
B.1.2. Interpreting attributes and relations . . . . . . . . 69 B.1.2. Interpreting attributes and relations . . . . . . . . 68
B.2. A slightly more complex example . . . . . . . . . . . . . 69 B.2. A slightly more complex example . . . . . . . . . . . . . 69
B.3. Enter the Resource Directory . . . . . . . . . . . . . . 70 B.3. Enter the Resource Directory . . . . . . . . . . . . . . 69
B.4. A note on differences between link-format and Link B.4. A note on differences between link-format and Link
headers . . . . . . . . . . . . . . . . . . . . . . . . . 71 headers . . . . . . . . . . . . . . . . . . . . . . . . . 71
Appendix C. Limited Link Format . . . . . . . . . . . . . . . . 72 Appendix C. Limited Link Format . . . . . . . . . . . . . . . . 72
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
1. Introduction 1. Introduction
The work on Constrained RESTful Environments (CoRE) aims at realizing The work on Constrained RESTful Environments (CoRE) aims at realizing
the REST architecture in a suitable form for the most constrained the REST architecture in a suitable form for the most constrained
nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and
skipping to change at page 12, line 29 skipping to change at page 12, line 29
o optional additional endpoint attributes (from Section 9.3) o optional additional endpoint attributes (from Section 9.3)
The cardinality of "base" is currently 1; future documents are The cardinality of "base" is currently 1; future documents are
invited to extend the RD specification to support multiple values invited to extend the RD specification to support multiple values
(e.g. [I-D.silverajan-core-coap-protocol-negotiation]). Its value (e.g. [I-D.silverajan-core-coap-protocol-negotiation]). Its value
is used as a Base URI when resolving URIs in the links contained in is used as a Base URI when resolving URIs in the links contained in
the endpoint. the endpoint.
Links are modelled as they are in Figure 2. Links are modelled as they are in Figure 2.
3.4. Link-local addresses 3.4. Link-local addresses and zone identifiers
Registration requests to the RD may arrive from link-local IP Registration Base URIs can contain link-local IP addresses. To be
addresses. When building a Registration Base URI from that source IP usable across hosts, those can not be serialized to contain zone
address (which would become part of the resolved URIs in resource identifiers (see [RFC6874] Section 1).
lookup), its link-local IP literal typically contains a zone
identifier of the RD, and is not usable across hosts (see [RFC6874]
Section 1).
Therefore, RD servers SHOULD reject registrations which use of URIs Link-local addresses can only be used on a single link (therefore RD
containing link-local IP addresses. servers can not announce them when queried on a different link), and
lookup clients using them need to keep track of which interface they
got them from.
Therefore, it is advisable in many scenarios to use addresses with
larger scope if available.
3.5. Use Case: Cellular M2M 3.5. Use Case: Cellular M2M
Over the last few years, mobile operators around the world have Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the focused on development of M2M solutions in order to expand the
business to the new type of users: machines. The machines are business to the new type of users: machines. The machines are
connected directly to a mobile network using an appropriate embedded connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing
short and wide range wireless interfaces. From the system design short and wide range wireless interfaces. From the system design
point of view, the ambition is to design horizontal solutions that point of view, the ambition is to design horizontal solutions that
skipping to change at page 15, line 39 skipping to change at page 15, line 41
resource directory (using the ABRO option to find that resource directory (using the ABRO option to find that
[RFC6775]). Confirmation can be obtained by sending a Unicast to [RFC6775]). Confirmation can be obtained by sending a Unicast to
"coap://[6LBR]/.well-known/core?rt=core.rd*". "coap://[6LBR]/.well-known/core?rt=core.rd*".
2. In a network that supports multicast well, discovering the RD 2. In a network that supports multicast well, discovering the RD
using a multicast query for /.well-known/core as specified in using a multicast query for /.well-known/core as specified in
CoRE Link Format [RFC6690]: Sending a Multicast GET to CoRE Link Format [RFC6690]: Sending a Multicast GET to
"coap://[MCD1]/.well-known/core?rt=core.rd*". RDs within the "coap://[MCD1]/.well-known/core?rt=core.rd*". RDs within the
multicast scope will answer the query. multicast scope will answer the query.
When answering a link-local multicast request, the RD SHOULD NOT When answering a multicast request directed at a link-local address,
respond with their link-local addresses but use a routable one; the RD may want to respond from a routable address; this makes it
otherwise the registrant-ep would later need to pick an explicit base easier for registrants to use one of their own routable addresses for
address to avoid the issue of Section 3.4. registration.
As some of the RD addresses obtained by the methods listed here are As some of the RD addresses obtained by the methods listed here are
just (more or less educated) guesses, endpoints MUST make use of any just (more or less educated) guesses, endpoints MUST make use of any
error messages to very strictly rate-limit requests to candidate IP error messages to very strictly rate-limit requests to candidate IP
addresses that don't work out. For example, an ICMP Destination addresses that don't work out. For example, an ICMP Destination
Unreachable message (and, in particular, the port unreachable code Unreachable message (and, in particular, the port unreachable code
for this message) may indicate the lack of a CoAP server on the for this message) may indicate the lack of a CoAP server on the
candidate host, or a CoAP error response code such as 4.05 "Method candidate host, or a CoAP error response code such as 4.05 "Method
Not Allowed" may indicate unwillingness of a CoAP server to act as a Not Allowed" may indicate unwillingness of a CoAP server to act as a
directory server. directory server.
skipping to change at page 16, line 15 skipping to change at page 16, line 18
If multiple candidate addresses are discovered, the device may pick If multiple candidate addresses are discovered, the device may pick
any of them initially, unless the discovery method indicates a more any of them initially, unless the discovery method indicates a more
precise selection scheme. precise selection scheme.
4.1. Resource Directory Address Option (RDAO) 4.1. Resource Directory Address Option (RDAO)
The Resource Directory Address Option (RDAO) using IPv6 Neighbor The Resource Directory Address Option (RDAO) using IPv6 Neighbor
Discovery (ND) carries information about the address of the Resource Discovery (ND) carries information about the address of the Resource
Directory (RD). This information is needed when endpoints cannot Directory (RD). This information is needed when endpoints cannot
discover the Resource Directory with a link-local or realm-local discover the Resource Directory with a link-local or realm-local
scope multicast address because the endpoint and the RD are separated scope multicast address, for instance because the endpoint and the RD
by a Border Router (6LBR). In many circumstances the availability of are separated by a Border Router (6LBR). In many circumstances the
DHCP cannot be guaranteed either during commissioning of the network. availability of DHCP cannot be guaranteed either during commissioning
The presence and the use of the RD is essential during commissioning. of the network. The presence and the use of the RD is essential
during commissioning.
It is possible to send multiple RDAO options in one message, It is possible to send multiple RDAO options in one message,
indicating as many resource directory addresses. indicating as many resource directory addresses.
The RDAO format is: The RDAO format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 3 | Valid Lifetime | | Type | Length = 3 | Valid Lifetime |
skipping to change at page 23, line 40 skipping to change at page 23, line 40
it MUST include the base parameter in the registration to it MUST include the base parameter in the registration to
provide a valid network path. provide a valid network path.
If the registrant-ep, located behind a NAT gateway, is If the registrant-ep, located behind a NAT gateway, is
registering with a Resource Directory which is on the network registering with a Resource Directory which is on the network
service side of the NAT gateway, the endpoint MUST use a service side of the NAT gateway, the endpoint MUST use a
persistent port for the outgoing registration in order to persistent port for the outgoing registration in order to
provide the NAT gateway with a valid network address for provide the NAT gateway with a valid network address for
replies and incoming requests. replies and incoming requests.
If the registrant-ep uses a link-local address to register, it If the Base URI contains a link-local IP literal, it MUST NOT
MUST give an explicit routable base address unless configured contain a Zone Identifier, and MUST be local to the link on
otherwise as per Section 3.4 (or just register from that which the registration request is received.
address in the first place).
Endpoints that register with a base that contains a path Endpoints that register with a base that contains a path
component can not meaningfully use [RFC6690] Link Format due to component can not meaningfully use [RFC6690] Link Format due to
its prevalence of the Origin concept in relative reference its prevalence of the Origin concept in relative reference
resolution. Those applications should use different resolution. Those applications should use different
representations of links to which Appendix C is not applicable representations of links to which Appendix C is not applicable
(e.g. [I-D.hartke-t2trg-coral]). (e.g. [I-D.hartke-t2trg-coral]).
extra-attrs := Additional registration attributes (optional). extra-attrs := Additional registration attributes (optional).
The endpoint can pass any parameter registered at Section 9.3 The endpoint can pass any parameter registered at Section 9.3
skipping to change at page 29, line 25 skipping to change at page 29, line 25
These operations are described below. These operations are described below.
5.4.1. Registration Update 5.4.1. Registration Update
The update interface is used by the registering endpoint to refresh The update interface is used by the registering endpoint to refresh
or update its registration with an RD. To use the interface, the or update its registration with an RD. To use the interface, the
registering endpoint sends a POST request to the registration registering endpoint sends a POST request to the registration
resource returned by the initial registration operation. resource returned by the initial registration operation.
An update MAY update the lifetime- or the context- registration An update MAY update the lifetime or the base URI registration
parameters "lt", "base" as in Section 5.3. Parameters that are not parameters "lt", "base" as in Section 5.3. Parameters that are not
being changed SHOULD NOT be included in an update. Adding parameters being changed SHOULD NOT be included in an update. Adding parameters
that have not changed increases the size of the message but does not that have not changed increases the size of the message but does not
have any other implications. Parameters MUST be included as query have any other implications. Parameters MUST be included as query
parameters in an update operation as in Section 5.3. parameters in an update operation as in Section 5.3.
A registration update resets the timeout of the registration to the A registration update resets the timeout of the registration to the
(possibly updated) lifetime of the registration, independent of (possibly updated) lifetime of the registration, independent of
whether a "lt" parameter was given. whether a "lt" parameter was given.
If the context of the registration is changed in an update, relative If the base URI of the registration is changed in an update, relative
references submitted in the original registration or later updates references submitted in the original registration or later updates
are resolved anew against the new context. are resolved anew against the new base.
The registration update operation only describes the use of POST with The registration update operation only describes the use of POST with
an empty payload. Future standards might describe the semantics of an empty payload. Future standards might describe the semantics of
using content formats and payloads with the POST method to update the using content formats and payloads with the POST method to update the
links of a registration (see Section 5.4.3). links of a registration (see Section 5.4.3).
The update registration request interface is specified as follows: The update registration request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
skipping to change at page 34, line 23 skipping to change at page 34, line 23
with the base URI of the registration as the anchor. Links of which with the base URI of the registration as the anchor. Links of which
href or anchor was submitted as a (full) URI are returned with these href or anchor was submitted as a (full) URI are returned with these
attributes unmodified. attributes unmodified.
Above rules allow the client to interpret the response as links Above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD. without any further knowledge of the storage conventions of the RD.
The Resource Directory MAY replace the registration base URIs with a The Resource Directory MAY replace the registration base URIs with a
configured intermediate proxy, e.g. in the case of an HTTP lookup configured intermediate proxy, e.g. in the case of an HTTP lookup
interface for CoAP endpoints. interface for CoAP endpoints.
If the base URI of a registration contains a link-local address, the
RD MUST NOT show its links unless the lookup was made from the same
link. The RD MUST NOT include zone identifiers in the resolved URIs.
6.2. Lookup filtering 6.2. Lookup filtering
Using the Accept Option, the requester can control whether the Using the Accept Option, the requester can control whether the
returned list is returned in CoRE Link Format ("application/link- returned list is returned in CoRE Link Format ("application/link-
format", default) or in alternate content-formats (e.g. from format", default) or in alternate content-formats (e.g. from
[I-D.ietf-core-links-json]). [I-D.ietf-core-links-json]).
The page and count parameters are used to obtain lookup results in The page and count parameters are used to obtain lookup results in
specified increments using pagination, where count specifies how many specified increments using pagination, where count specifies how many
links to return and page specifies which subset of links organized in links to return and page specifies which subset of links organized in
skipping to change at page 39, line 45 skipping to change at page 39, line 45
reports the registrant-ep's address if no explicit base was given) as reports the registrant-ep's address if no explicit base was given) as
well as a constant resource type (rt="core.rd-ep"); the lifetime (lt) well as a constant resource type (rt="core.rd-ep"); the lifetime (lt)
is not reported. Additional endpoint attributes are added as target is not reported. Additional endpoint attributes are added as target
attributes to their endpoint link unless their specification says attributes to their endpoint link unless their specification says
otherwise. otherwise.
Links to endpoints SHOULD be presented in path-absolute form or, if Links to endpoints SHOULD be presented in path-absolute form or, if
required, as absolute references. (This avoids the RFC6690 required, as absolute references. (This avoids the RFC6690
ambiguities.) ambiguities.)
Base addresses that contain link-local addresses MUST NOT include
zone identifiers, and such registrations MUST NOT be show unless the
lookup was made from the same link from which the registration was
made.
While Endpoint Lookup does expose the registration resources, the RD While Endpoint Lookup does expose the registration resources, the RD
does not need to make them accessible to clients. Clients SHOULD NOT does not need to make them accessible to clients. Clients SHOULD NOT
attempt to dereference or manipulate them. attempt to dereference or manipulate them.
A Resource Directory can report endpoints in lookup that are not A Resource Directory can report endpoints in lookup that are not
hosted at the same address. Lookup clients MUST be prepared to see hosted at the same address. Lookup clients MUST be prepared to see
arbitrary URIs as registration resources in the results and treat arbitrary URIs as registration resources in the results and treat
them as opaque identifiers; the precise semantics of such links are them as opaque identifiers; the precise semantics of such links are
left to future specifications. left to future specifications.
skipping to change at page 55, line 45 skipping to change at page 55, line 45
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have
provided helpful comments, discussions and ideas to improve and shape provided helpful comments, discussions and ideas to improve and shape
this document. Zach would also like to thank his colleagues from the this document. Zach would also like to thank his colleagues from the
EU FP7 SENSEI project, where many of the resource directory concepts EU FP7 SENSEI project, where many of the resource directory concepts
were originally developed. were originally developed.
12. Changelog 12. Changelog
changes from -18 to -19
o link-local addresses: allow but prescribe split-horizon fashion
when used, disallow zone identifiers
o Remove informative references to documents not mentioned any more
changes from -17 to -18 changes from -17 to -18
o Rather than re-specifying link format (Modernized Link Format), o Rather than re-specifying link format (Modernized Link Format),
describe a Limited Link Format that's the uncontested subset of describe a Limited Link Format that's the uncontested subset of
Link Format Link Format
o Acknowledging the -17 version as part of the draft o Acknowledging the -17 version as part of the draft
o Move "Read endpoint links" operation to future specification like o Move "Read endpoint links" operation to future specification like
PATCH PATCH
o Demote links-json to an informative reference, and removed them o Demote links-json to an informative reference, and removed them
from exchange examples from exchange examples
o Add note on unusability of link-local IP addresses, and describe o Add note on unusability of link-local IP addresses, and describe
mitigation. mitigation.
o Reshuffling of sections: Move additional operations and endpoint o Reshuffling of sections: Move additional operations and endpoint
skipping to change at page 64, line 35 skipping to change at page 64, line 44
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
13.2. Informative References 13.2. Informative References
[ER] Chen, P., "The entity-relationship model---toward a [ER] Chen, P., "The entity-relationship model---toward a
unified view of data", ACM Transactions on Database unified view of data", ACM Transactions on Database
Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March
1976. 1976.
[I-D.arkko-core-dev-urn]
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", draft-arkko-core-dev-urn-05
(work in progress), October 2017.
[I-D.bormann-t2trg-rel-impl] [I-D.bormann-t2trg-rel-impl]
Bormann, C., "impl-info: A link relation type for Bormann, C., "impl-info: A link relation type for
disclosing implementation information", draft-bormann- disclosing implementation information", draft-bormann-
t2trg-rel-impl-00 (work in progress), January 2018. t2trg-rel-impl-00 (work in progress), January 2018.
[I-D.hartke-t2trg-coral] [I-D.hartke-t2trg-coral]
Hartke, K., "The Constrained RESTful Application Language Hartke, K., "The Constrained RESTful Application Language
(CoRAL)", draft-hartke-t2trg-coral-06 (work in progress), (CoRAL)", draft-hartke-t2trg-coral-06 (work in progress),
October 2018. October 2018.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0 Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-17
(work in progress), November 2018. (work in progress), November 2018.
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-17 (work in progress), November 2018.
[I-D.ietf-core-links-json] [I-D.ietf-core-links-json]
Li, K., Rahman, A., and C. Bormann, "Representing Li, K., Rahman, A., and C. Bormann, "Representing
Constrained RESTful Environments (CoRE) Link Format in Constrained RESTful Environments (CoRE) Link Format in
JSON and CBOR", draft-ietf-core-links-json-10 (work in JSON and CBOR", draft-ietf-core-links-json-10 (work in
progress), February 2018. progress), February 2018.
[I-D.silverajan-core-coap-protocol-negotiation] [I-D.silverajan-core-coap-protocol-negotiation]
Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
draft-silverajan-core-coap-protocol-negotiation-09 (work draft-silverajan-core-coap-protocol-negotiation-09 (work
in progress), July 2018. in progress), July 2018.
skipping to change at page 66, line 24 skipping to change at page 66, line 14
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Appendix A. Groups Registration and Lookup Appendix A. Groups Registration and Lookup
The RD-Groups usage pattern allows announcing application groups The RD-Groups usage pattern allows announcing application groups
inside a Resource Directory. inside a Resource Directory.
Groups are represented by endpoint registrations. Their base address Groups are represented by endpoint registrations. Their base address
is a multicast address, and they SHOULD be entered with the endpoint is a multicast address, and they SHOULD be entered with the endpoint
type "core.rd-group". The endpoint name can also be referred to as a type "core.rd-group". The endpoint name can also be referred to as a
group name in this context. group name in this context.
 End of changes. 28 change blocks. 
52 lines changed or deleted 55 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/