draft-ietf-core-resource-directory-03.txt   draft-ietf-core-resource-directory-04.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft M. Koster Internet-Draft M. Koster
Intended status: Standards Track ARM Intended status: Standards Track ARM
Expires: December 24, 2015 C. Bormann Expires: January 7, 2016 C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
P. van der Stok P. van der Stok
consultant consultant
June 22, 2015 July 06, 2015
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-03 draft-ietf-core-resource-directory-04
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 December 24, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 17 5.5. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 17
6. Group Function Set . . . . . . . . . . . . . . . . . . . . . 18 6. Group Function Set . . . . . . . . . . . . . . . . . . . . . 18
6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 18 6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 18
6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 20
7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 21 7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 21
8. New Link-Format Attributes . . . . . . . . . . . . . . . . . 25 8. New Link-Format Attributes . . . . . . . . . . . . . . . . . 25
8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 25 8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 25
8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 25 8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 25
9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 25 9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 26 9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 26
9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 27 9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 27
9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 27 9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 28
9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 28 9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 28
9.5. TXT Record key=value strings . . . . . . . . . . . . . . 28 9.5. TXT Record key=value strings . . . . . . . . . . . . . . 28
9.6. Importing resource links into DNS-SD . . . . . . . . . . 28 9.6. Importing resource links into DNS-SD . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30
10.1. Endpoint Identification and Authentication . . . . . . . 30 10.1. Endpoint Identification and Authentication . . . . . . . 30
10.2. Access Control . . . . . . . . . . . . . . . . . . . . . 30 10.2. Access Control . . . . . . . . . . . . . . . . . . . . . 30
10.3. Denial of Service Attacks . . . . . . . . . . . . . . . 30 10.3. Denial of Service Attacks . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 31 11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 31
11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 31 11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 31
11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 31 11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 31
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Lighting Installation . . . . . . . . . . . . . . . . . 32 12.1. Lighting Installation . . . . . . . . . . . . . . . . . 32
12.1.1. Installation Characteristics . . . . . . . . . . . . 32 12.1.1. Installation Characteristics . . . . . . . . . . . . 32
12.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 34 12.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 34
12.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 37 12.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 37
12.1.4. RD Operation . . . . . . . . . . . . . . . . . . . . 41 12.1.4. RD Operation . . . . . . . . . . . . . . . . . . . . 40
12.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 41 12.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 40
12.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 42 12.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 41
12.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 42 12.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 42
12.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 44 12.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 43
12.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 44 12.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 44
12.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 44 12.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 45 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
15.1. Normative References . . . . . . . . . . . . . . . . . . 47 15.1. Normative References . . . . . . . . . . . . . . . . . . 47
15.2. Informative References . . . . . . . . . . . . . . . . . 48 15.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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.
skipping to change at page 5, line 32 skipping to change at page 5, line 32
directory entries on the RD, which are soft state and need to be directory entries on the RD, which are soft state and need to be
periodically refreshed. An endpoint is provided with interfaces to periodically refreshed. An endpoint is provided with interfaces to
register, update and remove a resource directory entry. Furthermore, register, update and remove a resource directory entry. Furthermore,
a mechanism to discover an RD using the CoRE Link Format is defined. a mechanism to discover an RD using the CoRE Link Format is defined.
It is also possible for an RD to proactively discover Web Links from It is also possible for an RD to proactively discover Web Links from
endpoints and add them as resource directory entries. A lookup endpoints and add them as resource directory entries. A lookup
interface for discovering any of the Web Links held in the RD is interface for discovering any of the Web Links held in the RD is
provided using the CoRE Link Format. provided using the CoRE Link Format.
Registration Lookup, Group Registration Lookup, Group
Interface Interfaces
+----+ | | +----+ | |
| EP |---- | | | EP |---- | |
+----+ ---- | | +----+ ---- | |
--|- +------+ | --|- +------+ |
+----+ | ----| | | +--------+ +----+ | ----| | | +--------+
| EP | ---------|-----| RD |----|-----| Client | | EP | ---------|-----| RD |----|-----| Client |
+----+ | ----| | | +--------+ +----+ | ----| | | +--------+
--|- +------+ | --|- +------+ |
+----+ ---- | | +----+ ---- | |
| EP |---- | | | EP |---- | |
skipping to change at page 6, line 47 skipping to change at page 6, line 47
(machines -- endpoints) capable of providing required information at (machines -- endpoints) capable of providing required information at
a given time or acting on instructions from the end users. a given time or acting on instructions from the end users.
In a typical scenario, during a boot-up procedure (and periodically In a typical scenario, during a boot-up procedure (and periodically
afterwards), the machines (endpoints) register with a Resource afterwards), the machines (endpoints) register with a Resource
Directory (for example EPs installed on vehicles enabling tracking of Directory (for example EPs installed on vehicles enabling tracking of
their position for fleet management purposes and monitoring their position for fleet management purposes and monitoring
environment parameters) hosted by the mobile operator or somewhere environment parameters) hosted by the mobile operator or somewhere
else in the network, periodically a description of its own else in the network, periodically a description of its own
capabilities. Due to the usual network configuration of mobile capabilities. Due to the usual network configuration of mobile
networks, the EPs attached to the mobile network do not have routable networks, the EPs attached to the mobile network may not always be
addresses. Therefore, a remote server is usually used to provide efficiently reachable. Therefore, a remote server is usually used to
proxy access to the EPs. The address of each (proxy) endpoint on provide proxy access to the EPs. The address of each (proxy)
this server is included in the resource description stored in the RD. endpoint on this server is included in the resource description
The users, for example mobile applications for environment stored in the RD. The users, for example mobile applications for
monitoring, contact the RD, look-up the endpoints capable of environment monitoring, contact the RD, look-up the endpoints capable
providing information about the environment using appropriate set of of providing information about the environment using appropriate set
link parameters, obtain information on how to contact them (URLs of of link parameters, obtain information on how to contact them (URLs
the proxy server) and then initiate interaction to obtain information of the proxy server) and then initiate interaction to obtain
that is finally processed, displayed on the screen and usually stored information that is finally processed, displayed on the screen and
in a database. Similarly, fleet management systems provide the usually stored in a database. Similarly, fleet management systems
appropriate link parameters to the RD to look-up for EPs deployed on provide the appropriate link parameters to the RD to look-up for EPs
the vehicles the application is responsible for. deployed on the vehicles the application is responsible for.
3.2. Use Case: Home and Building Automation 3.2. Use Case: Home and Building Automation
Home and commercial building automation systems can benefit from the Home and commercial building automation systems can benefit from the
use of M2M web services. The discovery requirements of these use of M2M web services. The discovery requirements of these
applications are demanding. Home automation usually relies on run- applications are demanding. Home automation usually relies on run-
time discovery to commission the system, whereas in building time discovery to commission the system, whereas in building
automation a combination of professional commissioning and run-time automation a combination of professional commissioning and run-time
discovery is used. Both home and building automation involve peer- discovery is used. Both home and building automation involve peer-
to-peer interactions between endpoints, and involve battery-powered to-peer interactions between endpoints, and involve battery-powered
skipping to change at page 7, line 49 skipping to change at page 7, line 49
public consumption may provide the data to an intermediary server, or public consumption may provide the data to an intermediary server, or
broker. Sensor data are published to the intermediary upon changes broker. Sensor data are published to the intermediary upon changes
or at regular intervals. Descriptions of the sensors that resolve to or at regular intervals. Descriptions of the sensors that resolve to
links to sensor data may be published to a Resource Directory. links to sensor data may be published to a Resource Directory.
Applications wishing to consume the data can use the Resource Applications wishing to consume the data can use the Resource
Directory lookup function set to discover and resolve links to the Directory lookup function set to discover and resolve links to the
desired resources and endpoints. The Resource Directory service need desired resources and endpoints. The Resource Directory service need
not be coupled with the data intermediary service. Mapping of not be coupled with the data intermediary service. Mapping of
Resource Directories to data intermediaries may be many-to-many. Resource Directories to data intermediaries may be many-to-many.
Metadata in link-format or link-format+json representations are Metadata in link-format, link-format+cbor, or link-format+json
supplied by Resource Directories, which may be internally stored as representations are supplied by Resource Directories, which may be
triples, or relation/attribute pairs providing metadata about internally stored as triples, or relation/attribute pairs providing
resource links. External catalogs that are represented in other metadata about resource links. External catalogs that are
formats may be converted to link-format or link-format+json for represented in other formats may be converted to link-format, link-
storage and access by Resource Directories. Since it is common format+json, or link-format+cbor for storage and access by Resource
practice for these to be URN encoded, simple and lossless structural Directories. Since it is common practice for these to be URN
transforms will generally be sufficient to store external metadata in encoded, simple and lossless structural transforms will generally be
Resource Directories. sufficient to store external metadata in 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
skipping to change at page 9, line 40 skipping to change at page 9, line 40
o specific static configuration (e.g., anycast addresses), if any, o specific static configuration (e.g., anycast addresses), if any,
o the ABRO option of 6LoWPAN-ND [RFC6775], o the ABRO option of 6LoWPAN-ND [RFC6775],
o other ND options that happen to point to servers (such as RDNSS), o other ND options that happen to point to servers (such as RDNSS),
o DHCPv6 options that might be defined later. o DHCPv6 options that might be defined later.
In networks with more inexpensive use of multicast, the candidate IP In networks with more inexpensive use of multicast, the candidate IP
address may be a well-known multicast address, i.e. directory servers address may be a well-known multicast address, i.e. directory servers
are found by simply sending POST requests to that well-known are found by simply sending GET requests to that well-known multicast
multicast address (details TBD). address (see Section 5.1).
As some of these sources are just (more or less educated) guesses, As some of these sources are just (more or less educated) guesses,
endpoints MUST make use of any error messages to very strictly rate- endpoints MUST make use of any error messages to very strictly rate-
limit requests to candidate IP addresses that don't work out. For limit requests to candidate IP addresses that don't work out. For
example, an ICMP Destination Unreachable message (and, in particular, example, an ICMP Destination Unreachable message (and, in particular,
the port unreachable code for this message) may indicate the lack of the port unreachable code for this message) may indicate the lack of
a CoAP server on the candidate host, or a CoAP error response code a CoAP server on the candidate host, or a CoAP error response code
such as 4.05 "Method Not Allowed" may indicate unwillingness of a such as 4.05 "Method Not Allowed" may indicate unwillingness of a
CoAP server to act as a directory server. CoAP server to act as a directory server.
skipping to change at page 10, line 23 skipping to change at page 10, line 23
tool. The installation tool can fill the Resource Directory from a tool. The installation tool can fill the Resource Directory from a
database or other means. For that purpose the scheme, IP address and database or other means. For that purpose the scheme, IP address and
port of the registered device is indicated in the Context parameter port of the registered device is indicated in the Context parameter
of the registration as well. of the registration as well.
5. Resource Directory Function Set 5. Resource Directory Function Set
This section defines the REST interfaces between an RD and endpoints, This section defines the REST interfaces between an RD and endpoints,
which is called the Resource Directory Function Set. Although the which is called the Resource Directory Function Set. Although the
examples throughout this section assume the use of CoAP [RFC7252], examples throughout this section assume the use of CoAP [RFC7252],
these REST interfaces can also be realized using HTTP [RFC7230]. An these REST interfaces can also be realized using HTTP [RFC7230]. In
RD implementing this specification MUST support the discovery, all definitions in this section, both CoAP response codes (with dot
notation) and HTTP response codes (without dot notation) are shown.
An RD implementing this specification MUST support the discovery,
registration, update, lookup, and removal interfaces defined in this registration, update, lookup, and removal interfaces defined in this
section. section.
Resource directory entries are designed to be easily exported to Resource directory entries are designed to be easily exported to
other discovery mechanisms such as DNS-SD. For that reason, other discovery mechanisms such as DNS-SD. For that reason,
parameters that would meaningfully be mapped to DNS SHOULD be limited parameters that would meaningfully be mapped to DNS SHOULD be limited
to a maximum length of 63 bytes. to a maximum length of 63 bytes.
5.1. Discovery 5.1. Discovery
skipping to change at page 11, line 27 skipping to change at page 11, line 28
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 "core.rd", rt := Resource Type (optional). MAY contain the value "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)
Content-Type: application/link-format+json (if any)
Content-Type: application/link-format+cbor (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" or 200 "OK" with an application/link-format,
containing one or more matching entries for the RD resource. application/link-format+json, or application/link-format+cbor
payload 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" or 404 "Not Found" is returned in case no
found for a unicast request. matching entry is found for a unicast request.
Failure: 4.00 "Bad Request" is returned in case of a malformed Failure: 4.00 "Bad Request" or 400 "Bad Request" is returned in case
request for a unicast request. of a malformed request for a unicast request.
Failure: No error response to a multicast request. Failure: No error response to a multicast request.
The following example shows an endpoint discovering an RD using this The following example shows an endpoint discovering an RD using this
interface, thus learning that the base RD resource is, in this interface, thus learning that the base RD resource is, in this
example, at /rd. Note that it is up to the RD to choose its base RD example, at /rd. Note that it is up to the RD to choose its base RD
resource, although diagnostics and debugging is facilitated by using resource, although diagnostics and debugging is facilitated by using
the base paths specified here where possible. the base paths specified here where possible.
EP RD EP RD
| | | |
| ----- GET /.well-known/core?rt=core.rd* ------> | | ----- GET /.well-known/core?rt=core.rd* ------> |
| | | |
| | | |
| <---- 2.05 Content "</rd>; rt="core.rd" ------ | | <---- 2.05 Content "</rd>;rt="core.rd" ------- |
| | | |
Req: GET coap://[ff02::1]/.well-known/core?rt=core.rd* Req: GET coap://[ff02::1]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
</rd>;rt="core.rd", </rd>;rt="core.rd",
</rd-lookup>;rt="core.rd-lookup", </rd-lookup>;rt="core.rd-lookup",
</rd-group>;rt="core.rd-group" </rd-group>;rt="core.rd-group"
5.2. Registration 5.2. Registration
After discovering the location of an RD Function Set, an endpoint MAY After discovering the location of an RD Function Set, an endpoint MAY
register its resources using the registration interface. This register its resources using the registration interface. This
interface accepts a POST from an endpoint containing the list of interface accepts a POST from an endpoint containing the list of
resources to be added to the directory as the message payload in the resources to be added to the directory as the message payload in the
CoRE Link Format [RFC6690] or JSON Link Format CoRE Link Format [RFC6690], JSON CoRE Link Format
[I-D.ietf-core-links-json] along with query string parameters [I-D.ietf-core-links-json], or CBOR CoRE Link Format (application/
indicating the name of the endpoint, its domain and the lifetime of link-format+cbor) along with query string parameters indicating the
the registration. All parameters except the endpoint name are name of the endpoint, its domain and the lifetime of the
optional. It is expected that other specifications will define registration. All parameters except the endpoint name are optional.
further parameters (see Section 11.3). The RD then creates a new It is expected that other specifications will define further
resource or updates an existing resource in the RD and returns its parameters (see Section 11.3). The RD then creates a new resource or
location. An endpoint MUST use that location when refreshing updates an existing resource in the RD and returns its location. An
registrations using this interface. Endpoint resources in the RD are endpoint MUST use that location when refreshing registrations using
kept active for the period indicated by the lifetime parameter. The this interface. Endpoint resources in the RD are kept active for the
endpoint is responsible for refreshing the entry within this period period indicated by the lifetime parameter. The endpoint is
using either the registration or update interface. The registration responsible for refreshing the entry within this period using either
interface MUST be implemented to be idempotent, so that registering the registration or update interface. The registration interface
twice with the same endpoint parameter does not create multiple RD MUST be implemented to be idempotent, so that registering twice with
entries. the same endpoint parameter does not create multiple RD entries.
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 name (mandatory). The endpoint name is an
the registering node, unique within that domain. The maximum identifier that MUST be unique within a 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
skipping to change at page 13, line 40 skipping to change at page 13, line 40
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
Content-Type: application/link-format+cbor
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created". The Location header MUST be included with Success: 2.01 "Created" or 201 "Created". The Location header MUST
the new resource entry for the endpoint. This Location MUST be a be included with the new resource entry for the endpoint. This
stable identifier generated by the RD as it is used for all Location MUST be a stable identifier generated by the RD as it is
subsequent operations on this registration. The resource returned used for all subsequent operations on this registration. The
in the Location is only for the purpose of the Update (POST) and resource returned in the Location is only for the purpose of the
Removal (DELETE), and MUST NOT implement GET or PUT methods. Update (POST) and Removal (DELETE), and MUST NOT implement GET or
PUT methods.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following example shows an endpoint with the name "node1" The following example shows an endpoint with the name "node1"
registering two resources to an RD using this interface. The registering two resources to an RD using this interface. The
resulting location /rd/4521 is just an example of an RD generated resulting location /rd/4521 is just an example of an RD generated
location. location.
EP RD EP RD
| | | |
| --- POST /rd?ep=node1 "</sensors..." -------> | | --- POST /rd?ep=node1 "</sensors..." -------> |
| | | |
skipping to change at page 15, line 25 skipping to change at page 15, line 32
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)
Content-Type: application/link-format+cbor (optional)
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.04 "Changed" in the update was successfully processed. Success: 2.04 "Changed" 0r 204 "No Content" in the update was
successfully processed.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not
have expired). exist (e.g. may have expired).
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following example shows an endpoint updating its registration at The following example shows an endpoint updating its registration at
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 ---------------------------- |
skipping to change at page 16, line 28 skipping to change at page 16, line 40
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" or 204 "No Content" upon successful deletion
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad request". Malformed
request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not
have expired). exist (e.g. may have expired).
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following examples shows successful removal of the endpoint from The following examples shows successful removal of the endpoint from
the RD. the RD.
EP RD EP RD
| | | |
| --- DELETE /rd/4521 ------------------------> | | --- DELETE /rd/4521 ------------------------> |
| | | |
| | | |
| <-- 2.02 Deleted ---------------------------- | | <-- 2.02 Deleted ---------------------------- |
skipping to change at page 17, line 26 skipping to change at page 17, line 38
URI Template: /{+location}{?rt,if,ct} URI Template: /{+location}{?rt,if,ct}
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.05 "Content" upon success Success: 2.05 "Content" or 200 "OK" upon success with an
"application/link-format", "application/link-format+cbor", or
"application/link-format+json" payload.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 4.04 "Not Found". Registration does not exist (e.g. may Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not
have expired). exist (e.g. may have expired).
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following examples show successful read of the endpoint links The following examples show successful read of the endpoint links
from the RD. from the RD.
EP RD EP RD
| | | |
| --- GET /rd/4521 ------------------------> | | --- GET /rd/4521 ------------------------> |
| | | |
| | | |
| <-- 2.05 Content </sensors... ---------------- | | <-- 2.05 Content </sensors... ---------------- |
skipping to change at page 19, line 18 skipping to change at page 19, line 33
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
Content-Type: application/link-format+cbor
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created". The Location header MUST be included with Success: 2.01 "Created" or 201 "Created". The Location header MUST
the new group entry. This Location MUST be a stable identifier be included with the new group entry. This Location MUST be a
generated by the RD as it is used for delete operations on this stable identifier generated by the RD as it is used for delete
registration. operations on this registration.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following example shows a group with the name "lights" The following example shows an EP registering a group with the name
registering two endpoints to an RD using this interface. The "lights" which has two endpoints to an RD using this interface. The
resulting location /rd-group/12 is just an example of an RD generated resulting location /rd-group/12 is just an example of an RD generated
group location. group location.
EP RD EP RD
| | | |
| - POST /rd-group?gp=lights "<>;ep=node1..." --> | | - POST /rd-group?gp=lights "<>;ep=node1..." --> |
| | | |
| | | |
| <---- 2.01 Created Location: /rd-group/12 ---- | | <---- 2.01 Created Location: /rd-group/12 ---- |
| | | |
skipping to change at page 20, line 26 skipping to change at page 20, line 42
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" or 204 "No Content" upon successful deletion
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 4.04 "Not Found". Group does not exist. Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist.
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following examples shows successful removal of the group from the The following examples shows successful removal of the group from the
RD. RD.
EP RD EP RD
| | | |
| --- DELETE /rd-group/412 -------------------> | | --- DELETE /rd-group/412 -------------------> |
| | | |
| | | |
| <-- 2.02 Deleted ---------------------------- | | <-- 2.02 Deleted ---------------------------- |
skipping to change at page 21, line 20 skipping to change at page 21, line 35
RDs may also support lookups to return resource descriptions in RDs may also support lookups to return resource descriptions in
alternative formats (e.g. Atom or HTML Link) or using more advanced alternative formats (e.g. Atom or HTML Link) or using more advanced
interfaces (e.g. supporting context or semantic based lookup). interfaces (e.g. supporting context or semantic based lookup).
This function set allows lookups for domains, groups, endpoints and This function set allows lookups for domains, groups, endpoints and
resources using attributes defined in the RD Function Set and for use resources using attributes defined in the RD Function Set and for use
with the CoRE Link Format. The result of a lookup request is the with the CoRE Link Format. The result of a lookup request is the
list of links (if any) corresponding to the type of lookup. Using list of links (if any) corresponding to the type of lookup. Using
the Accept Option, the requester can control whether this list is the Accept Option, the requester can control whether this list is
returned in CoRE Link Format ("application/link-format", default) or returned in CoRE Link Format ("application/link-format", default) or
its JSON form ("application/link-format+json"). The target of these its alternate content-formats ("application/link-format+json" or
links SHOULD be the actual location of the domain, endpoint or "application/link-format+cbor").
resource, but MAY be an intermediate proxy e.g. in the case of an The target of these links SHOULD be the actual location of the
HTTP lookup interface for CoAP endpoints. Multiple query parameters domain, endpoint or resource, but MAY be an intermediate proxy e.g.
MAY be included in a lookup, all included parameters MUST match for a in the case of an HTTP lookup interface for CoAP endpoints. Multiple
resource to be returned. The character '*' MAY be included at the query parameters MAY be included in a lookup, all included parameters
end of a parameter value as a wildcard operator. MUST match for a resource to be returned. The character '*' MAY be
included at the 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}/{lookup- URI Template: /{+rd-lookup-base}/{lookup-
type}{?d,ep,gp,et,rt,page,count,resource-param} type}{?d,ep,gp,et,rt,page,count,resource-param}
URI Template Variables: 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 variable lookup-type := ("d", "ep", "res", "gp") (mandatory) This variable
is used to select the kind of lookup to perform (domain, is used to select the kind of lookup to perform (domain,
endpoint, resource, or group). endpoint, resource, or group).
ep := Endpoint (optional). Used for endpoint, group and resource ep := Endpoint name (optional). Used for endpoint, group and
lookups. resource 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
skipping to change at page 22, line 26 skipping to change at page 22, line 42
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 link resource-param := Link attribute parameters (optional). Any 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" or 200 "OK" with an "application/link-
"application/link-format+json" payload containing a matching format", "application/link-format+cbor", or "application/link-
entries for the lookup. format+json" payload containing matching entries for the lookup.
Failure: 4.04 "Not Found" in case no matching entry is found for a Failure: 4.04 "Not Found" or 404 "Not Found" in case no matching
unicast request. entry is found for a unicast request.
Failure: No error response to a multicast request. Failure: No error response to a multicast request.
Failure: 4.00 "Bad Request". Malformed request. Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 5.03 "Service Unavailable". Service could not perform the Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
operation. Service could not perform the operation.
The following example shows a client performing a resource lookup: The examples in this section assume a host with IP address FDFD::123
and a default CoAP port 61616. The following example shows a client
performing a resource lookup:
Client RD Client RD
| | | |
| ----- GET /rd-lookup/res?rt=temperature -----------------> | | ----- GET /rd-lookup/res?rt=temperature -----------------> |
| | | |
| | | |
| <-- 2.05 Content <coap://{host:port}/temp>;rt="temperature" | | <-- 2.05 Content <coap://[FDFD::123]:61616/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://[FDFD::123]:61616/temp>;rt="temperature"
The following example shows a client performing an endpoint type The following example shows a client performing an endpoint type
lookup: 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://[FDFD::123]:61616>;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://[FDFD::123]:61616>;ep="node5",
<coap://{ip:port}>;ep="node7" <coap://[FDFD::123]:61616>;ep="node7"
The following example shows a client performing a domain lookup: The following example shows a client performing a domain lookup:
Client RD Client RD
| | | |
| ----- GET /rd-lookup/d ----------------------------------> | | ----- GET /rd-lookup/d ----------------------------------> |
| | | |
| | | |
| <-- 2.05 Content </rd>;d=domain1,</rd>;d=domain2 ---------- | | <-- 2.05 Content </rd>;d=domain1,</rd>;d=domain2 ---------- |
| | | |
skipping to change at page 24, line 27 skipping to change at page 24, line 36
</rd-group/12>;gp="lights1";d="example.com" </rd-group/12>;gp="lights1";d="example.com"
The following example shows a client performing a lookup for all The following example shows a client performing a lookup for all
endpoints in a particular group: endpoints in a particular group:
Client RD Client RD
| | | |
| ----- GET /rd-lookup/ep?gp=lights1-----------------------> | | ----- GET /rd-lookup/ep?gp=lights1-----------------------> |
| | | |
| | | |
| <-- 2.05 Content <coap://{host:port}>;ep="node1" ---------- | | <-- 2.05 Content <coap://[FDFD::123]:61616>;ep="node1" ---- |
| | | |
Req: GET /rd-lookup/ep?gp=lights1 Req: GET /rd-lookup/ep?gp=lights1
Res: 2.05 Content Res: 2.05 Content
<coap://{host:port}>;ep="node1", <coap://[FDFD::123]:61616>;ep="node1",
<coap://{host:port}>;ep="node2", <coap://[FDFD::123]:61616>;ep="node2",
The following example shows a client performing a lookup for all The following example shows a client performing a lookup for all
groups an endpoint belongs to: groups an endpoint belongs to:
Client RD Client RD
| | | |
| ----- GET /rd-lookup/gp?ep=node1 ------------------------> | | ----- GET /rd-lookup/gp?ep=node1 -----------------------> |
| | | |
| | | |
| <-- 2.05 Content <coap://{ip:port}>;gp="lights1";ep="node1" | |< 2.05 Content <coap://[FDFD::123]:61616>;gp="lights1"; -- |
| | | ep="node1" ------ |
| |
Req: GET /rd-lookup/gp?ep=node1 Req: GET /rd-lookup/gp?ep=node1
Res: 2.05 Content Res: 2.05 Content
<coap://{ip:port}>;gp="lights1";ep="node1", <coap://[FDFD::123]:61616>;gp="lights1";ep="node1",
8. New Link-Format Attributes 8. New Link-Format Attributes
When using the CoRE Link Format to describe resources being When using the CoRE Link Format to describe resources being
discovered by or posted to a resource directory service, additional discovered by or posted to a resource directory service, additional
information about those resources is useful. This specification information about those resources is useful. This specification
defines the following new attributes for use in the CoRE Link Format defines the following new attributes for use in the CoRE Link Format
[RFC6690]: [RFC6690]:
link-extension = ( "ins" "=" quoted-string ) ; Max 63 bytes link-extension = ( "ins" "=" quoted-string ) ; Max 63 bytes
skipping to change at page 29, line 10 skipping to change at page 29, line 23
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://[FDFD::1234]:61616/light/1>;exp; | | <-- 2.05 Content "<coap://[FDFD::1234]:5683/light/1>;exp; |
| rt="dali.light";ins="FrontSpot" | | rt="dali.light";ins="Spot"; |
| d="office";ep="node1" | | 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]:5683/light/1>;
exp;rt="dali.light";ins="Spot"; exp;rt="dali.light";ins="Spot";
d="office"; ep="node1" d="office";ep="node1"
The agent subsequently registers the following DNS-SD RRs, assuming a The agent subsequently registers the following DNS-SD RRs, assuming a
zone name "example.com" prefixed with "office": zone name "example.com" prefixed with "office":
node1.office.example.com. IN AAAA FDFD::1234 node1.office.example.com. IN AAAA FDFD::1234
_dali._udp.office.example.com IN PTR _dali._udp.office.example.com IN PTR
Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com
light._sub._dali._udp.example.com IN PTR light._sub._dali._udp.example.com IN PTR
Spot._dali._udp.office.example.com Spot._dali._udp.office.example.com
Spot._dali._udp.office.example.com IN SRV 0 0 5678 Spot._dali._udp.office.example.com IN SRV 0 0 5683
node1.office.example.com. node1.office.example.com.
Spot._dali._udp.office.example.com IN TXT Spot._dali._udp.office.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
Spot._dali._udp.office.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:
Spot.light._sub._dali._udp.office.example.com. Spot.light._sub._dali._udp.office.example.com.
10. Security Considerations 10. Security Considerations
skipping to change at page 33, line 4 skipping to change at page 33, line 4
be drawn on the realization of actual installation procedures, be drawn on the realization of actual installation procedures,
because the example "emphasizes" some of the issues that may because the example "emphasizes" some of the issues that may
influence the use of the RD. influence the use of the RD.
12.1.1. Installation Characteristics 12.1.1. Installation Characteristics
The example assumes that the installation is managed. That means The example assumes that the installation is managed. That means
that a Commissioning Tool (CT) is used to authorize the addition of that a Commissioning Tool (CT) is used to authorize the addition of
nodes, name them, and name their services. The CT can be connected 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 to the installation in many ways: the CT can be part of the
installation network, connected by wifi to the installation network, installation network, connected by WiFi to the installation network,
or connected via GPRS link, or other method. or connected via GPRS link, or other method.
It is assumed that there are two naming authorities for the It is assumed that there are two naming authorities for the
installation: (1) the network manager that is responsible for the installation: (1) the network manager that is responsible for the
correct operation of the network and the connected interfaces, and correct operation of the network and the connected interfaces, and
(2) the lighting manager that is responsible for the correct (2) the lighting manager that is responsible for the correct
functioning of networked lights and sensors. The result is the functioning of networked lights and sensors. The result is the
existence of two naming schemes coming from the two managing existence of two naming schemes coming from the two managing
entities. entities.
skipping to change at page 35, line 9 skipping to change at page 35, line 9
| Presence | ps_R2-4-015_door | /ps | p-sensor | | Presence | ps_R2-4-015_door | /ps | p-sensor |
| sensor | | | | | sensor | | | |
+----------------+------------------+---------------+---------------+ +----------------+------------------+---------------+---------------+
Table 4: Resource Directory identifiers Table 4: Resource Directory identifiers
The CT inserts the end-points of the luminaries and the sensor in the The CT inserts the end-points of the luminaries and the sensor in the
RD using the Context parameter (con) to specify the interface RD using the Context parameter (con) to specify the interface
address: address:
Req: POST Req: POST coap://[FDFD::ABCD:0]/rd
coap://[FDFD::ABCD:0]/rd?ep=lm_R2-4-015_wndw ?ep=lm_R2-4-015_wndw&con=coap://[FDFD::ABCD:1]
Payload: Payload:
</light/left>;rt="light"; </light/left>;rt="light";
con="FDFD::ABCD:1"; d="R2-4-015";ins="lamp4444";exp,
d="R2-4-015"; ins="lamp4444"; exp,
</light/middle>;rt="light"; </light/middle>;rt="light";
con="FDFD::ABCD:1"; d="R2-4-015";ins="lamp5555";exp,
d="R2-4-015"; ins="lamp5555"; exp,
</light/right>;rt="light"; </light/right>;rt="light";
con="FDFD::ABCD:1"; d="R2-4-015";ins="lamp6666";exp
d="R2-4-015"; ins="lamp6666"; exp
Res: 2.01 Created Res: 2.01 Created
Location: /rd/4521 Location: /rd/4521
Req: POST coap://[FDFD::ABCD:0]/rd?ep=lm_R2-4-015_door Req: POST coap://[FDFD::ABCD:0]/rd
?ep=lm_R2-4-015_door&con=coap://[FDFD::ABCD:2]
Payload: Payload:
</light/left>;rt="light"; </light/left>;rt="light";
con="FDFD::ABCD:2"; d="R2-4-015";ins="lamp1111";exp,
d="R2-4-015"; ins="lamp1111"; exp,
</light/middle>;rt="light"; </light/middle>;rt="light";
con="FDFD::ABCD:2"; d="R2-4-015";ins="lamp2222";exp,
d="R2-4-015"; ins="lamp2222"; exp,
</light/right>;rt="light"; </light/right>;rt="light";
con="FDFD::ABCD:2"; d="R2-4-015";ins="lamp3333";exp
d="R2-4-015"; ins="lamp3333"; exp
Res: 2.01 Created Res: 2.01 Created
Location: /rd/4522 Location: /rd/4522
Req: POST coap://[FDFD::ABCD:0]/rd?ep=ps_R2-4-015_door Req: POST coap://[FDFD::ABCD:0]/rd
?ep=ps_R2-4-015_door&con=coap://[FDFD::ABCD:3]
Payload: Payload:
</ps>;rt="p-sensor"; </ps>;rt="p-sensor";
con="FDFD::ABCD:3"; d="R2-4-015";ins="pres1234";exp
d="R2-4-015"; ins="pres1234"; exp
Res: 2.01 Created Res: 2.01 Created
Location: /rd/4523 Location: /rd/4523
The domain name d="R2-4-015" has been added for an efficient lookup 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 because filtering on "ep" name is awkward. The same domain name is
communicated to the two luminaries and the presence sensor by the CT. 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 The "exp" attribute is set for the later administration in DNS of the
instance name ins="lampxxxx". instance name ins="lampxxxx".
Once the individual endpoints are registered, the group needs to be Once the individual endpoints are registered, the group needs to be
registered. Because the presence sensor sends one multicast message registered. Because the presence sensor sends one multicast message
to the luminaries, all lamps in the group need to have an identical 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 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 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 of lamps is defined as: /light/grp1. In the example below, two
endpoints are updated with an additional resource using the path endpoints are updated with an additional resource using the path
skipping to change at page 36, line 19 skipping to change at page 36, line 12
registered. Because the presence sensor sends one multicast message registered. Because the presence sensor sends one multicast message
to the luminaries, all lamps in the group need to have an identical 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 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 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 of lamps is defined as: /light/grp1. In the example below, two
endpoints are updated with an additional resource using the path endpoints are updated with an additional resource using the path
/light/grp1 on the two luminaries. /light/grp1 on the two luminaries.
Req: POST Req: POST
coap://[FDFD::ABCD:1]/light/grp1 coap://[FDFD::ABCD:1]/light/grp1
(content-type:application/link-format)light/middle, light/left (content-type:application/link-format)<light/middle>,<light/left>
Res: 2.04 Changed Res: 2.04 Changed
Req: POST Req: POST
coap://[FDFD::ABCD:2]/light/grp1 coap://[FDFD::ABCD:2]/light/grp1
(content-type:application/link-format)light/right (content-type:application/link-format)<light/right>
Res: 2.04 Changed Res: 2.04 Changed
The group is specified in the RD. The Context parameter is set to 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 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 in the example below, these two end-points and the end-point of the
presence sensor are registered as members of the group. presence sensor are registered as members of the group.
It is expected that Standards Developing Organization (SDO) may It is expected that Standards Developing Organizations (SDOs) may
develop other special purpose protocols to specify additional group develop other special purpose protocols to specify additional group
links, group membership, group names and other parameters in the links, group membership, group names and other parameters in the
individual nodes. individual nodes.
Req: POST coap://[FDFD::ABCD:0]/rd-group Req: POST coap://[FDFD::ABCD:0]/rd-group
?gp=grp_R2-4-015;con="FF05::1";exp; ins="grp1234" ?gp=grp_R2-4-015;con="coap//[FF05::1]";exp;ins="grp1234"
Payload: Payload:
<>ep=lm_R2-4-015_wndw, <>ep=lm_R2-4-015_wndw,
<>ep=lm_R2-4-015_door, <>ep=lm_R2-4-015_door,
<>ep=ps_R2-4-015_door <>ep=ps_R2-4-015_door
Res: 2.01 Created Res: 2.01 Created
Location: /rd-group/501 Location: /rd-group/501
After the filling of the RD by the CT, the application in the After the filling of the RD by the CT, the application in the
luminaries can learn to which groups they belong, and enable their luminaries can learn to which groups they belong, and enable their
interface for the multicast address. interface for the multicast address.
The luminary, knowing its domain, queries the RD for the end-point 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 with rt=light and d=R2-4-015. The RD returns all end-points in the
domain. domain.
Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep Req: GET coap://[FDFD::ABCD:0]/rd-lookup/ep
?d=R2-4-015; rt=light ?d=R2-4-015;rt=light
Res: 2.05 Content Res: 2.05 Content
<coap://[FDFD::ABCD:1]>; <coap://[FDFD::ABCD:1]>;
ep="lm_R2-4-015_wndw", ep="lm_R2-4-015_wndw",
<coap://[FDFD::ABCD:2]>; <coap://[FDFD::ABCD:2]>;
ep="lm_R2-4-015_door" ep="lm_R2-4-015_door"
Knowing its own IPv6 address, the luminary discovers its endpoint Knowing its own IPv6 address, the luminary discovers its endpoint
name. With the end-point name the luminary queries the RD for all name. With the end-point name the luminary queries the RD for all
groups to which the end-point belongs. groups to which the end-point belongs.
Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp Req: GET coap://[FDFD::ABCD:0]/rd-lookup/gp
?ep=lm_R2-4-015_wndw ?ep=lm_R2-4-015_wndw
Res: 2.05 Content Res: 2.05 Content
</rd-group/501;gp="grp_R2-4-015";con="FF05::1" <coap://[FF05::1]>;gp="grp_R2-4-015"
From the context parameter value, the luminary learns the multicast From the context parameter value, the luminary learns the multicast
address of the multicast group. address of the multicast group.
Alternatively, the CT can communicate the multicast address directly Alternatively, the CT can communicate the multicast address directly
to the luminaries by using the "coap-group" resource specified in to the luminaries by using the "coap-group" resource specified in
[RFC7390]. [RFC7390].
Req: POST //[FDFD::ABCD:1]/coap-group Req: POST //[FDFD::ABCD:1]/coap-group
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
skipping to change at page 39, line 22 skipping to change at page 38, line 22
_light._udp.bc.example.com IN PTR _light._udp.bc.example.com IN PTR
lamp3333._light._udp.bc.example.com lamp3333._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR _light._udp.bc.example.com IN PTR
lamp4444._light._udp.bc.example.com lamp4444._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR _light._udp.bc.example.com IN PTR
lamp5555._light._udp.bc.example.com lamp5555._light._udp.bc.example.com
_light._udp.bc.example.com IN PTR _light._udp.bc.example.com IN PTR
lamp6666._light._udp.bc.example.com lamp6666._light._udp.bc.example.com
_p-sensor._udp.bc.example.com IN PTR _p-sensor._udp.bc.example.com IN PTR
pres12324._p-sensor._udp.bc.example.com pres12324._p-sensor._udp.bc.example.com
lamp1111._light._udp.bc.example.com IN SRV 0 0 5678 lamp1111._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_door.bc.example.com. lm_R2-4-015_door.bc.example.com.
lamp1111._light._udp.bc.example.com IN TXT lamp1111._light._udp.bc.example.com IN TXT
txtver=1;path=/light/left txtver=1;path=/light/left
lamp2222._light._udp.bc.example.com IN SRV 0 0 5678 lamp2222._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_door.bc.example.com. lm_R2-4-015_door.bc.example.com.
lamp2222._light._udp.bc.example.com IN TXT lamp2222._light._udp.bc.example.com IN TXT
txtver=1;path=/light/middle txtver=1;path=/light/middle
lamp3333._light._udp.bc.example.com IN SRV 0 0 5678 lamp3333._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_door.bc.example.com. lm_R2-4-015_door.bc.example.com.
lamp3333._light._udp.bc.example.com IN TXT lamp3333._light._udp.bc.example.com IN TXT
txtver=1;path=/light/right txtver=1;path=/light/right
lamp4444._light._udp.bc.example.com IN SRV 0 0 5678 lamp4444._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_wndw.bc.example.com. lm_R2-4-015_wndw.bc.example.com.
lamp4444._light._udp.bc.example.com IN TXT lamp4444._light._udp.bc.example.com IN TXT
txtver=1;path=/light/left txtver=1;path=/light/left
lamp5555._light._udp.bc.example.com IN SRV 0 0 5678 lamp5555._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_wndw.bc.example.com. lm_R2-4-015_wndw.bc.example.com.
lamp5555._light._udp.bc.example.com IN TXT lamp5555._light._udp.bc.example.com IN TXT
txtver=1;path=/light/middle txtver=1;path=/light/middle
lamp6666._light._udp.bc.example.com IN SRV 0 0 5678 lamp6666._light._udp.bc.example.com IN SRV 0 0 5683
lm_R2-4-015_wndw.bc.example.com. lm_R2-4-015_wndw.bc.example.com.
lamp6666._light._udp.bc.example.com IN TXT lamp6666._light._udp.bc.example.com IN TXT
txtver=1;path=/light/right txtver=1;path=/light/right
pres1234._p-sensor._udp.bc.example.com IN SRV 0 0 5678 pres1234._p-sensor._udp.bc.example.com IN SRV 0 0 5683
ps_R2-4-015_door.bc.example.com. ps_R2-4-015_door.bc.example.com.
pres1234._p-sensor._udp.bc.example.com IN TXT pres1234._p-sensor._udp.bc.example.com IN TXT
txtver=1;path=/ps txtver=1;path=/ps
To ask for all lamps is equivalent to returning all PTR RR with label 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 _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 filter on the rd=R2-4-015 value in the DNS, additional PTR RRs have
to be entered into the DNS. to be entered into the DNS.
R2-4-015._light._udp.bc.example.com IN PTR R2-4-015._light._udp.bc.example.com IN PTR
skipping to change at page 40, line 31 skipping to change at page 39, line 31
provides all service instances within the domain R2-4-015. This provides all service instances within the domain R2-4-015. This
filtering can be handy when there are many rooms. In the example filtering can be handy when there are many rooms. In the example
there is only one room, making the filtering superfluous. there is only one room, making the filtering superfluous.
The agent can also discover groups that need to be discovered. It The agent can also discover groups that need to be discovered. It
queries RD to return all groups which are exported. queries RD to return all groups which are exported.
Req: GET /rd-lookup/gp?exp Req: GET /rd-lookup/gp?exp
Res: 2.05 Content Res: 2.05 Content
<coap://[FF05::1]/>; exp; gp="grp_R2-4-015; ins="grp1234"; <coap://[FF05::1]/>;exp;gp="grp_R2-4-015;ins="grp1234";
ep="lm_R2-4-015_wndw"; ep="lm_R2-4-015_wndw";
ep="lm_R2-4-015_door ep="lm_R2-4-015_door
The group with FQDN grp_R2-4-015.bc.example.com can be entered into 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 DNS by the agent. The accompanying instance name is grp1234.
The <ServiceType> is chosen to be _group._udp. The agent enters the The <ServiceType> is chosen to be _group._udp. The agent enters the
following RRs into the DNS. following RRs into the DNS.
grp_R2-4-015.bc.example.com. IN AAAA FF05::1 grp_R2-4-015.bc.example.com. IN AAAA FF05::1
_group._udp.bc.example.com IN PTR _group._udp.bc.example.com IN PTR
grp1234._group._udp.bc.example.com grp1234._group._udp.bc.example.com
grp1234._group._udp.bc.example.com IN SRV 0 0 5678 grp1234._group._udp.bc.example.com IN SRV 0 0 5683
grp_R2-4-015_door.bc.example.com. grp_R2-4-015_door.bc.example.com.
grp1234._group._udp.bc.example.com IN TXT grp1234._group._udp.bc.example.com IN TXT
txtver=1;path=/light/grp1 txtver=1;path=/light/grp1
12.1.4. RD Operation 12.1.4. RD Operation
The specification of the group can be used by devices other than the 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 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 in a given room. For example a smart phone may be used to adjust the
lamps in the room. lamps in the room.
skipping to change at page 42, line 30 skipping to change at page 41, line 30
signal strength. signal strength.
Since there may potentially be more than one of a given type object, Since there may potentially be more than one of a given type object,
for example more than one network connection, LWM2M defines instances for example more than one network connection, LWM2M defines instances
of objects that contain the resources that represent a specific of objects that contain the resources that represent a specific
physical thing. physical thing.
The URI template for LWM2M consists of a base URI followed by Object, The URI template for LWM2M consists of a base URI followed by Object,
Instance, and Resource IDs: Instance, and Resource IDs:
/{base-uri}/{object-id}/{instance-id}/{resource-id} {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource-
instance}
LWM2M IDs are 16 bit numbers represented in decimal by URI format The five variables given here are strings. base-uri can also have
strings. For example, a LWM2M URI might be: the special value "undefined" (sometimes called "null" in RFC 6570).
Each of the variables object-instance, resource-id, and resource-
instance can be the special value "undefined" only if the values
behind it in this sequence also are "undefined". As a special case,
object-instance can be "empty" (which is different from "undefined")
if resource-id is not "undefined". [_TEMPLATE_TODO]
base-uri := Base URI for LWM2M resources or "undefined" for default
(empty) base URI
object-id := OMNA registered object ID (0-65535)
object-instance := Object instance identifier (0-65535) or
"undefined"/"empty" (see above)) to refer to all instances of an
object ID
resource-id := OMNA registered resource ID (0-65535) or "undefined"
to refer to all resources within an instance
resource-instance := Resource instance identifier or "undefined" to
refer to single instance of a resource
LWM2M IDs are 16 bit unsigned integers represented in decimal (no
leading zeroes except for the value 0) by URI format strings. For
example, a LWM2M URI might be:
/1/0/1 /1/0/1
The base uri is "/", the Object ID is 1, the instance ID is 0, and The base uri is empty, the Object ID is 1, the instance ID is 0, the
the resource ID is 1. This example URI points to internal resource resource ID is 1, and the resource instance is "undefined". This
1, which represents the registration lifetime configured, in instance example URI points to internal resource 1, which represents the
0 of a type 1 object (LWM2M Server Object). registration lifetime configured, in instance 0 of a type 1 object
(LWM2M Server Object).
12.2.2. LWM2M Register Endpoint 12.2.2. LWM2M Register Endpoint
LWM2M defines a registration interface based on the Resource LWM2M defines a registration interface based on the Resource
Directory Function Set, described in Section 5. The URI of the LWM2M Directory Function Set, described in Section 5. The URI of the LWM2M
Resource Directory function set is specified to be "/rd" as Resource Directory function set is specified to be "/rd" as
recommended in Section 5.2. recommended in Section 5.2.
LWM2M endpoints register object IDs, for example </1>, to indicate LWM2M endpoints register object IDs, for example </1>, to indicate
that a particular object type is supported, and register object that a particular object type is supported, and register object
skipping to change at page 44, line 17 skipping to change at page 43, line 41
</1>,</1/0>,</3/0>,</5> </1>,</1/0>,</3/0>,</5>
This link format payload indicates that object ID 1 (LWM2M Server This link format payload indicates that object ID 1 (LWM2M Server
Object) is supported, with a single instance 0 existing, object ID 3 Object) is supported, with a single instance 0 existing, object ID 3
(LWM2M Device object) is supported, with a single instance 0 (LWM2M Device object) is supported, with a single instance 0
existing, and object 5 (LWM2M Firmware Object) is supported, with no existing, and object 5 (LWM2M Firmware Object) is supported, with no
existing instances. existing instances.
12.2.3. Alternate Base URI 12.2.3. Alternate Base URI
If the LWM2M endpoint exposes objects at a base URI other that "/", If the LWM2M endpoint exposes objects at a base URI other than the
the endpoint must register the base URI using rt="oma.lwm2m". An default empty base path, the endpoint must register the base URI
example link payload using alternate base URI would be: 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> </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 This link payload indicates that the lwm2m objects will be placed
under the base URI "/my_lwm2m" and that object ID 1 (server) is under the base URI "/my_lwm2m" and that object ID 1 (server) is
supported, with a single instance 0 existing, and object 5 (firmware supported, with a single instance 0 existing, and object 5 (firmware
update) is supported. update) is supported.
12.2.4. LWM2M Update Endpoint Registration 12.2.4. LWM2M Update Endpoint Registration
skipping to change at page 45, line 10 skipping to change at page 44, line 36
Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt,
Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided
helpful comments, discussions and ideas to improve and shape this helpful comments, discussions and ideas to improve and shape this
document. Zach would also like to thank his colleagues from the EU document. Zach would also like to thank his colleagues from the EU
FP7 SENSEI project, where many of the resource directory concepts FP7 SENSEI project, where many of the resource directory concepts
were originally developed. were originally developed.
14. Changelog 14. Changelog
Changes from -03 to -04:
o Added http response codes
o Clarified endpoint name usage
o Add application/link-format+cbor content-format
Changes from -02 to -03: Changes from -02 to -03:
o Added an example for lighting and DNS integration o Added an example for lighting and DNS integration
o Added an example for RD use in OMA LWM2M o Added an example for RD use in OMA LWM2M
o Added Read Links operation for link inspection by endpoints o Added Read Links operation for link inspection by endpoints
o Expanded DNS-SD section o Expanded DNS-SD section
o Added draft authors Peter van der Stok and Michael Koster 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.
skipping to change at page 46, line 33 skipping to change at page 46, line 17
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.
o Fixed tickets 383 and 372
Changes from -02 to -03: Changes from -02 to -03:
o Changed the endpoint name back to a single registration parameter o Changed the endpoint name back to a single registration 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.
skipping to change at page 48, line 42 skipping to change at page 48, line 27
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June (HTTP/1.1): Message Syntax and Routing", RFC 7230, 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 [RFC7390] Rahman, A. and E. Dijk, "Group Communication for the
Constrained Application Protocol (CoAP)", RFC 7390, Constrained Application Protocol (CoAP)", RFC 7390,
October 2014. October 2014.
Editorial Comments
[_TEMPLATE_TODO] This text needs some help from an RFC 6570 expert.
Authors' Addresses Authors' Addresses
Zach Shelby Zach Shelby
ARM ARM
150 Rose Orchard 150 Rose Orchard
San Jose 95134 San Jose 95134
USA USA
Phone: +1-408-203-9434 Phone: +1-408-203-9434
Email: zach.shelby@arm.com Email: zach.shelby@arm.com
 End of changes. 103 change blocks. 
190 lines changed or deleted 254 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/