draft-ietf-core-resource-directory-20.txt		draft-ietf-core-resource-directory-21.txt
	CoRE Z. Shelby		CoRE Z. Shelby
	Internet-Draft ARM		Internet-Draft ARM
	Intended status: Standards Track M. Koster		Intended status: Standards Track M. Koster
	Expires: September 12, 2019 SmartThings		Expires: December 15, 2019 SmartThings
	C. Bormann		C. Bormann
	Universitaet Bremen TZI		Universitaet Bremen TZI
	P. van der Stok		P. van der Stok
	consultant		consultant
	C. Amsuess, Ed.		C. Amsuess, Ed.
	March 11, 2019		June 13, 2019
	CoRE Resource Directory		CoRE Resource Directory
	draft-ietf-core-resource-directory-20		draft-ietf-core-resource-directory-21
	Abstract		Abstract
	In many IoT applications, direct discovery of resources is not		In many IoT applications, direct discovery of resources is not
	practical due to sleeping nodes, disperse networks, or networks where		practical due to sleeping nodes, disperse networks, or networks where
	multicast traffic is inefficient. These problems can be solved by		multicast traffic is inefficient. These problems can be solved by
	employing an entity called a Resource Directory (RD), which contains		employing an entity called a Resource Directory (RD), which contains
	information about resources held on other servers, allowing lookups		information about resources held on other servers, allowing lookups
	to be performed for those resources. The input to an RD is composed		to be performed for those resources. The input to an RD is composed
	of links and the output is composed of links constructed from the		of links and the output is composed of links constructed from the
	skipping to change at page 1, line 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 12, 2019.		This Internet-Draft will expire on December 15, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 31 ¶		skipping to change at page 2, line 31 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6		3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6
	3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8		3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8
	3.4. Link-local addresses and zone identifiers . . . . . . . . 12		3.4. Link-local addresses and zone identifiers . . . . . . . . 12
	3.5. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12		3.5. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12
	3.6. Use Case: Home and Building Automation . . . . . . . . . 13		3.6. Use Case: Home and Building Automation . . . . . . . . . 13
	3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 13		3.7. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 14
	4. RD discovery and other interface-independent components . . . 14		4. RD discovery and other interface-independent components . . . 14
	4.1. Finding a Resource Directory . . . . . . . . . . . . . . 15		4.1. Finding a Resource Directory . . . . . . . . . . . . . . 15
	4.1.1. Resource Directory Address Option (RDAO) . . . . . . 17		4.1.1. Resource Directory Address Option (RDAO) . . . . . . 17
	4.2. Payload Content Formats . . . . . . . . . . . . . . . . . 18		4.2. Payload Content Formats . . . . . . . . . . . . . . . . . 18
	4.3. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 19		4.3. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 19
	5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 21		5. Registration . . . . . . . . . . . . . . . . . . . . . . . . 21
	5.1. Simple Registration . . . . . . . . . . . . . . . . . . . 26		5.1. Simple Registration . . . . . . . . . . . . . . . . . . . 26
	5.2. Third-party registration . . . . . . . . . . . . . . . . 28		5.2. Third-party registration . . . . . . . . . . . . . . . . 28
	5.3. Operations on the Registration Resource . . . . . . . . . 28		5.3. Operations on the Registration Resource . . . . . . . . . 28
	5.3.1. Registration Update . . . . . . . . . . . . . . . . . 29		5.3.1. Registration Update . . . . . . . . . . . . . . . . . 29
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 52		10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 52
	10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 54		10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 54
	10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 54		10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 54
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
	12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 54		12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 54
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 63
	13.1. Normative References . . . . . . . . . . . . . . . . . . 63		13.1. Normative References . . . . . . . . . . . . . . . . . . 63
	13.2. Informative References . . . . . . . . . . . . . . . . . 64		13.2. Informative References . . . . . . . . . . . . . . . . . 64
	Appendix A. Groups Registration and Lookup . . . . . . . . . . . 66		Appendix A. Groups Registration and Lookup . . . . . . . . . . . 66
	Appendix B. Web links and the Resource Directory . . . . . . . . 67		Appendix B. Web links and the Resource Directory . . . . . . . . 67
	B.1. A simple example . . . . . . . . . . . . . . . . . . . . 67		B.1. A simple example . . . . . . . . . . . . . . . . . . . . 68
	B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 68		B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 68
	B.1.2. Interpreting attributes and relations . . . . . . . . 68		B.1.2. Interpreting attributes and relations . . . . . . . . 68
	B.2. A slightly more complex example . . . . . . . . . . . . . 69		B.2. A slightly more complex example . . . . . . . . . . . . . 69
	B.3. Enter the Resource Directory . . . . . . . . . . . . . . 69		B.3. Enter the Resource Directory . . . . . . . . . . . . . . 69
	B.4. A note on differences between link-format and Link		B.4. A note on differences between link-format and Link
	headers . . . . . . . . . . . . . . . . . . . . . . . . . 71		headers . . . . . . . . . . . . . . . . . . . . . . . . . 71
	Appendix C. Limited Link Format . . . . . . . . . . . . . . . . 72		Appendix C. Limited Link Format . . . . . . . . . . . . . . . . 72
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 73
	1. Introduction		1. Introduction
	In the work on Constrained RESTful Environments (CoRE), a REST		In the work on Constrained RESTful Environments (CoRE), a REST
	architecture suitable for constrained nodes (e.g. with limited RAM		architecture suitable for constrained nodes (e.g. with limited RAM
	and ROM [RFC7228]) and networks (e.g. 6LoWPAN [RFC4944]) has been		and ROM [RFC7228]) and networks (e.g. 6LoWPAN [RFC4944]) has been
	established and is used in Internet-of-Things (IoT) or machine-to-		established and is used in Internet-of-Things (IoT) or machine-to-
	machine (M2M) applications such as smart energy and building		machine (M2M) applications such as smart energy and building
	automation.		automation.
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 21 ¶
	installation of the network by assigning values to parameters,		installation of the network by assigning values to parameters,
	naming endpoints and groups, or adapting the installation to the		naming endpoints and groups, or adapting the installation to the
	needs of the applications.		needs of the applications.
	Registrant-ep		Registrant-ep
	Registrant-ep is the endpoint that is registered into the RD. The		Registrant-ep is the endpoint that is registered into the RD. The
	registrant-ep can register itself, or a CT registers the		registrant-ep can register itself, or a CT registers the
	registrant-ep.		registrant-ep.
	RDAO		RDAO
	Resource Directory Address Option. A new IPv6 Neigbhbor Discovery		Resource Directory Address Option. A new IPv6 Neighbor Discovery
	option defined for announcing a Resource Directory's address.		option defined for announcing a Resource Directory's address.
	3. Architecture and Use Cases		3. Architecture and Use Cases
	3.1. Principles		3.1. Principles
	The Resource Directory is primarily a tool to make discovery		The Resource Directory is primarily a tool to make discovery
	operations more efficient than querying /.well-known/core on all		operations more efficient than querying /.well-known/core on all
	connected devices, or across boundaries that would be limiting those		connected devices, or across boundaries that would be limiting those
	operations.		operations.
	skipping to change at page 13, line 43 ¶		skipping to change at page 13, line 43 ¶
	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
	sleeping devices.		sleeping devices.
			Two phases can be discerned for a network servicing the system: (1)
			installation and (2) operation. During the operational phase, the
			network is connected to the Internet with a Border router (6LBR) and
			the nodes connected to the network can use the Internet services that
			are provided by the Internet Provider or the network administrator.
			During the installation phase, the network is completely stand-alone,
			no 6LBR is connected, and the network only supports the IP
			communication between the connected nodes. The installation phase is
			usually followed by the operational phase.
	3.7. Use Case: Link Catalogues		3.7. Use Case: Link Catalogues
	Resources may be shared through data brokers that have no knowledge		Resources may be shared through data brokers that have no knowledge
	beforehand of who is going to consume the data. Resource Directory		beforehand of who is going to consume the data. Resource Directory
	can be used to hold links about resources and services hosted		can be used to hold links about resources and services hosted
	anywhere to make them discoverable by a general class of		anywhere to make them discoverable by a general class of
	applications.		applications.
	For example, environmental and weather sensors that generate data for		For example, environmental and weather sensors that generate data for
	public consumption may provide data to an intermediary server, or		public consumption may provide data to an intermediary server, or
	skipping to change at page 15, line 30 ¶		skipping to change at page 15, line 38 ¶
	in HTTP).		in HTTP).
	A resource directory MAY make the information submitted to it		A resource directory MAY make the information submitted to it
	available to further directories, if it can ensure that a loop does		available to further directories, if it can ensure that a loop does
	not form. The protocol used between directories to ensure loop-free		not form. The protocol used between directories to ensure loop-free
	operation is outside the scope of this document.		operation is outside the scope of this document.
	4.1. Finding a Resource Directory		4.1. Finding a Resource Directory
	A (re-)starting device may want to find one or more resource		A (re-)starting device may want to find one or more resource
	directories for discovery purposes.		directories for discovery purposes. Dependent on the operational
			conditions, one or more of the techniques below apply. The use of
			DNS-SD [RFC6763] is described in [I-D.ietf-core-rd-dns-sd].
	The device may be pre-configured to exercise specific mechanisms for		The device may be pre-configured to exercise specific mechanisms for
	finding the resource directory:		finding the resource directory:
	1. It may be configured with a specific IP address for the RD. That		1. It may be configured with a specific IP address for the RD. That
	IP address may also be an anycast address, allowing the network		IP address may also be an anycast address, allowing the network
	to forward RD requests to an RD that is topologically close; each		to forward RD requests to an RD that is topologically close; each
	target network environment in which some of these preconfigured		target network environment in which some of these preconfigured
	nodes are to be brought up is then configured with a route for		nodes are to be brought up is then configured with a route for
	this anycast address that leads to an appropriate RD. (Instead		this anycast address that leads to an appropriate RD. (Instead
	of using an anycast address, a multicast address can also be		of using an anycast address, a multicast address can also be
	preconfigured. The RD servers then need to configure one of		preconfigured. The RD servers then need to configure one of
	their interfaces with this multicast address.)		their interfaces with this multicast address.)
	2. It may be configured with a DNS name for the RD and use DNS to		2. It may be configured with a DNS name for the RD and use DNS to
	return the IP address of the RD; it can find a DNS server to		return the IP address of the RD; it can find a DNS server to
	perform the lookup using the usual mechanisms for finding DNS		perform the lookup using the usual mechanisms for finding DNS
	servers.		servers.
	3. It may be configured to use a service discovery mechanism such as
	DNS-SD [RFC6763]. The present specification suggests configuring
	the service with name rd._sub._coap._udp, preferably within the
	domain of the querying nodes.
	For cases where the device is not specifically configured with a way		For cases where the device is not specifically configured with a way
	to find a resource directory, the network may want to provide a		to find a resource directory, the network may want to provide a
	suitable default.		suitable default.
	1. If the address configuration of the network is performed via		1. If the address configuration of the network is performed via
	SLAAC, this is provided by the RDAO option Section 4.1.1.		SLAAC, this is provided by the RDAO option Section 4.1.1.
	2. If the address configuration of the network is performed via		2. If the address configuration of the network is performed via
	DHCP, this could be provided via a DHCP option (no such option is		DHCP, this could be provided via a DHCP option (no such option is
	defined at the time of writing).		defined at the time of writing).
	skipping to change at page 17, line 5 ¶		skipping to change at page 17, line 8 ¶
	As some of the RD addresses obtained by the methods listed here are		As some of the RD addresses obtained by the methods listed here are
	just (more or less educated) guesses, endpoints MUST make use of any		just (more or less educated) guesses, endpoints MUST make use of any
	error messages to very strictly rate-limit requests to candidate IP		error messages to very strictly rate-limit requests to candidate IP
	addresses that don't work out. For example, an ICMP Destination		addresses that don't work out. For example, an ICMP Destination
	Unreachable message (and, in particular, the port unreachable code		Unreachable message (and, in particular, the port unreachable code
	for this message) may indicate the lack of a CoAP server on the		for this message) may indicate the lack of a CoAP server on the
	candidate host, or a CoAP error response code such as 4.05 "Method		candidate host, or a CoAP error response code such as 4.05 "Method
	Not Allowed" may indicate unwillingness of a CoAP server to act as a		Not Allowed" may indicate unwillingness of a CoAP server to act as a
	directory server.		directory server.
	If multiple candidate addresses are discovered, the device may pick		The following RD discovery mechanisms are recommended:
	any of them initially, unless the discovery method indicates a more
	precise selection scheme.		o In managed networks with border routers that need stand-alone
			operation, the RDA0 option is recommended (e.g. operational phase
			described in Section 3.6).
			o In managed networks without border router (no Internet services
			available), the use of a preconfigured anycast address is
			recommended (e.g. installation phase described in Section 3.6).
			o The use of DNS facilities is described in
			[I-D.ietf-core-rd-dns-sd].
			The use of multicast discovery in mesh networks is NOT recommended.
	4.1.1. Resource Directory Address Option (RDAO)		4.1.1. Resource Directory Address Option (RDAO)
	The Resource Directory Address Option (RDAO) using IPv6 Neighbor		The Resource Directory Address Option (RDAO) using IPv6 Neighbor
	Discovery (ND) carries information about the address of the Resource		Discovery (ND) carries information about the address of the Resource
	Directory (RD). This information is needed when endpoints cannot		Directory (RD). This information is needed when endpoints cannot
	discover the Resource Directory with a link-local or realm-local		discover the Resource Directory with a link-local or realm-local
	scope multicast address, for instance because the endpoint and the RD		scope multicast address, for instance because the endpoint and the RD
	are separated by a Border Router (6LBR). In many circumstances the		are separated by a Border Router (6LBR). In many circumstances the
	availability of DHCP cannot be guaranteed either during commissioning		availability of DHCP cannot be guaranteed either during commissioning
	skipping to change at page 64, line 32 ¶		skipping to change at page 64, line 32 ¶
	Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March		Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March
	1976.		1976.
	[I-D.bormann-t2trg-rel-impl]		[I-D.bormann-t2trg-rel-impl]
	Bormann, C., "impl-info: A link relation type for		Bormann, C., "impl-info: A link relation type for
	disclosing implementation information", draft-bormann-		disclosing implementation information", draft-bormann-
	t2trg-rel-impl-00 (work in progress), January 2018.		t2trg-rel-impl-00 (work in progress), January 2018.
	[I-D.hartke-t2trg-coral]		[I-D.hartke-t2trg-coral]
	Hartke, K., "The Constrained RESTful Application Language		Hartke, K., "The Constrained RESTful Application Language
	(CoRAL)", draft-hartke-t2trg-coral-07 (work in progress),		(CoRAL)", draft-hartke-t2trg-coral-08 (work in progress),
	February 2019.		March 2019.
	[I-D.ietf-ace-oauth-authz]		[I-D.ietf-ace-oauth-authz]
	Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and		Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
	H. Tschofenig, "Authentication and Authorization for		H. Tschofenig, "Authentication and Authorization for
	Constrained Environments (ACE) using the OAuth 2.0		Constrained Environments (ACE) using the OAuth 2.0
	Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-22		Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
	(work in progress), March 2019.		(work in progress), March 2019.
	[I-D.ietf-core-links-json]		[I-D.ietf-core-links-json]
	Li, K., Rahman, A., and C. Bormann, "Representing		Li, K., Rahman, A., and C. Bormann, "Representing
	Constrained RESTful Environments (CoRE) Link Format in		Constrained RESTful Environments (CoRE) Link Format in
	JSON and CBOR", draft-ietf-core-links-json-10 (work in		JSON and CBOR", draft-ietf-core-links-json-10 (work in
	progress), February 2018.		progress), February 2018.
			[I-D.ietf-core-rd-dns-sd]
			Lynn, K., Stok, P., Koster, M., and C. Amsuess, "CoRE
			Resource Directory: DNS-SD mapping", draft-ietf-core-rd-
			dns-sd-04 (work in progress), March 2019.
	[I-D.silverajan-core-coap-protocol-negotiation]		[I-D.silverajan-core-coap-protocol-negotiation]
	Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",		Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
	draft-silverajan-core-coap-protocol-negotiation-09 (work		draft-silverajan-core-coap-protocol-negotiation-09 (work
	in progress), July 2018.		in progress), July 2018.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<https://www.rfc-editor.org/info/rfc4944>.		<https://www.rfc-editor.org/info/rfc4944>.
End of changes. 15 change blocks.
	20 lines changed or deleted		43 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/