draft-ietf-core-resource-directory-02.txt   draft-ietf-core-resource-directory-03.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft ARM Internet-Draft M. Koster
Intended status: Standards Track C. Bormann Intended status: Standards Track ARM
Expires: May 13, 2015 Universitaet Bremen TZI Expires: December 24, 2015 C. Bormann
November 9, 2014 Universitaet Bremen TZI
P. van der Stok
consultant
June 22, 2015
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-02 draft-ietf-core-resource-directory-03
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 hosts employing an entity called a Resource Directory (RD), which hosts
descriptions of resources held on other servers, allowing lookups to descriptions of resources held on other servers, allowing lookups to
be performed for those resources. This document specifies the web be performed for those resources. This document specifies the web
interfaces that a Resource Directory supports in order for web interfaces that a Resource Directory supports in order for web
servers to discover the RD and to register, maintain, lookup and servers to discover the RD and to register, maintain, lookup and
remove resources descriptions. Furthermore, new link attributes remove resources descriptions. Furthermore, new link attributes
useful in conjunction with an RD are defined. useful in conjunction with an RD are defined.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 13, 2015. This Internet-Draft will expire on December 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture and Use Cases . . . . . . . . . . . . . . . . . . 5 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 5
3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . . 7 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6
3.2. Use Case: Home and Building Automation . . . . . . . . . . 7 3.2. Use Case: Home and Building Automation . . . . . . . . . 7
3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 8 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7
4. Simple Directory Discovery . . . . . . . . . . . . . . . . . . 8 4. Simple Directory Discovery . . . . . . . . . . . . . . . . . 8
4.1. Finding a Directory Server . . . . . . . . . . . . . . . . 10 4.1. Finding a Directory Server . . . . . . . . . . . . . . . 9
4.2. Third-party registration . . . . . . . . . . . . . . . . . 10 4.2. Third-party registration . . . . . . . . . . . . . . . . 10
5. Resource Directory Function Set . . . . . . . . . . . . . . . 10 5. Resource Directory Function Set . . . . . . . . . . . . . . . 10
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Group Function Set . . . . . . . . . . . . . . . . . . . . . . 18 5.5. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 17
6.1. Register a Group . . . . . . . . . . . . . . . . . . . . . 18 6. Group Function Set . . . . . . . . . . . . . . . . . . . . . 18
6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 20 6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 18
7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . . 21 6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 20
8. New Link-Format Attributes . . . . . . . . . . . . . . . . . . 25 7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 21
8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 25 8. New Link-Format Attributes . . . . . . . . . . . . . . . . . 25
8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . . 26 8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 25
9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 25
9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 26 9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 25
9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 27 9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 26
9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 28 9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 27
9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . . 28 9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 27
9.5. TXT Record key=value strings . . . . . . . . . . . . . . . 28 9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 28
9.6. Importing resource links into DNS-SD . . . . . . . . . . . 29 9.5. TXT Record key=value strings . . . . . . . . . . . . . . 28
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9.6. Importing resource links into DNS-SD . . . . . . . . . . 28
10.1. Endpoint Identification and Authentication . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10.2. Access Control . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Endpoint Identification and Authentication . . . . . . . 30
10.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 31 10.2. Access Control . . . . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 10.3. Denial of Service Attacks . . . . . . . . . . . . . . . 30
11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 31
11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . . 32 11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 31
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Lighting Installation . . . . . . . . . . . . . . . . . 32
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 12.1.1. Installation Characteristics . . . . . . . . . . . . 32
15.1. Normative References . . . . . . . . . . . . . . . . . . . 35 12.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . . 36 12.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 12.1.4. RD Operation . . . . . . . . . . . . . . . . . . . . 41
12.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 41
12.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 42
12.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 42
12.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 44
12.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 44
12.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 45
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
15.1. Normative References . . . . . . . . . . . . . . . . . . 47
15.2. Informative References . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
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
networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M)
applications such as smart energy and building automation. applications such as smart energy and building automation.
The discovery of resources offered by a constrained server is very The discovery of resources offered by a constrained server is very
important in machine-to-machine applications where there are no important in machine-to-machine applications where there are no
humans in the loop and static interfaces result in fragility. The humans in the loop and static interfaces result in fragility. The
discovery of resources provided by an HTTP Web Server is typically discovery of resources provided by an HTTP Web Server is typically
called Web Linking [RFC5988]. The use of Web Linking for the called Web Linking [RFC5988]. The use of Web Linking for the
description and discovery of resources hosted by constrained web description and discovery of resources hosted by constrained web
servers is specified by the CoRE Link Format [RFC6690]. This servers is specified by the CoRE Link Format [RFC6690]. This
skipping to change at page 8, line 42 skipping to change at page 8, line 13
triples, or relation/attribute pairs providing metadata about triples, or relation/attribute pairs providing metadata about
resource links. External catalogs that are represented in other resource links. External catalogs that are represented in other
formats may be converted to link-format or link-format+json for formats may be converted to link-format or link-format+json for
storage and access by Resource Directories. Since it is common storage and access by Resource Directories. Since it is common
practice for these to be URN encoded, simple and lossless structural practice for these to be URN encoded, simple and lossless structural
transforms will generally be sufficient to store external metadata in transforms will generally be sufficient to store external metadata in
Resource Directories. Resource Directories.
The additional features of Resource Directory allow domains to be The additional features of Resource Directory allow domains to be
defined to enable access to a particular set of resources from defined to enable access to a particular set of resources from
particular applications. this provides isolation and protection of particular applications. This provides isolation and protection of
sensitive data when needed. Resource groups may defined to allow sensitive data when needed. Resource groups may defined to allow
batched reads from multiple resources. batched reads from multiple resources.
4. Simple Directory Discovery 4. Simple Directory Discovery
Not all endpoints hosting resources are expected to know how to Not all endpoints hosting resources are expected to know how to
implement the Resource Directory Function Set (see Section 5) and implement the Resource Directory Function Set (see Section 5) and
thus explicitly register with a Resource Directory (or other such thus explicitly register with a Resource Directory (or other such
directory server). Instead, simple endpoints can implement the directory server). Instead, simple endpoints can implement the
generic Simple Directory Discovery approach described in this generic Simple Directory Discovery approach described in this
section. An RD implementing this specification MUST implement Simple section. An RD implementing this specification MUST implement Simple
Directory Discovery. However, there may be security reasons why this Directory Discovery. However, there may be security reasons why this
form of directory discovery would be disabled. form of directory discovery would be disabled.
This approach requires that the endpoint makes available the hosted This approach requires that the endpoint makes available the hosted
resources that it wants to be discovered, as links on its resources that it wants to be discovered, as links on its "/.well-
"/.well-known/core" interface as specified in [RFC6690]. known/core" interface as specified in [RFC6690].
The endpoint then finds one or more IP addresses of the directory The endpoint then finds one or more IP addresses of the directory
server it wants to know about its resources as described in server it wants to know about its resources as described in
Section 4.1. Section 4.1.
An endpoint that wants to make itself discoverable occasionally sends An endpoint that wants to make itself discoverable occasionally sends
a POST request to the "/.well-known/core" URI of any candidate a POST request to the "/.well-known/core" URI of any candidate
directory server that it finds. The body of the POST request is directory server that it finds. The body of the POST request is
either either
skipping to change at page 11, line 31 skipping to change at page 10, line 50
using the CoRE Link Format (see also Section 4.1). This section using the CoRE Link Format (see also Section 4.1). This section
defines discovery of the RD using the well-known interface of the defines discovery of the RD using the well-known interface of the
CoRE Link Format [RFC6690] as the required mechanism. It is however CoRE Link Format [RFC6690] as the required mechanism. It is however
expected that RDs will also be discoverable via other methods expected that RDs will also be discoverable via other methods
depending on the deployment. depending on the deployment.
Discovery is performed by sending either a multicast or unicast GET Discovery is performed by sending either a multicast or unicast GET
request to "/.well-known/core" and including a Resource Type (rt) request to "/.well-known/core" and including a Resource Type (rt)
parameter [RFC6690] with the value "core.rd" in the query string. parameter [RFC6690] with the value "core.rd" in the query string.
Likewise, a Resource Type parameter value of "core.rd-lookup" is used Likewise, a Resource Type parameter value of "core.rd-lookup" is used
to discover the RD Lookup Function Set. Upon success, the response to discover the RD Lookup Function Set. Upon success, the response
will contain a payload with a link format entry for each RD will contain a payload with a link format entry for each RD
discovered, with the URL indicating the root resource of the RD. discovered, with the URL indicating the root resource of the RD.
When performing multicast discovery, the multicast IP address used When performing multicast discovery, the multicast IP address used
will depend on the scope required and the multicast capabilities of will depend on the scope required and the multicast capabilities of
the network. the network.
An RD implementation of this specification MUST support query An RD implementation of this specification MUST support query
filtering for the rt parameter as defined in [RFC6690]. filtering for the rt parameter as defined in [RFC6690].
The discovery request interface is specified as follows: The discovery request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
skipping to change at page 12, line 4 skipping to change at page 11, line 19
An RD implementation of this specification MUST support query An RD implementation of this specification MUST support query
filtering for the rt parameter as defined in [RFC6690]. filtering for the rt parameter as defined in [RFC6690].
The discovery request interface is specified as follows: The discovery request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
Method: GET Method: GET
URI Template: /.well-known/core{?rt} URI Template: /.well-known/core{?rt}
URI Template Variables: URI Template Variables:
rt := Resource Type (optional). MAY contain the value rt := Resource Type (optional). MAY contain the value "core.rd",
"core.rd", "core.rd-lookup", "core.rd-group" or "core.rd*" "core.rd-lookup", "core.rd-group" or "core.rd*"
Content-Type: application/link-format (if any) Content-Type: application/link-format (if any)
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content" with an application/link-format payload Success: 2.05 "Content" with an application/link-format payload
containing one or more matching entries for the RD resource. containing one or more matching entries for the RD resource.
Failure: 4.04 "Not Found" is returned in case no matching entry is Failure: 4.04 "Not Found" is returned in case no matching entry is
found for a unicast request. found for a unicast request.
skipping to change at page 13, line 37 skipping to change at page 13, line 5
The registration request interface is specified as follows: The registration request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
Method: POST Method: POST
URI Template: /{+rd}{?ep,d,et,lt,con} URI Template: /{+rd}{?ep,d,et,lt,con}
URI Template Variables: URI Template Variables:
rd := RD Function Set path (mandatory). This is the path of the rd := RD Function Set path (mandatory). This is the path of the
RD Function Set, as obtained from discovery. An RD SHOULD use RD Function Set, as obtained from discovery. An RD SHOULD use
the value "rd" for this variable whenever possible. the value "rd" for this variable whenever possible.
ep := Endpoint (mandatory). The endpoint identifier or name of ep := Endpoint (mandatory). The endpoint identifier or name of
the registering node, unique within that domain. The maximum the registering node, unique within that domain. The maximum
length of this parameter is 63 bytes. length of this parameter is 63 bytes.
d := Domain (optional). The domain to which this endpoint d := Domain (optional). The domain to which this endpoint
belongs. This parameter SHOULD be less than 63 bytes. belongs. This parameter SHOULD be less than 63 bytes.
Optional. When this parameter is elided, the RD MAY associate Optional. When this parameter is elided, the RD MAY associate
the endpoint with a configured default domain. The domain the endpoint with a configured default domain. The domain
value is needed to export the endpoint to DNS-SD (see value is needed to export the endpoint to DNS-SD (see
Section 9). Section 9).
et := Endpoint Type (optional). The semantic type of the et := Endpoint Type (optional). The semantic type of the
endpoint. This parameter SHOULD be less than 63 bytes. endpoint. This parameter SHOULD be less than 63 bytes.
Optional. Optional.
lt := Lifetime (optional). Lifetime of the registration in lt := Lifetime (optional). Lifetime of the registration in
seconds. Range of 60-4294967295. If no lifetime is included, seconds. Range of 60-4294967295. If no lifetime is included,
a default value of 86400 (24 hours) SHOULD be assumed. a default value of 86400 (24 hours) SHOULD be assumed.
con := Context (optional). This parameter sets the scheme, con := Context (optional). This parameter sets the scheme,
address and port at which this server is available in the form address and port at which this server is available in the form
scheme://host:port. Optional. In the absence of this scheme://host:port. Optional. In the absence of this
parameter the scheme of the protocol, source IP address and parameter the scheme of the protocol, source IP address and
source port of the register request are assumed. This source port of the register request are assumed. This
parameter is mandatory when the directory is filled by a third parameter is mandatory when the directory is filled by a third
party such as an installation tool. party such as an installation tool.
Content-Type: application/link-format Content-Type: application/link-format
Content-Type: application/link-format+json Content-Type: application/link-format+json
skipping to change at page 15, line 40 skipping to change at page 15, line 4
is replaced only if both the target URI and relation type match (see is replaced only if both the target URI and relation type match (see
Section 10.1). Section 10.1).
The update request interface is specified as follows: The update request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
Method: POST Method: POST
URI Template: /{+location}{?lt,con} URI Template: /{+location}{?lt,con}
URI Template Variables: URI Template Variables:
location := This is the Location path returned by the RD as a location := This is the Location path returned by the RD as a
result of a successful earlier registration. result of a successful earlier registration.
lt := Lifetime (optional). Lifetime of the registration in lt := Lifetime (optional). Lifetime of the registration in
seconds. Range of 60-4294967295. If no lifetime is included, seconds. Range of 60-4294967295. If no lifetime is included,
a default value of 86400 (24 hours) SHOULD be assumed. a default value of 86400 (24 hours) SHOULD be assumed.
con := Context (optional). This parameter sets the scheme, con := Context (optional). This parameter sets the scheme,
address and port at which this server is available in the form address and port at which this server is available in the form
scheme://host:port. Optional. In the absence of this scheme://host:port. Optional. In the absence of this
parameter the scheme of the protocol, source IP address and parameter the scheme of the protocol, source IP address and
source port used to register are assumed. This parameter is source port used to register are assumed. This parameter is
compulsory when the directory is filled by a third party such compulsory when the directory is filled by a third party such
as an installation tool. as an installation tool.
Content-Type: application/link-format (optional) Content-Type: application/link-format (optional)
Content-Type: application/link-format+json (optional) Content-Type: application/link-format+json (optional)
skipping to change at page 16, line 29 skipping to change at page 15, line 37
Success: 2.04 "Changed" in the update was successfully processed. Success: 2.04 "Changed" in the update was successfully processed.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may Failure: 4.04 "Not Found". Registration does not exist (e.g. may
have expired). have expired).
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable". Service could not perform the
operation. operation.
The following example shows an endpoint updating a new set of The following example shows an endpoint updating its registration at
resources to an RD using this interface. an RD using this interface.
EP RD EP RD
| | | |
| --- POST /rd/4521 --------------------------> | | --- POST /rd/4521 --------------------------> |
| | | |
| | | |
| <-- 2.04 Changed ---------------------------- | | <-- 2.04 Changed ---------------------------- |
| | | |
Req: POST /rd/4521 Req: POST /rd/4521
Res: 2.04 Changed Res: 2.04 Changed
5.4. Removal 5.4. Removal
skipping to change at page 17, line 16 skipping to change at page 16, line 23
The removal request interface is specified as follows: The removal request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
Method: DELETE Method: DELETE
URI Template: /{+location} URI Template: /{+location}
URI Template Variables: URI Template Variables:
location := This is the Location path returned by the RD as a location := This is the Location path returned by the RD as a
result of a successful earlier registration. result of a successful earlier registration.
The following responses codes are defined for this interface: The following responses codes are defined for this interface:
Success: 2.02 "Deleted" upon successful deletion Success: 2.02 "Deleted" upon successful deletion
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may Failure: 4.04 "Not Found". Registration does not exist (e.g. may
have expired). have expired).
skipping to change at page 18, line 5 skipping to change at page 17, line 5
| --- DELETE /rd/4521 ------------------------> | | --- DELETE /rd/4521 ------------------------> |
| | | |
| | | |
| <-- 2.02 Deleted ---------------------------- | | <-- 2.02 Deleted ---------------------------- |
| | | |
Req: DELETE /rd/4521 Req: DELETE /rd/4521
Res: 2.02 Deleted Res: 2.02 Deleted
5.5. Read Endpoint Links
Some endpoints may wish to manage their links as a collection, and
may need to read the current set of links in order to determine link
maintenance operations.
The read request interface is specified as follows:
Interaction: EP -> RD
Method: GET
URI Template: /{+location}{?rt,if,ct}
URI Template Variables:
location := This is the Location path returned by the RD as a
result of a successful earlier registration.
The following responses codes are defined for this interface:
Success: 2.05 "Content" upon success
Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may
have expired).
Failure: 5.03 "Service Unavailable". Service could not perform the
operation.
The following examples show successful read of the endpoint links
from the RD.
EP RD
| |
| --- GET /rd/4521 ------------------------> |
| |
| |
| <-- 2.05 Content </sensors... ---------------- |
| |
Req: GET /rd/4521
Res: 2.01 Content
Payload:
</sensors/temp>;ct=41;rt="temperature-c";if="sensor",
</sensors/light>;ct=41;rt="light-lux";if="sensor"
6. Group Function Set 6. Group Function Set
This section defines a function set for the creation of groups of This section defines a function set for the creation of groups of
endpoints for the purpose of managing and looking up endpoints for endpoints for the purpose of managing and looking up endpoints for
group operations. The group function set is similar to the resource group operations. The group function set is similar to the resource
directory function set, in that a group may be created or removed. directory function set, in that a group may be created or removed.
However unlike an endpoint entry, a group entry consists of a list of However unlike an endpoint entry, a group entry consists of a list of
endpoints and does not have a lifetime associated with it. In order endpoints and does not have a lifetime associated with it. In order
to make use of multicast requests with CoAP, a group MAY have a to make use of multicast requests with CoAP, a group MAY have a
multicast address associated with it. multicast address associated with it.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
create (or update), optionally the domain the group belongs to, and create (or update), optionally the domain the group belongs to, and
optionally the multicast address of the group. The registration optionally the multicast address of the group. The registration
message includes the list of endpoints that belong to that group. If message includes the list of endpoints that belong to that group. If
an endpoint has already registered with the RD, the RD attempts to an endpoint has already registered with the RD, the RD attempts to
use the context of the endpoint from its RD endpoint entry. If the use the context of the endpoint from its RD endpoint entry. If the
client registering the group knows the endpoint has already client registering the group knows the endpoint has already
registered, then it MAY send a blank target URI for that endpoint registered, then it MAY send a blank target URI for that endpoint
link when registering the group. Configuration of the endpoints link when registering the group. Configuration of the endpoints
themselves is out of scope of this specification. Such an interface themselves is out of scope of this specification. Such an interface
for managing the group membership of an endpoint has been defined in for managing the group membership of an endpoint has been defined in
[I-D.ietf-core-groupcomm]. [RFC7390].
The registration request interface is specified as follows: The registration request interface is specified as follows:
Interaction: Manager -> RD Interaction: Manager -> RD
Method: POST Method: POST
URI Template: /{+rd-group}{?gp,d,con} URI Template: /{+rd-group}{?gp,d,con}
URI Template Variables: URI Template Variables:
rd-group := RD Group Function Set path (mandatory). This is the rd-group := RD Group Function Set path (mandatory). This is the
path of the RD Group Function Set. An RD SHOULD use the value path of the RD Group Function Set. An RD SHOULD use the value
"rd-group" for this variable whenever possible. "rd-group" for this variable whenever possible.
gp := Group Name (mandatory). The name of the group to be gp := Group Name (mandatory). The name of the group to be
created or replaced, unique within that domain. The maximum created or replaced, unique within that domain. The maximum
length of this parameter is 63 bytes. length of this parameter is 63 bytes.
d := Domain (optional). The domain to which this group belongs. d := Domain (optional). The domain to which this group belongs.
The maximum length of this parameter is 63 bytes. Optional. The maximum length of this parameter is 63 bytes. Optional.
When this parameter is elided, the RD MAY associate the When this parameter is elided, the RD MAY associate the
endpoint with a configured default domain. The domain value is endpoint with a configured default domain. The domain value is
needed to export the endpoint to DNS-SD (see Section 9) needed to export the endpoint to DNS-SD (see Section 9)
con := Context (optional). This parameter is used to set the IP con := Context (optional). This parameter is used to set the IP
multicast address at which this server is available in the form multicast address at which this server is available in the form
scheme://multicast-address:port. Optional. In the absence of scheme://multicast-address:port. Optional. In the absence of
this parameter no multicast address is configured. This this parameter no multicast address is configured. This
parameter is compulsory when the directory is filled by an parameter is compulsory when the directory is filled by an
installation tool. installation tool.
Content-Type: application/link-format Content-Type: application/link-format
Content-Type: application/link-format+json Content-Type: application/link-format+json
skipping to change at page 20, line 29 skipping to change at page 20, line 21
The removal request interface is specified as follows: The removal request interface is specified as follows:
Interaction: Manager -> RD Interaction: Manager -> RD
Method: DELETE Method: DELETE
URI Template: /{+location} URI Template: /{+location}
URI Template Variables: URI Template Variables:
location := This is the Location path returned by the RD as a location := This is the Location path returned by the RD as a
result of a successful group registration. result of a successful group registration.
The following responses codes are defined for this interface: The following responses codes are defined for this interface:
Success: 2.02 "Deleted" upon successful deletion Success: 2.02 "Deleted" upon successful deletion
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request". Malformed request.
Failure: 4.04 "Not Found". Group does not exist. Failure: 4.04 "Not Found". Group does not exist.
skipping to change at page 21, line 40 skipping to change at page 21, line 34
MAY be included in a lookup, all included parameters MUST match for a MAY be included in a lookup, all included parameters MUST match for a
resource to be returned. The character '*' MAY be included at the resource to be returned. The character '*' MAY be included at the
end of a parameter value as a wildcard operator. end of a parameter value as a wildcard operator.
The lookup interface is specified as follows: The lookup interface is specified as follows:
Interaction: Client -> RD Interaction: Client -> RD
Method: GET Method: GET
URI Template: /{+rd-lookup-base}/ URI Template: /{+rd-lookup-base}/{lookup-
{lookup-type}{?d,ep,gp,et,rt,page,count,resource-param} type}{?d,ep,gp,et,rt,page,count,resource-param}
Parameters: URI Template Variables:
rd-lookup-base := RD Lookup Function Set path (mandatory). This rd-lookup-base := RD Lookup Function Set path (mandatory). This
is the path of the RD Lookup Function Set. An RD SHOULD use the is the path of the RD Lookup Function Set. An RD SHOULD use the
value "rd-lookup" for this variable whenever possible. value "rd-lookup" for this variable whenever possible.
lookup-type := ("d", "ep", "res", "gp") (mandatory) This lookup-type := ("d", "ep", "res", "gp") (mandatory) This variable
variable is used to select the kind of lookup to perform is used to select the kind of lookup to perform (domain,
(domain, endpoint, resource, or group). endpoint, resource, or group).
ep := Endpoint (optional). Used for endpoint, group and ep := Endpoint (optional). Used for endpoint, group and resource
resource lookups. lookups.
d := Domain (optional). Used for domain, group, endpoint and d := Domain (optional). Used for domain, group, endpoint and
resource lookups. resource lookups.
page := Page (optional). Parameter can not be used without the page := Page (optional). Parameter can not be used without the
count parameter. Results are returned from result set in pages count parameter. Results are returned from result set in pages
that contains 'count' results starting from index (page * that contains 'count' results starting from index (page *
count). count).
count := Count (optional). Number of results is limited to this count := Count (optional). Number of results is limited to this
parameter value. If the parameter is not present, then an RD parameter value. If the parameter is not present, then an RD
implementation specific default value SHOULD be used. implementation specific default value SHOULD be used.
rt := Resource type (optional). Used for group, endpoint and rt := Resource type (optional). Used for group, endpoint and
resource lookups. resource lookups.
et := Endpoint type (optional). Used for group, endpoint and et := Endpoint type (optional). Used for group, endpoint and
resource lookups. resource lookups.
resource-param := Link attribute parameters (optional). Any resource-param := Link attribute parameters (optional). Any link
link attribute as defined in Section 4.1 of [RFC6690], used for attribute as defined in Section 4.1 of [RFC6690], used for
resource lookups. resource lookups.
The following responses codes are defined for this interface: The following responses codes are defined for this interface:
Success: 2.05 "Content" with an "application/link-format" or Success: 2.05 "Content" with an "application/link-format" or
"application/link-format+json" payload containing a matching "application/link-format+json" payload containing a matching
entries for the lookup. entries for the lookup.
Failure: 4.04 "Not Found" in case no matching entry is found for a Failure: 4.04 "Not Found" in case no matching entry is found for a
unicast request. unicast request.
skipping to change at page 23, line 18 skipping to change at page 23, line 10
| | | |
| | | |
| <-- 2.05 Content <coap://{host:port}/temp>;rt="temperature" | | <-- 2.05 Content <coap://{host:port}/temp>;rt="temperature" |
| | | |
Req: GET /rd-lookup/res?rt=temperature Req: GET /rd-lookup/res?rt=temperature
Res: 2.05 Content Res: 2.05 Content
<coap://{host:port}/temp>;rt="temperature" <coap://{host:port}/temp>;rt="temperature"
The following example shows a client performing an endpoint lookup: The following example shows a client performing an endpoint type
lookup:
Client RD Client RD
| | | |
| ----- GET /rd-lookup/ep?et=power-node --------------------> | | ----- GET /rd-lookup/ep?et=power-node --------------------> |
| | | |
| | | |
| <-- 2.05 Content <coap://{ip:port}>;ep="node5" ------------ | | <-- 2.05 Content <coap://{ip:port}>;ep="node5" ------------ |
| | | |
Req: GET /rd-lookup/ep?et=power-node Req: GET /rd-lookup/ep?et=power-node
Res: 2.05 Content Res: 2.05 Content
<coap://{ip:port}>;ep="node5", <coap://{ip:port}>;ep="node5",
<coap://{ip:port}>;ep="node7" <coap://{ip:port}>;ep="node7"
skipping to change at page 28, line 41 skipping to change at page 28, line 13
is mapped to the DNS-SD <ServiceType> by appending a period followed is mapped to the DNS-SD <ServiceType> by appending a period followed
by the "_sub" label and then appending a period followed by the by the "_sub" label and then appending a period followed by the
service type label pair derived as in the previous paragraph. For service type label pair derived as in the previous paragraph. For
example, rt="dali.light" is mapped into "light._sub._dali._udp". example, rt="dali.light" is mapped into "light._sub._dali._udp".
The resulting string is used to form labels for DNS-SD records which The resulting string is used to form labels for DNS-SD records which
are stored directly in the DNS. are stored directly in the DNS.
9.4. Domain mapping 9.4. Domain mapping
DNS domains are defined from the "d" attribute.The domain attribute DNS domains may be derived from the "d" attribute. The domain
is suffixed to the host name and should be consistent with the domain attribute may be suffixed with the zone name of the authoritative DNS
name attributed to the hosting network segment. server to generate the domain name. The "ep" attribute is prefixed
to the domain name to generate the FQDN to be stored into DNS with an
AAAA RR.
9.5. TXT Record key=value strings 9.5. TXT Record key=value strings
A number of [RFC6763] key/value pairs are derived from link-format A number of [RFC6763] key/value pairs are derived from link-format
information, to be exported in the DNS-SD as key=value strings in a information, to be exported in the DNS-SD as key=value strings in a
TXT record ([RFC6763], Section 6.3). TXT record ([RFC6763], Section 6.3).
The resource <URI> is exported as key/value pair "path=<URI>". The resource <URI> is exported as key/value pair "path=<URI>".
The Interface Description "if" attribute is exported as key/value The Interface Description "if" attribute is exported as key/value
skipping to change at page 29, line 30 skipping to change at page 29, line 10
the <ServiceType>, and registered in the correct <Domain>. The agent the <ServiceType>, and registered in the correct <Domain>. The agent
responsible for exporting records to the DNS zone file SHOULD be responsible for exporting records to the DNS zone file SHOULD be
authenticated to the DNS server. The following example shows an authenticated to the DNS server. The following example shows an
agent discovering a resource to be exported: agent discovering a resource to be exported:
Agent RD Agent RD
| | | |
| --- GET /rd-lookup/res?exp ------------------------------> | | --- GET /rd-lookup/res?exp ------------------------------> |
| | | |
| | | |
| <-- 2.05 Content "<coap://node1/light/1>;exp; ------------ | | <-- 2.05 Content "<coap://[FDFD::1234]:61616/light/1>;exp; |
| rt="dali.light";ins="FrontSpot" | | rt="dali.light";ins="FrontSpot" |
| d="example.com" | | d="office";ep="node1" |
| | | |
Req: GET /rd-lookup/res?exp Req: GET /rd-lookup/res?exp
Res: 2.05 Content Res: 2.05 Content
<coap://[FDFD::1234]:61616/light/1>; <coap://[FDFD::1234]:61616/light/1>;
exp;ct=41;rt="dali.light";ins="FrontSpot"; exp;rt="dali.light";ins="Spot";
d="example.com" d="office"; ep="node1"
The agent subsequently registers the following DNS-SD RRs: The agent subsequently registers the following DNS-SD RRs, assuming a
zone name "example.com" prefixed with "office":
node1.example.com. IN AAAA node1.office.example.com. IN AAAA FDFD::1234
FDFD::1234 _dali._udp.office.example.com IN PTR
_dali._udp.example.com IN PTR Spot._dali._udp.office.example.com
FrontSpot._dali._udp.example.com light._sub._dali._udp.example.com IN PTR
light._sub._dali._udp.example.com IN PTR Spot._dali._udp.office.example.com
FrontSpot._dali._udp.example.com Spot._dali._udp.office.example.com IN SRV 0 0 5678
FrontSpot._dali._udp.example.com IN SRV 0 0 5678 node1.office.example.com.
node1.example.com. Spot._dali._udp.office.example.com IN TXT
FrontSpot._dali._udp.example.com IN TXT
txtver=1;path=/light/1 txtver=1;path=/light/1
In the above figure the Service Name is chosen as In the above figure the Service Name is chosen as
FrontSpot._dali._udp.example.com without the light._sub service Spot._dali._udp.office.example.com without the light._sub service
prefix. An alternative Service Name would be: prefix. An alternative Service Name would be:
FrontSpot.light._sub._dali._udp.example.com. Spot.light._sub._dali._udp.office.example.com.
10. Security Considerations 10. Security Considerations
The security considerations as described in Section 7 of [RFC5988] The security considerations as described in Section 7 of [RFC5988]
and Section 6 of [RFC6690] apply. The "/.well-known/core" resource and Section 6 of [RFC6690] apply. The "/.well-known/core" resource
may be protected e.g. using DTLS when hosted on a CoAP server as may be protected e.g. using DTLS when hosted on a CoAP server as
described in [RFC7252]. DTLS or TLS based security SHOULD be used on described in [RFC7252]. DTLS or TLS based security SHOULD be used on
all resource directory interfaces defined in this document (TODO: all resource directory interfaces defined in this document.
Improve the exact DTLS or TLS security requirements and references).
10.1. Endpoint Identification and Authentication 10.1. Endpoint Identification and Authentication
An Endpoint is determined to be unique by an RD by the Endpoint An Endpoint is determined to be unique by an RD by the Endpoint
identifier parameter included during Registration, and any associated identifier parameter included during Registration, and any associated
TLS or DTLS security bindings. An Endpoint MUST NOT be identified by TLS or DTLS security bindings. An Endpoint MUST NOT be identified by
its protocol, port or IP address as these may change over the its protocol, port or IP address as these may change over the
lifetime of an Endpoint. lifetime of an Endpoint.
Every operation performed by an Endpoint or Client on a resource Every operation performed by an Endpoint or Client on a resource
skipping to change at page 31, line 20 skipping to change at page 30, line 43
Services that run over UDP unprotected are vulnerable to unknowingly Services that run over UDP unprotected are vulnerable to unknowingly
become part of a DDoS attack as UDP does not require return become part of a DDoS attack as UDP does not require return
routability check. Therefore, an attacker can easily spoof the routability check. Therefore, an attacker can easily spoof the
source IP of the target entity and send requests to such a service source IP of the target entity and send requests to such a service
which would then respond to the target entity. This can be used for which would then respond to the target entity. This can be used for
large-scale DDoS attacks on the target. Especially, if the service large-scale DDoS attacks on the target. Especially, if the service
returns a response that is order of magnitudes larger than the returns a response that is order of magnitudes larger than the
request, the situation becomes even worse as now the attack can be request, the situation becomes even worse as now the attack can be
amplified. DNS servers have been widely used for DDoS amplification amplified. DNS servers have been widely used for DDoS amplification
attacks. Recently, it has been observed that NTP Servers, that also attacks. Recently, it has been observed that NTP Servers, that also
run on unprotected UDP have been used for DDoS attacks (http:// run on unprotected UDP have been used for DDoS attacks
tools.cisco.com/security/center/content/CiscoSecurityNotice/ (http://tools.cisco.com/security/center/content/CiscoSecurityNotice/
CVE-2013-5211) [TODO: Ref, and cut down the verbiage, as this is CVE-2013-5211) since there is no return routability check and can
already discussed in RFC 7252] since there is no return routability have a large amplification factor. The responses from the NTP server
check and can have a large amplification factor. The responses from were found to be 19 times larger than the request. A Resource
the NTP server were found to be 19 times larger than the request. A Directory (RD) which responds to wild-card lookups is potentially
Resource Directory (RD) which responds to wild-card lookups is vulnerable if run with CoAP over UDP. Since there is no return
potentially vulnerable if run with CoAP over UDP. Since there is no routability check and the responses can be significantly larger than
return routability check and the responses can be significantly requests, RDs can unknowingly become part of a DDoS amplification
larger than requests, RDs can unknowingly become part of a DDoS attack. Therefore, it is RECOMMENDED that implementations ensure
amplification attack. Therefore, it is RECOMMENDED that return routability. This can be done, for example by responding to
implementations ensure return routability. This can be done, for wild card lookups only over DTLS or TLS or TCP.
example by responding to wild card lookups only over DTLS or TLS or
TCP.
11. IANA Considerations 11. IANA Considerations
11.1. Resource Types 11.1. Resource Types
"core.rd", "core.rd-group" and "core.rd-lookup" resource types need "core.rd", "core.rd-group" and "core.rd-lookup" resource types need
to be registered with the resource type registry defined by to be registered with the resource type registry defined by
[RFC6690]. [RFC6690].
11.2. Link Extension 11.2. Link Extension
skipping to change at page 33, line 4 skipping to change at page 32, line 33
| Page | page | Integer | Used for pagination | | Page | page | Integer | Used for pagination |
| Count | count | Integer | Used for pagination | | Count | count | Integer | Used for pagination |
+----------+-------+---------------+--------------------------------+ +----------+-------+---------------+--------------------------------+
Table 1: RD Parameters Table 1: RD Parameters
The IANA policy for future additions to the sub-registry is "Expert The IANA policy for future additions to the sub-registry is "Expert
Review" as described in [RFC5226]. Review" as described in [RFC5226].
12. Examples 12. Examples
Examples are added here.
12.1. Lighting Installation
This example shows a simplified lighting installation which makes use
of the Resource Directory (RD) to facilitate the installation and
start up of the application code in the lights and sensors. In
particular, the example leads to the definition of a group and the
enabling of the corresponding multicast address. No conclusions must
be drawn on the realization of actual installation procedures,
because the example "emphasizes" some of the issues that may
influence the use of the RD.
12.1.1. Installation Characteristics
The example assumes that the installation is managed. That means
that a Commissioning Tool (CT) is used to authorize the addition of
nodes, name them, and name their services. The CT can be connected
to the installation in many ways: the CT can be part of the
installation network, connected by wifi to the installation network,
or connected via GPRS link, or other method.
It is assumed that there are two naming authorities for the
installation: (1) the network manager that is responsible for the
correct operation of the network and the connected interfaces, and
(2) the lighting manager that is responsible for the correct
functioning of networked lights and sensors. The result is the
existence of two naming schemes coming from the two managing
entities.
The example installation consists of one presence sensor, and two
luminaries, luminary1 and luminary2, each with their own wireless
interface. Each luminary contains three lamps: left, right and
middle. Each luminary is accessible through one end-point. For each
lamp a resource exists to modify the settings of a lamp in a
luminary. The purpose of the installation is that the presence
sensor notifies the presence of persons to a group of lamps. The
group of lamps consists of: middle and left lamps of luminary1 and
right lamp of luminary2.
Before commissioning by the lighting manager, the network is
installed and access to the interfaces is proven to work by the
network manager. Following the lay-out of cables and routers the
network manager has defined DNS domains. The presence sensor and
luminary1 are part of DNS domain: rtr_5612_rrt.example.com and
luminary2 is part of rtr_7899_pfa.example.com. The names of
luminary1- luminary2-, and sensor- interfaces are respectively:
lm_12-345-678, lm_12-456-378, and sn_12-345-781. These names are
stored in DNS together with their IP addresses. The FQDN of the
interfaces is shown in Table 2 below:
+--------------------+----------------------------------------+
| Name | FQDN |
+--------------------+----------------------------------------+
| luminary1 | lm_12-345-678.rtr_5612_rrt.example.com |
| luminary2 | lm_12-456-378.rtr_7899_pfa.example.com |
| Presence sensor | sn_12-345-781.rtr_5612_rrt.example.com |
| Resource directory | pc_123456.rtr_5612_rrt.example.com |
+--------------------+----------------------------------------+
Table 2: interface FQDNs
At the moment of installation, the network under installation is not
necessarily connected to the DNS infra structure. Therefore, SLAAC
IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in
Table 3 below:
+--------------------+--------------+
| Name | IPv6 address |
+--------------------+--------------+
| luminary1 | FDFD::ABCD:1 |
| luminary2 | FDFD::ABCD:2 |
| Presence sensor | FDFD::ABCD:3 |
| Resource directory | FDFD::ABCD:0 |
+--------------------+--------------+
Table 3: interface SLAAC addresses
In Section 12.1.2 the use of resource directory during installation
is presented. In Section 12.1.3 the connection to DNS is discussed.
12.1.2. RD entries
It is assumed that access to the DNS infrastructure is not always
possible during installation. Therefore, the SLAAC addresses are
used in this section.
For discovery, the resource types (rt) of the devices are important.
The lamps in the luminaries have rt: light, and the presence sensor
has rt: p-sensor. The end-points have names which are relevant to
the light installation manager. In this case luminary1, luminary2,
and the presence sensor are located in room 2-4-015, where luminary1
is located at the window and luminary2 and the presence sensor are
located at the door. The end-point names reflect this physical
location. The middle, left and right lamps are accessed via path
/light/middle, /light/left, and /light/right respectively. The
identifiers relevant to the Resource Directory are shown in Table 4
below:
+----------------+------------------+---------------+---------------+
| Name | end-point | resource path | resource type |
+----------------+------------------+---------------+---------------+
| luminary1 | lm_R2-4-015_wndw | /light/left | light |
| luminary1 | lm_R2-4-015_wndw | /light/middle | light |
| luminary1 | lm_R2-4-015_wndw | /light/right | light |
| luminary2 | lm_R2-4-015_door | /light/left | light |
| luminary2 | lm_R2-4-015_door | /light/middle | light |
| luminary2 | lm_R2-4-015_door | /light/right | light |
| Presence | ps_R2-4-015_door | /ps | p-sensor |
| sensor | | | |
+----------------+------------------+---------------+---------------+
Table 4: Resource Directory identifiers
The CT inserts the end-points of the luminaries and the sensor in the
RD using the Context parameter (con) to specify the interface
address:
Req: POST
coap://[FDFD::ABCD:0]/rd?ep=lm_R2-4-015_wndw
Payload:
</light/left>;rt="light";
con="FDFD::ABCD:1";
d="R2-4-015"; ins="lamp4444"; exp,
</light/middle>;rt="light";
con="FDFD::ABCD:1";
d="R2-4-015"; ins="lamp5555"; exp,
</light/right>;rt="light";
con="FDFD::ABCD:1";
d="R2-4-015"; ins="lamp6666"; exp
Res: 2.01 Created
Location: /rd/4521
Req: POST coap://[FDFD::ABCD:0]/rd?ep=lm_R2-4-015_door
Payload:
</light/left>;rt="light";
con="FDFD::ABCD:2";
d="R2-4-015"; ins="lamp1111"; exp,
</light/middle>;rt="light";
con="FDFD::ABCD:2";
d="R2-4-015"; ins="lamp2222"; exp,
</light/right>;rt="light";
con="FDFD::ABCD:2";
d="R2-4-015"; ins="lamp3333"; exp
Res: 2.01 Created
Location: /rd/4522
Req: POST coap://[FDFD::ABCD:0]/rd?ep=ps_R2-4-015_door
Payload:
</ps>;rt="p-sensor";
con="FDFD::ABCD:3";
d="R2-4-015"; ins="pres1234"; exp
Res: 2.01 Created
Location: /rd/4523
The domain name d="R2-4-015" has been added for an efficient lookup
because filtering on "ep" name is awkward. The same domain name is
communicated to the two luminaries and the presence sensor by the CT.
The "exp" attribute is set for the later administration in DNS of the
instance name ins="lampxxxx".
Once the individual endpoints are registered, the group needs to be
registered. Because the presence sensor sends one multicast message
to the luminaries, all lamps in the group need to have an identical
path. This path is created on the two luminaries using the batch
command defined in [I-D.ietf-core-interfaces]. The path to a batch
of lamps is defined as: /light/grp1. In the example below, two
endpoints are updated with an additional resource using the path
/light/grp1 on the two luminaries.
Req: POST
coap://[FDFD::ABCD:1]/light/grp1
(content-type:application/link-format)light/middle, light/left
Res: 2.04 Changed
Req: POST
coap://[FDFD::ABCD:2]/light/grp1
(content-type:application/link-format)light/right
Res: 2.04 Changed
The group is specified in the RD. The Context parameter is set to
the site-local multicast address allocated to the group. In the POST
in the example below, these two end-points and the end-point of the
presence sensor are registered as members of the group.
It is expected that Standards Developing Organization (SDO) may
develop other special purpose protocols to specify additional group
links, group membership, group names and other parameters in the
individual nodes.
Req: POST coap://[FDFD::ABCD:0]/rd-group
?gp=grp_R2-4-015;con="FF05::1";exp; ins="grp1234"
Payload:
<>ep=lm_R2-4-015_wndw,
<>ep=lm_R2-4-015_door,
<>ep=ps_R2-4-015_door
Res: 2.01 Created
Location: /rd-group/501
After the filling of the RD by the CT, the application in the
luminaries can learn to which groups they belong, and enable their
interface for the multicast address.
The luminary, knowing its domain, queries the RD for the end-point
with rt=light and d=R2-4-015. The RD returns all end-points in the
domain.
Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep
?d=R2-4-015; rt=light
Res: 2.05 Content
<coap://[FDFD::ABCD:1]>;
ep="lm_R2-4-015_wndw",
<coap://[FDFD::ABCD:2]>;
ep="lm_R2-4-015_door"
Knowing its own IPv6 address, the luminary discovers its endpoint
name. With the end-point name the luminary queries the RD for all
groups to which the end-point belongs.
Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp
?ep=lm_R2-4-015_wndw
Res: 2.05 Content
</rd-group/501;gp="grp_R2-4-015";con="FF05::1"
From the context parameter value, the luminary learns the multicast
address of the multicast group.
Alternatively, the CT can communicate the multicast address directly
to the luminaries by using the "coap-group" resource specified in
[RFC7390].
Req: POST //[FDFD::ABCD:1]/coap-group
Content-Format: application/coap-group+json
{ "a": "[FF05::1]" }
{ "n": "grp_R2-4-015"}
Res: 2.01 Created
Location-Path: /coap-group/1
Dependent on the situation only the address ,"a", or the name, "n",
is specified in the coap-group resource. Instead of the RD group
name also the DNS group name can be used.
12.1.3. DNS entries
The network manager assigns the domain bc.example.com to the entries
coming from the RD. The agent that looks up the resource directory
uses the domain name bc.example.com as prescribed, to enter the
services and hosts into the DNS.
The agent does a lookup as specified in Section 9.6. The RD returns
all entries annotated with "exp". The agent subsequently registers
the following DNS-SD RRs:
lm_R2-4-015_wndw.bc.example.com. IN AAAA FDFD::ABCD:1
lm_R2-4-015_door.bc.example.com. IN AAAA FDFD::ABCD:2
ps_R2-4-015_door.bc.example.com. IN AAAA FDFD::ABCD:3
_light._udp.bc.example.com IN PTR
lamp1111._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR
lamp2222._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR
lamp3333._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR
lamp4444._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR
lamp5555._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR
lamp6666._light._udp.bc.example.com
_p-sensor._udp.bc.example.com IN PTR
pres12324._p-sensor._udp.bc.example.com
lamp1111._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_door.bc.example.com.
lamp1111._light._udp.bc.example.com IN TXT
txtver=1;path=/light/left
lamp2222._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_door.bc.example.com.
lamp2222._light._udp.bc.example.com IN TXT
txtver=1;path=/light/middle
lamp3333._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_door.bc.example.com.
lamp3333._light._udp.bc.example.com IN TXT
txtver=1;path=/light/right
lamp4444._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_wndw.bc.example.com.
lamp4444._light._udp.bc.example.com IN TXT
txtver=1;path=/light/left
lamp5555._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_wndw.bc.example.com.
lamp5555._light._udp.bc.example.com IN TXT
txtver=1;path=/light/middle
lamp6666._light._udp.bc.example.com IN SRV 0 0 5678
lm_R2-4-015_wndw.bc.example.com.
lamp6666._light._udp.bc.example.com IN TXT
txtver=1;path=/light/right
pres1234._p-sensor._udp.bc.example.com IN SRV 0 0 5678
ps_R2-4-015_door.bc.example.com.
pres1234._p-sensor._udp.bc.example.com IN TXT
txtver=1;path=/ps
To ask for all lamps is equivalent to returning all PTR RR with label
_light.udp.bc.example.com. from the DNS. When it is required to
filter on the rd=R2-4-015 value in the DNS, additional PTR RRs have
to be entered into the DNS.
R2-4-015._light._udp.bc.example.com IN PTR
lamp1111._light._udp.bc.example.com
R2-4-015._light._udp.bc.example.com IN PTR
lamp2222._light._udp.bc.example.com
R2-4-015._light._udp.bc.example.com IN PTR
lamp3333._light._udp.bc.example.com
R2-4-015._light._udp.bc.example.com IN PTR
lamp4444._light._udp.bc.example.com
R2-4-015._light._udp.bc.example.com IN PTR
lamp5555._light._udp.bc.example.com
R2-4-015._light._udp.bc.example.com IN PTR
lamp6666._light._udp.bc.example.com
Returning all PTR RRs with label R2-4-015._light._udp.bc.example.com
provides all service instances within the domain R2-4-015. This
filtering can be handy when there are many rooms. In the example
there is only one room, making the filtering superfluous.
The agent can also discover groups that need to be discovered. It
queries RD to return all groups which are exported.
Req: GET /rd-lookup/gp?exp
Res: 2.05 Content
<coap://[FF05::1]/>; exp; gp="grp_R2-4-015; ins="grp1234";
ep="lm_R2-4-015_wndw";
ep="lm_R2-4-015_door
The group with FQDN grp_R2-4-015.bc.example.com can be entered into
the DNS by the agent. The accompanying instance name is grp1234.
The <ServiceType> is chosen to be _group._udp. The agent enters the
following RRs into the DNS.
grp_R2-4-015.bc.example.com. IN AAAA FF05::1
_group._udp.bc.example.com IN PTR
grp1234._group._udp.bc.example.com
grp1234._group._udp.bc.example.com IN SRV 0 0 5678
grp_R2-4-015_door.bc.example.com.
grp1234._group._udp.bc.example.com IN TXT
txtver=1;path=/light/grp1
12.1.4. RD Operation
The specification of the group can be used by devices other than the
luminaries and the sensor to learn the multicast address of the group
in a given room. For example a smart phone may be used to adjust the
lamps in the room.
After entry into the room, on request of the user, the smart phone
queries the presence of RDs and may display all the domain names
found on the RDs. The user can, for example, scroll all domains
(room names in this case) and select the room that he entered. After
selection the phone shows all groups in the selected room with their
members. Selecting a group, the user can dim, switch on/off the
group of lights, or possibly even create temporary new groups.
In all examples the SLAAC IPv6 address can be exchanged with the
FQDN, when a connection to DNS exists. Using the FQDN, a node learns
the interface's IPv6 address, or the group's multicast address from
DNS. In the same way the presence sensor can learn the multicast
address to which it should send its presence messages.
12.2. OMA Lightweight M2M (LWM2M) Example
This example shows how the OMA LWM2M specification makes use of
Resource Directory (RD).
OMA LWM2M is a profile for device services based on CoAP, CoRE RD,
and other IETF RFCs and drafts. LWM2M defines a simple object model
and a number of abstract interfaces and operations for device
management and device service enablement.
An LWM2M server is an instance of an LWM2M middleware service layer,
containing a Resource Directory along with other LWM2M interfaces
defined by the LWM2M specification.
CoRE Resource Directory (RD) is used to provide the LWM2M
Registration interface.
LWM2M does not provide for registration domains and does not
currently use the rd-group or rd-lookup interfaces.
The LWM2M specification describes a set of interfaces and a resource
model used between a LWM2M device and an LWM2M server. Other
interfaces, proxies, applications, and function sets are currently
out of scope for LWM2M.
The location of the LWM2M Server and RD Function Set is provided by
the LWM2M Bootstrap process, so no dynamic discovery of the RD
function set is used. LWM2M Servers and endpoints are not required
to implement the ./well-known/core resource.
12.2.1. The LWM2M Object Model
The OMA LWM2M object model is based on a simple 2 level class
hierarchy consisting of Objects and Resources.
An LWM2M Resource is a REST endpoint, allowed to be a single value or
an array of values of the same data type.
An LWM2M Object is a resource template and container type that
encapsulates a set of related resources. An LWM2M Object represents
a specific type of information source; for example, there is a LWM2M
Device Management object that represents a network connection,
containing resources that represent individual properties like radio
signal strength.
Since there may potentially be more than one of a given type object,
for example more than one network connection, LWM2M defines instances
of objects that contain the resources that represent a specific
physical thing.
The URI template for LWM2M consists of a base URI followed by Object,
Instance, and Resource IDs:
/{base-uri}/{object-id}/{instance-id}/{resource-id}
LWM2M IDs are 16 bit numbers represented in decimal by URI format
strings. For example, a LWM2M URI might be:
/1/0/1
The base uri is "/", the Object ID is 1, the instance ID is 0, and
the resource ID is 1. This example URI points to internal resource
1, which represents the registration lifetime configured, in instance
0 of a type 1 object (LWM2M Server Object).
12.2.2. LWM2M Register Endpoint
LWM2M defines a registration interface based on the Resource
Directory Function Set, described in Section 5. The URI of the LWM2M
Resource Directory function set is specified to be "/rd" as
recommended in Section 5.2.
LWM2M endpoints register object IDs, for example </1>, to indicate
that a particular object type is supported, and register object
instances, for example </1/0>, to indicate that a particular instance
of that object type exists.
Resources within the LWM2M object instance are not registered with
the RD, but may be discovered by reading the resource links from the
object instance using GET with a CoAP Content-Format of application/
link-format. Resources may also be read as a structured object by
performing a GET to the object instance with a Content-Format of
senml+json.
When an LWM2M object or instance is registered, this indicates to the
LWM2M server that the object and it's resources are available for
management and service enablement (REST API) operations.
LWM2M endpoints may use the following RD registration parameters as
defined in Table 1 :
ep - Endpoint Name
lt - registration lifetime
Endpoint Name is mandatory, all other registration parameters are
optional.
Additional optional LWM2M registration parameters are defined:
+------------+-------+-------------------------------+--------------+
| Name | Query | Validity | Description |
+------------+-------+-------------------------------+--------------+
| Protocol | b | {"U",UQ","S","SQ","US","UQS"} | Available |
| Binding | | | Protocols |
| | | | |
| LWM2M | ver | 1.0 | Spec Version |
| Version | | | |
| | | | |
| SMS Number | sms | | MSISDN |
+------------+-------+-------------------------------+--------------+
Table 5: LWM2M Additional Registration Parameters
The following RD registration parameters are not currently specified
for use in LWM2M:
et - Endpoint Type
con - Context
The endpoint registration must include a payload containing links to
all supported objects and existing object instances, optionally
including the appropriate link-format relations.
Here is an example LWM2M registration payload:
</1>,</1/0>,</3/0>,</5>
This link format payload indicates that object ID 1 (LWM2M Server
Object) is supported, with a single instance 0 existing, object ID 3
(LWM2M Device object) is supported, with a single instance 0
existing, and object 5 (LWM2M Firmware Object) is supported, with no
existing instances.
12.2.3. Alternate Base URI
If the LWM2M endpoint exposes objects at a base URI other that "/",
the endpoint must register the base URI using rt="oma.lwm2m". An
example link payload using alternate base URI would be:
</my_lwm2m>;rt="oma.lwm2m",</my_lwm2m/1>,<my_lwm2m/1/0>,<my_lwm2m/5>
This link payload indicates that the lwm2m objects will be placed
under the base URI "/my_lwm2m" and that object ID 1 (server) is
supported, with a single instance 0 existing, and object 5 (firmware
update) is supported.
12.2.4. LWM2M Update Endpoint Registration
An LWM2M Registration update proceeds as described in Section 5.3,
and adds some optional parameter updates:
lt - Registration Lifetime
b - Protocol Binding
sms - MSISDN
link payload - new or modified links
A Registration update is also specified to be used to update the
LWM2M server whenever the endpoint's UDP port or IP address are
changed.
12.2.5. LWM2M De-Register Endpoint
LWM2M allows for de-registration using the delete method on the
returned location from the initial registration operation. LWM2M de-
registration proceeds as described in Section 5.4.
13. Acknowledgments 13. Acknowledgments
Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Peter van der Stok, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt,
Anders Brandt, Matthieu Vial, Michael Koster, Mohit Sethi, Sampo Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided
Ukkola and Linyi Tian have provided helpful comments, discussions and helpful comments, discussions and ideas to improve and shape this
ideas to improve and shape this document. Zach would also like to document. Zach would also like to thank his colleagues from the EU
thank his collagues from the EU FP7 SENSEI project, where many of the FP7 SENSEI project, where many of the resource directory concepts
resource directory concepts were originally developed. were originally developed.
14. Changelog 14. Changelog
Changes from -02 to -03:
o Added an example for lighting and DNS integration
o Added an example for RD use in OMA LWM2M
o Added Read Links operation for link inspection by endpoints
o Expanded DNS-SD section
o Added draft authors Peter van der Stok and Michael Koster
Changes from -01 to -02: Changes from -01 to -02:
o Added a catalogue use case. o Added a catalogue use case.
o Changed the registration update to a POST with optional link o Changed the registration update to a POST with optional link
format payload. Removed the endpoint type update from the update. format payload. Removed the endpoint type update from the update.
o Additional examples section added for more complex use cases. o Additional examples section added for more complex use cases.
o New DNS-SD mapping section. o New DNS-SD mapping section.
o Added text on endpoint identification and authentication. o Added text on endpoint identification and authentication.
o Error code 4.04 added to Registration Update and Delete o Error code 4.04 added to Registration Update and Delete requests.
requests.
o Made 63 bytes a SHOULD rather than a MUST for endpoint name and o Made 63 bytes a SHOULD rather than a MUST for endpoint name and
resource type parameters. resource type parameters.
Changes from -00 to -01: Changes from -00 to -01:
o Removed the ETag validation feature. o Removed the ETag validation feature.
o Place holder for the DNS-SD mapping section. o Place holder for the DNS-SD mapping section.
o Explicitly disabled GET or POST on returned Location. o Explicitly disabled GET or POST on returned Location.
o New registry for RD parameters. o New registry for RD parameters.
o Added support for the JSON Link Format. o Added support for the JSON Link Format.
o Added reference to the Groupcomm WG draft. o Added reference to the Groupcomm WG draft.
Changes from -05 to WG Document -00: Changes from -05 to WG Document -00:
o Updated the version and date. o Updated the version and date.
Changes from -04 to -05: Changes from -04 to -05:
o Restricted Update to parameter updates. o Restricted Update to parameter updates.
o Added pagination support for the Lookup interface. o Added pagination support for the Lookup interface.
o Minor editing, bug fixes and reference updates. o Minor editing, bug fixes and reference updates.
o Added group support. o Added group support.
o Changed rt to et for the registration and update interface. o Changed rt to et for the registration and update interface.
Changes from -03 to -04: Changes from -03 to -04:
o Added the ins= parameter back for the DNS-SD mapping. o Added the ins= parameter back for the DNS-SD mapping.
o Integrated the Simple Directory Discovery from Carsten. o Integrated the Simple Directory Discovery from Carsten.
o Editorial improvements. o Editorial improvements.
o Fixed the use of ETags. o Fixed the use of ETags.
Changes from -02 to -03: Changes from -02 to -03:
o Changed the endpoint name back to a single registration o Changed the endpoint name back to a single registration parameter
parameter ep= and removed the h= and ins= parameters. ep= and removed the h= and ins= parameters.
o Updated REST interface descriptions to use RFC6570 URI Template o Updated REST interface descriptions to use RFC6570 URI Template
format. format.
o Introduced an improved RD Lookup design as its own function set. o Introduced an improved RD Lookup design as its own function set.
o Improved the security considerations section. o Improved the security considerations section.
o Made the POST registration interface idempotent by requiring the o Made the POST registration interface idempotent by requiring the
ep= parameter to be present. ep= parameter to be present.
Changes from -01 to -02: Changes from -01 to -02:
o Added a terminology section. o Added a terminology section.
o Changed the inclusion of an ETag in registration or update to a o Changed the inclusion of an ETag in registration or update to a
MAY. MAY.
o Added the concept of an RD Domain and a registration parameter o Added the concept of an RD Domain and a registration parameter for
for it. it.
o Recommended the Location returned from a registration to be o Recommended the Location returned from a registration to be
stable, allowing for endpoint and Domain information to be changed stable, allowing for endpoint and Domain information to be changed
during updates. during updates.
o Changed the lookup interface to accept endpoint and Domain as o Changed the lookup interface to accept endpoint and Domain as
query string parameters to control the scope of a lookup. query string parameters to control the scope of a lookup.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-core-links-json] [I-D.ietf-core-links-json]
Bormann, C., "Representing CoRE Link Collections in JSON", Bormann, C., "Representing CoRE Link Collections in JSON",
draft-ietf-core-links-json-02 (work in progress), draft-ietf-core-links-json-02 (work in progress), July
July 2014. 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165, RFC
RFC 6335, August 2011. 6335, August 2011.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, March 2012. and D. Orchard, "URI Template", RFC 6570, March 2012.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012. Format", RFC 6690, August 2012.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, February 2013. Discovery", RFC 6763, February 2013.
15.2. Informative References 15.2. Informative References
[I-D.ietf-core-groupcomm] [I-D.ietf-core-interfaces]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf-
draft-ietf-core-groupcomm-25 (work in progress), core-interfaces-02 (work in progress), November 2014.
September 2014.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008. Interchange", RFC 5198, March 2008.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
June 2014. 2014.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, June 2014. Application Protocol (CoAP)", RFC 7252, June 2014.
[RFC7390] Rahman, A. and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390,
October 2014.
Authors' Addresses Authors' Addresses
Zach Shelby Zach Shelby
ARM ARM
150 Rose Orchard 150 Rose Orchard
San Jose 95134 San Jose 95134
FINLAND USA
Phone: +1-408-203-9434 Phone: +1-408-203-9434
Email: zach.shelby@arm.com Email: zach.shelby@arm.com
Michael Koster
ARM
150 Rose Orchard
San Jose 95134
USA
Phone: +1-408-576-1500 x11516
Email: Michael.Koster@arm.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Peter van der Stok
consultant
Phone: +31-492474673 (Netherlands), +33-966015248 (France)
Email: consultancy@vanderstok.org
URI: www.vanderstok.org
 End of changes. 101 change blocks. 
186 lines changed or deleted 817 lines changed or added

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