draft-ietf-core-coap-pubsub-05.txt   draft-ietf-core-coap-pubsub-06.txt 
Network Working Group M. Koster Network Working Group M. Koster
Internet-Draft SmartThings Internet-Draft SmartThings
Intended status: Standards Track A. Keranen Intended status: Standards Track A. Keranen
Expires: January 3, 2019 J. Jimenez Expires: July 7, 2019 J. Jimenez
Ericsson Ericsson
July 2, 2018 January 3, 2019
Publish-Subscribe Broker for the Constrained Application Protocol (CoAP) Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
draft-ietf-core-coap-pubsub-05 draft-ietf-core-coap-pubsub-06
Abstract Abstract
The Constrained Application Protocol (CoAP), and related extensions The Constrained Application Protocol (CoAP), and related extensions
are intended to support machine-to-machine communication in systems are intended to support machine-to-machine communication in systems
where one or more nodes are resource constrained, in particular for where one or more nodes are resource constrained, in particular for
low power wireless sensor networks. This document defines a publish- low power wireless sensor networks. This document defines a publish-
subscribe Broker for CoAP that extends the capabilities of CoAP for subscribe Broker for CoAP that extends the capabilities of CoAP for
supporting nodes with long breaks in connectivity and/or up-time. supporting nodes with long breaks in connectivity and/or up-time.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 January 3, 2019. This Internet-Draft will expire on July 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. CoAP Pub/sub Architecture . . . . . . . . . . . . . . . . 4 3.1. CoAP Pub/sub Architecture . . . . . . . . . . . . . . . . 4
3.2. CoAP Pub/sub Broker . . . . . . . . . . . . . . . . . . . 4 3.2. CoAP Pub/sub Broker . . . . . . . . . . . . . . . . . . . 5
3.3. CoAP Pub/sub Client . . . . . . . . . . . . . . . . . . . 5 3.3. CoAP Pub/sub Client . . . . . . . . . . . . . . . . . . . 5
3.4. CoAP Pub/sub Topic . . . . . . . . . . . . . . . . . . . 5 3.4. CoAP Pub/sub Topic . . . . . . . . . . . . . . . . . . . 5
3.5. brokerless Pub/sub . . . . . . . . . . . . . . . . . . . 5 3.5. brokerless Pub/sub . . . . . . . . . . . . . . . . . . . 5
4. CoAP Pub/sub REST API . . . . . . . . . . . . . . . . . . . . 6 4. CoAP Pub/sub REST API . . . . . . . . . . . . . . . . . . . . 6
4.1. DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. CREATE . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. SUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. UNSUBSCRIBE . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. READ . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. REMOVE . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. CoAP Pub/sub Operation with Resource Directory . . . . . . . 19 5. CoAP Pub/sub Operation with Resource Directory . . . . . . . 19
6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 20 6. Sleep-Wake Operation . . . . . . . . . . . . . . . . . . . . 20
7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 20 7. Simple Flow Control . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 22 9.1. Resource Type value 'core.ps' . . . . . . . . . . . . . . 22
9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 22 9.2. Resource Type value 'core.ps.discover' . . . . . . . . . 22
9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 22 9.3. Response Code value '2.07' . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 11.1. Normative References . . . . . . . . . . . . . . . . . . 23
11.2. Informative References . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] supports The Constrained Application Protocol (CoAP) [RFC7252] supports
machine-to-machine communication across networks of constrained machine-to-machine communication across networks of constrained
devices. CoAP uses a request/response model where clients make devices. CoAP uses a request/response model where clients make
requests to servers in order to request actions on resources. requests to servers in order to request actions on resources.
Depending on the situation the same device may act either as a server Depending on the situation the same device may act either as a
or a client. server, a client, or both.
One important class of constrained devices includes devices that are One important class of constrained devices includes devices that are
intended to run for years from a small battery, or by scavenging intended to run for years from a small battery, or by scavenging
energy from their environment. These devices have limited energy from their environment. These devices have limited
reachability because they spend most of their time in a sleeping reachability because they spend most of their time in a sleeping
state with no network connectivity. Devices may also have limited state with no network connectivity. Devices may also have limited
reachability due to certain middle-boxes, such as Network Address reachability due to certain middle-boxes, such as Network Address
Translators (NATs) or firewalls. Such middle-boxes often prevent Translators (NATs) or firewalls. Such middle-boxes often prevent
connecting to a device from the Internet unless the connection was connecting to a device from the Internet unless the connection was
initiated by the device. initiated by the device.
This document specifies the means for nodes with limited reachability For some applications the client/server and request/response
to communicate using simple extensions to CoAP. The extensions communication model is not optimal but publish-subscribe
enable publish-subscribe communication using a Broker node that communication with potentially many senders and/or receivers and
enables store-and-forward messaging between two or more nodes. communication via topics rather than directly with endpoints may fit
Furthermore the extensions facilitate many-to-many communication better.
using CoAP.
This document specifies simple extensions to CoAP for enabling
publish-subscribe communication using a Broker node that enables
store-and-forward messaging between two or more nodes. This model
facilitates communication of nodes with limited reachability, enables
simple many-to-many communication, and eases integration with other
publish-subscribe systems.
2. Terminology 2. Terminology
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
specification are to be interpreted as described in [RFC2119]. specification are to be interpreted as described in [RFC2119].
This specification requires readers to be familiar with all the terms This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC5988] and [RFC6690]. Readers and concepts that are discussed in [RFC5988] and [RFC6690]. Readers
should also be familiar with the terms and concepts discussed in should also be familiar with the terms and concepts discussed in
skipping to change at page 5, line 32 skipping to change at page 5, line 42
all the clients using the Broker share the same namespace for topics. all the clients using the Broker share the same namespace for topics.
Every CoAP pub/sub topic has an associated link, consisting of a Every CoAP pub/sub topic has an associated link, consisting of a
reference path on the Broker using URI path [RFC3986] construction reference path on the Broker using URI path [RFC3986] construction
and link attributes [RFC6690]. Every topic is associated with zero and link attributes [RFC6690]. Every topic is associated with zero
or more stored representations and a content-format specified in the or more stored representations and a content-format specified in the
link. A CoAP pub/sub topic value may alternatively consist of a link. A CoAP pub/sub topic value may alternatively consist of a
collection of one or more sub-topics, consisting of links to the sub- collection of one or more sub-topics, consisting of links to the sub-
topic URIs and indicated by a link-format content-format. Sub-topics topic URIs and indicated by a link-format content-format. Sub-topics
are also topics and may have their own sub-topics, forming a tree are also topics and may have their own sub-topics, forming a tree
structure of unique paths that is implemented using URIs. The full structure of unique paths that is implemented using URIs. The full
URI of a topic includes a schems and authority for the Broker, for URI of a topic includes a scheme and authority for the Broker, for
example "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700". example "coaps://10.0.0.13:5684/EP-33543/sen/3303/0/5700".
3.5. brokerless Pub/sub 3.5. brokerless Pub/sub
Figure 2 shows an arrangement for using CoAP pub/sub in a Figure 2 shows an arrangement for using CoAP pub/sub in a
"Brokerless" configuration between peer nodes. Nodes in a Brokerless "Brokerless" configuration between peer nodes. Nodes in a Brokerless
system may act as both Broker and client. A node that supports system may act as both Broker and client. A node that supports
Broker functionality may be pre-configured with topics that expose Broker functionality may be pre-configured with topics that expose
services and resources. Brokerless peer nodes can be mixed with services and resources. Brokerless peer nodes can be mixed with
client and Broker nodes in a system with full interoperability. client and Broker nodes in a system with full interoperability.
skipping to change at page 8, line 49 skipping to change at page 8, line 49
A CoAP pub/sub broker SHOULD allow Clients to create new topics on A CoAP pub/sub broker SHOULD allow Clients to create new topics on
the broker using CREATE. Some exceptions are for fixed brokerless the broker using CREATE. Some exceptions are for fixed brokerless
devices and pre-configured brokers in dedicated installations. A devices and pre-configured brokers in dedicated installations. A
client wishing to create a topic MUST use a CoAP POST to the pub/sub client wishing to create a topic MUST use a CoAP POST to the pub/sub
API with a payload indicating the desired topic. The topic API with a payload indicating the desired topic. The topic
specification sent in the payload MUST use a supported serialization specification sent in the payload MUST use a supported serialization
of the CoRE link format [RFC6690]. The target of the link MUST be a of the CoRE link format [RFC6690]. The target of the link MUST be a
URI formatted string. The client MUST indicate the desired content URI formatted string. The client MUST indicate the desired content
format for publishes to the topic by using the ct (Content Format) format for publishes to the topic by using the ct (Content Format)
link attribute in the link-format payload. The client MAY indicate link attribute in the link-format payload. Additional link target
the lifetime of the topic by including the Max-Age option in the attributes and relation values may be included in the topic
CREATE request. specification link whena topic is created.
Topics may be created as sub-topics of other topics. A client MAY The client MAY indicate the lifetime of the topic by including the
create a topic with a ct (Content Format) link attribute value which Max-Age option in the CREATE request.
describes a supported serialization of the CoRE link format [RFC6690]
such as application/link-format (ct=40) or its JSON or CBOR Topic hierarchies can be created by creating parent topics. A parent
serializations. If a topic is created which describes a link topic is created with a POST using ct (Content Format) link attribute
value which describes a supported serialization of the CoRE link
format [RFC6690], such as application/link-format (ct=40) or its JSON
or CBOR serializations. If a topic is created which describes a link
serialization, that topic may then have sub-topics created under it serialization, that topic may then have sub-topics created under it
as shown in Figure 7. as shown in Figure 7.
Ony one level in the topic hierarchy may be created as a result of a Ony one level in the topic hierarchy may be created as a result of a
CREATE operation, unless create on PUBLISH is supported (see CREATE operation, unless create on PUBLISH is supported (see
Section 4.3). The topic string used in the link target MUST NOT Section 4.3). The topic string used in the link target MUST NOT
contain the "/" character. contain the "/" character.
A topic creator MUST include exactly one content format link A topic creator MUST include exactly one content format link
attribute value (ct) in the create payload. If the Broker does not attribute value (ct) in the create payload. If the Broker does not
support the indicated format for both publish and subscribe, it MUST support the indicated format for both publish and subscribe, or if
reject the operation with an error code of 4.00 "Bad Request". there is more than one "ct" value included in the request, the Broker
MUST reject the operation with an error code of 4.00 "Bad Request".
Only one topic may be created per request. If there is more than one
link included in a CREATE request, the Broker MUST reject the
operation with an erroro code of 4.00 "Bad Request".
There is no default content format. If no ct is specified, the There is no default content format. If no ct is specified, the
Broker MUST reject the operation with an error code of 4.00 "Bad Broker MUST reject the operation with an error code of 4.00 "Bad
Request". Request".
A Broker MUST return a response code of "2.01 Created" if the topic A Broker MUST return a response code of "2.01 Created" if the topic
is created and return the URI path of the created topic via Location- is created and return the URI path of the created topic via Location-
Path options. The Broker MUST return the appropriate 4.xx response Path options. The Broker MUST return the appropriate 4.xx response
code indicating the reason for failure if a new topic can not be code indicating the reason for failure if a new topic can not be
created. Broker SHOULD remove topics if the Max-Age of the topic is created. Broker SHOULD remove topics if the Max-Age of the topic is
exceeded without any publishes to the topic. Broker SHOULD retain a exceeded without any publishes to the topic. Broker SHOULD retain a
topic indefinitely if the Max-Age option is elided or is set to zero topic indefinitely if the Max-Age option is elided or is set to zero
upon topic creation. The lifetime of a topic MUST be refreshed upon upon topic creation. The lifetime of a topic MUST be refreshed upon
create operations with a target of an existing topic. create operations with a target of an existing topic.
Topic hierarchies can be created by creating parent topics. A parent
topic is created with a POST using ct (Content Format) link attribute
value which describes a supported serialization of the CoRE link
format [RFC6690], such as application/link-format (ct=40) or its JSON
or CBOR serializations. If a topic is created which describes a link
serialization, that topic may then have sub-topics created under it
as shown in Figure 7.
The CREATE interface is specified as follows: The CREATE interface is specified as follows:
Interaction: Client -> Broker Interaction: Client -> Broker
Method: POST Method: POST
URI Template: {+ps}/{+topic} URI Template: {+ps}/{+topic}
URI Template Variables: ps := Pub/sub REST API entry point URI Template Variables: ps := Pub/sub REST API entry point
(optional). The entry point of the pub/sub REST API, as obtained (optional). The entry point of the pub/sub REST API, as obtained
from discovery, used to discover topics. from discovery, used to discover topics.
skipping to change at page 20, line 36 skipping to change at page 20, line 36
7. Simple Flow Control 7. Simple Flow Control
Since the Broker node has to potentially send a large amount of Since the Broker node has to potentially send a large amount of
notification messages for each publish message and it may be serving notification messages for each publish message and it may be serving
a large amount of subscribers and publishers simultaneously, the a large amount of subscribers and publishers simultaneously, the
Broker may become overwhelmed if it receives many publish messages to Broker may become overwhelmed if it receives many publish messages to
popular topics in a short period of time. popular topics in a short period of time.
If the Broker is unable to serve a certain client that is sending If the Broker is unable to serve a certain client that is sending
publish messages too fast, the Broker SHOULD respond with Response publish messages too fast, the Broker SHOULD respond with Response
Code 4.29, "Too Many Requests" [I-D.keranen-core-too-many-reqs] and Code 4.29, "Too Many Requests" [I-D.ietf-core-too-many-reqs] and set
set the Max-Age Option to indicate the number of seconds after which the Max-Age Option to indicate the number of seconds after which the
the client can retry. The Broker MAY stop creating notifications client can retry. The Broker MAY stop creating notifications from
from the publish messages from this client and to this topic for the the publish messages from this client and to this topic for the
indicated time. indicated time.
If a client receives the 4.29 Response Code from the Broker for a If a client receives the 4.29 Response Code from the Broker for a
publish message to a topic, it MUST NOT send new publish messages to publish message to a topic, it MUST NOT send new publish messages to
the Broker on the same topic before the time indicated in Max-Age has the Broker on the same topic before the time indicated in Max-Age has
passed. passed.
8. Security Considerations 8. Security Considerations
CoAP pub/sub re-uses CoAP [RFC7252], CoRE Resource Directory CoAP pub/sub re-uses CoAP [RFC7252], CoRE Resource Directory
skipping to change at page 21, line 40 skipping to change at page 21, line 40
a client device will also provide guarantee to the client application a client device will also provide guarantee to the client application
that the data originated on the client device itself. The protected that the data originated on the client device itself. The protected
data can also be verified by the intermediate Broker ensuring that it data can also be verified by the intermediate Broker ensuring that it
stores/caches correct request/response and no malicious messages/ stores/caches correct request/response and no malicious messages/
requests are accepted. The Broker would still be able to perform requests are accepted. The Broker would still be able to perform
aggregation of data/requests collected. aggregation of data/requests collected.
Depending on the level of trust users and system designers place in Depending on the level of trust users and system designers place in
the CoAP pub/sub Broker, the use of end-to-end object security is the CoAP pub/sub Broker, the use of end-to-end object security is
RECOMMENDED as described in [I-D.palombini-ace-coap-pubsub-profile]. RECOMMENDED as described in [I-D.palombini-ace-coap-pubsub-profile].
When only end-to-end encryption is necessary and the CoAP Broker is An example application that uses the CoAP pub/sub Broker and relies
trusted, Payload Only Protection (Mode:PAYL) could be used. The on end-to-end object security is described in [RFC8387]. When only
Publisher would wrap only the payload before sending it to the Broker end-to-end encryption is necessary and the CoAP Broker is trusted,
and set the option Content-Format to application/smpayl. Upon Payload Only Protection (Mode:PAYL) could be used. The Publisher
receival, the Broker can read the unencrypted CoAP header to forward would wrap only the payload before sending it to the Broker and set
it to the subscribers. the option Content-Format to application/smpayl. Upon receival, the
Broker can read the unencrypted CoAP header to forward it to the
subscribers.
9. IANA Considerations 9. IANA Considerations
This document registers one attribute value in the Resource Type This document registers one attribute value in the Resource Type
(rt=) registry established with [RFC6690] and appends to the (rt=) registry established with [RFC6690] and appends to the
definition of one CoAP Response Code in the CoRE Parameters Registry. definition of one CoAP Response Code in the CoRE Parameters Registry.
9.1. Resource Type value 'core.ps' 9.1. Resource Type value 'core.ps'
o Attribute Value: core.ps o Attribute Value: core.ps
skipping to change at page 22, line 49 skipping to change at page 23, line 9
The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit The authors would like to thank Hannes Tschofenig, Zach Shelby, Mohit
Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran Sethi, Peter van der Stok, Tim Kellogg, Anders Eriksson, Goran
Selander, Mikko Majanen, and Olaf Bergmann for their contributions Selander, Mikko Majanen, and Olaf Bergmann for their contributions
and reviews. and reviews.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.keranen-core-too-many-reqs] [I-D.ietf-core-too-many-reqs]
Keranen, A., "Too Many Requests Response Code for the Keranen, A., "Too Many Requests Response Code for the
Constrained Application Protocol", draft-keranen-core-too- Constrained Application Protocol", draft-ietf-core-too-
many-reqs-01 (work in progress), March 2018. many-reqs-06 (work in progress), November 2018.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[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 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 23, line 39 skipping to change at page 23, line 48
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, <https://www.rfc- DOI 10.17487/RFC7641, September 2015, <https://www.rfc-
editor.org/info/rfc7641>. editor.org/info/rfc7641>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-core-object-security] [I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz, Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments "Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-13 (work in (OSCORE)", draft-ietf-core-object-security-15 (work in
progress), June 2018. progress), August 2018.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-14 (work in progress), July 2018. resource-directory-18 (work in progress), December 2018.
[I-D.palombini-ace-coap-pubsub-profile] [I-D.palombini-ace-coap-pubsub-profile]
Palombini, F., "CoAP Pub-Sub Profile for Authentication Palombini, F., "CoAP Pub-Sub Profile for Authentication
and Authorization for Constrained Environments (ACE)", and Authorization for Constrained Environments (ACE)",
draft-palombini-ace-coap-pubsub-profile-03 (work in draft-palombini-ace-coap-pubsub-profile-03 (work in
progress), June 2018. progress), June 2018.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010, <https://www.rfc- DOI 10.17487/RFC5988, October 2010, <https://www.rfc-
editor.org/info/rfc5988>. editor.org/info/rfc5988>.
[RFC8387] Sethi, M., Arkko, J., Keranen, A., and H. Back, "Practical
Considerations and Implementation Experiences in Securing
Smart Object Networks", RFC 8387, DOI 10.17487/RFC8387,
May 2018, <https://www.rfc-editor.org/info/rfc8387>.
Authors' Addresses Authors' Addresses
Michael Koster Michael Koster
SmartThings SmartThings
Email: Michael.Koster@smartthings.com Email: Michael.Koster@smartthings.com
Ari Keranen Ari Keranen
Ericsson Ericsson
 End of changes. 22 change blocks. 
52 lines changed or deleted 65 lines changed or added

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