draft-ietf-core-dev-urn-10.txt		draft-ietf-core-dev-urn.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Intended status: Standards Track C. Jennings		Intended status: Standards Track C. Jennings
	Expires: July 17, 2021 Cisco		Expires: August 27, 2021 Cisco
	Z. Shelby		Z. Shelby
	ARM		ARM
	January 13, 2021		February 23, 2021
	Uniform Resource Names for Device Identifiers		Uniform Resource Names for Device Identifiers
	draft-ietf-core-dev-urn-10		draft-ietf-core-dev-urn-11
	Abstract		Abstract
	This document describes a new Uniform Resource Name (URN) namespace		This document describes a new Uniform Resource Name (URN) namespace
	for hardware device identifiers. A general representation of device		for hardware device identifiers. A general representation of device
	identity can be useful in many applications, such as in sensor data		identity can be useful in many applications, such as in sensor data
	streams and storage, or equipment inventories. A URN-based		streams and storage, or equipment inventories. A URN-based
	representation can be passed along in applications that need the		representation can be passed along in applications that need the
	information.		information.
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 July 17, 2021.		This Internet-Draft will expire on August 27, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 22		skipping to change at page 2, line 22
	2. Requirements language . . . . . . . . . . . . . . . . . . . . 4		2. Requirements language . . . . . . . . . . . . . . . . . . . . 4
	3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4		3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2.1. Character Case and URN-Equivalence . . . . . . . . . 6		3.2.1. Character Case and URN-Equivalence . . . . . . . . . 6
	3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 7		3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 7
	3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 7		3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 7
	3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 7		3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 7
	3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7		3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7
	3.8. Additional Information . . . . . . . . . . . . . . . . . 7		3.8. Additional Information . . . . . . . . . . . . . . . . . 8
	3.9. Revision Information . . . . . . . . . . . . . . . . . . 8		3.9. Revision Information . . . . . . . . . . . . . . . . . . 8
	4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 8		4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 8		4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8		4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8
	4.3. Organization-Defined Identifiers . . . . . . . . . . . . 9		4.3. Organization-Defined Identifiers . . . . . . . . . . . . 9
	4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9		4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9
	4.5. Organization Product and Serial Numbers . . . . . . . . . 10		4.5. Organization Product and Serial Numbers . . . . . . . . . 10
	4.6. Future Subtypes . . . . . . . . . . . . . . . . . . . . . 10		4.6. Future Subtypes . . . . . . . . . . . . . . . . . . . . . 10
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12
	6.2. Validity . . . . . . . . . . . . . . . . . . . . . . . . 12		6.2. Validity . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix A. Changes from Previous Version . . . . . . . . . . . 16		Appendix A. Changes from Previous Versions . . . . . . . . . . . 16
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 20		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This document describes a new Uniform Resource Name (URN) [RFC8141]		This document describes a new Uniform Resource Name (URN) [RFC8141]
	namespace for hardware device identifiers. A general representation		namespace for hardware device identifiers. A general representation
	of device identity can be useful in many applications, such as in		of device identity can be useful in many applications, such as in
	sensor data streams and storage [RFC8428], or equipment inventories		sensor data streams and storage [RFC8428], or equipment inventories
	[RFC7252], [I-D.ietf-core-resource-directory].		[RFC7252], [I-D.ietf-core-resource-directory].
	A URN-based representation can be passed along in applications that		A URN-based representation can be passed along in applications that
	need the information. It fits particularly well for protocols		need the information. It fits particularly well for protocols
	mechanisms that are designed to carry URNs [RFC7230], [RFC7540],		mechanisms that are designed to carry URNs [RFC7230], [RFC7540],
	[RFC3261], [RFC7252]. Finally, URNs can also be easily carried and		[RFC3261], [RFC7252]. Finally, URNs can also be easily carried and
	stored in formats such as XML [W3C.REC-xml-19980210] or JSON		stored in formats such as XML [W3C.REC-xml-19980210], JSON [RFC8259]
	[RFC8259] [RFC8428]. Using URNs in these formats is often preferable		or SenML [RFC8428]. Using URNs in these formats is often preferable
	as they are universally recognized and self-describing, and therefore		as they are universally recognized and self-describing, and therefore
	avoid the need for agreeing to interpret an octet string as a		avoid the need for agreeing to interpret an octet string as a
	specific form of a MAC address, for instance. Passing URNs may		specific form of a MAC address, for instance. Passing URNs may
	consume additional bytes compared to, for instance, passing 4-byte		consume additional bytes compared to, for instance, passing 4-byte
	binary IPv4 addresses, but offers some flexibility in return.		binary IPv4 addresses, but offers some flexibility in return.
	This document defines identifier URN types for situations where no		This document defines identifier URN types for situations where no
	such convenient type already exists. For instance, [RFC6920] defines		such convenient type already exists. For instance, [RFC6920] defines
	cryptographic identifiers, [RFC7254] defines International Mobile		cryptographic identifiers, [RFC7254] defines International Mobile
	station Equipment Identity (IMEI) identifiers for use with 3GPP		station Equipment Identity (IMEI) identifiers for use with 3GPP
	skipping to change at page 3, line 32		skipping to change at page 3, line 32
	(MEID) identifiers for use with 3GPP2 cellular systems. Those URN		(MEID) identifiers for use with 3GPP2 cellular systems. Those URN
	types should be employed when such identifiers are transported; this		types should be employed when such identifiers are transported; this
	document does not redefine these identifiers in any way.		document does not redefine these identifiers in any way.
	Universally Unique IDentifier (UUID) URNs [RFC4122] are another		Universally Unique IDentifier (UUID) URNs [RFC4122] are another
	alternative way for representing device identifiers, and already		alternative way for representing device identifiers, and already
	support MAC addresses as one type of an identifier. However, UUIDs		support MAC addresses as one type of an identifier. However, UUIDs
	can be inconvenient in environments where it is important that the		can be inconvenient in environments where it is important that the
	identifiers are as simple as possible and where additional		identifiers are as simple as possible and where additional
	requirements on stable storage, real-time clocks, and identifier		requirements on stable storage, real-time clocks, and identifier
	length can be prohibitive. UUID-based identifiers are recommended		length can be prohibitive. Often, UUID-based identifiers are
	for all general purpose uses when MAC addresses are available as		preferred for general purpose uses instead of MAC-based device URNs
	identifiers. The device URN defined in this document is recommended		defined in this document. The device URNs are recommended for
	for constrained environments.		constrained environments.
	Future device identifier types can extend the device URN type defined		Future device identifier types can extend the device URN type defined
	here, or define their own URNs.		here (see Section 7), or define their own URNs.
	Note that long-term stable unique identifiers are problematic for		Note that long-term stable unique identifiers are problematic for
	privacy reasons and should be used with care as described in		privacy reasons and should be used with care as described in
	[RFC7721].		[RFC7721].
	The rest of this document is organized as follows. Section 3 defines		The rest of this document is organized as follows. Section 3 defines
	the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48,		the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48,
	EUI-48 and EUI-64 addresses and 1-Wire device identifiers. Section 5		EUI-48 and EUI-64 addresses and 1-Wire device identifiers. Section 5
	gives examples. Section 6 discusses the security and privacy		gives examples. Section 6 discusses the security and privacy
	considerations of the new URN type. Finally, Section 7 specifies the		considerations of the new URN type. Finally, Section 7 specifies the
	skipping to change at page 5, line 17		skipping to change at page 5, line 17
	part of the IETF-provided basic URN types, covering identifiers that		part of the IETF-provided basic URN types, covering identifiers that
	have previously not been possible to use in URNs.		have previously not been possible to use in URNs.
	3.2. Syntax		3.2. Syntax
	Syntax: The identifier is expressed in ASCII characters and has a		Syntax: The identifier is expressed in ASCII characters and has a
	hierarchical structure as follows:		hierarchical structure as follows:
	devurn = "urn:dev:" body componentpart		devurn = "urn:dev:" body componentpart
	body = macbody / owbody / orgbody / osbody / opsbody / otherbody		body = macbody / owbody / orgbody / osbody / opsbody / otherbody
	macbody = %s "mac:" hexstring		macbody = %s"mac:" hexstring
	owbody = %s "ow:" hexstring		owbody = %s"ow:" hexstring
	orgbody = %s "org:" posnumber "-" identifier *( ":" identifier )		orgbody = %s"org:" posnumber "-" identifier *( ":" identifier )
	osbody = %s "os:" posnumber "-" serial *( ":" identifier )		osbody = %s"os:" posnumber "-" serial *( ":" identifier )
	opsbody = %s "ops:" posnumber "-" product "-" serial *( ":" identifier )		opsbody = %s"ops:" posnumber "-" product "-" serial *( ":" identifier )
	otherbody = subtype ":" identifier *( ":" identifier )		otherbody = subtype ":" identifier *( ":" identifier )
	subtype = LALPHA *(DIGIT / LALPHA)		subtype = LALPHA *(DIGIT / LALPHA)
	identifier = 1*devunreserved		identifier = 1*devunreserved
	identifiernodash = 1*devunreservednodash		identifiernodash = 1*devunreservednodash
	product = identifiernodash		product = identifiernodash
	serial = identifier		serial = identifier
	componentpart = *( "_" identifier )		componentpart = *( "_" identifier )
	devunreservednodash = ALPHA / DIGIT / "."		devunreservednodash = ALPHA / DIGIT / "."
	devunreserved = devunreservednodash / "-"		devunreserved = devunreservednodash / "-"
	hexstring = 1*(hexdigit hexdigit)		hexstring = 1*(hexdigit hexdigit)
	skipping to change at page 7, line 21		skipping to change at page 7, line 21
	Device identifiers are generally expected to identify a unique		Device identifiers are generally expected to identify a unique
	device, barring the accidental issue of multiple devices with the		device, barring the accidental issue of multiple devices with the
	same identifiers. In many cases, device identifiers can also be		same identifiers. In many cases, device identifiers can also be
	changed by users, or sometimes assigned in an algorithmic or local		changed by users, or sometimes assigned in an algorithmic or local
	fashion. Any potential conflicts arising from such assignments are		fashion. Any potential conflicts arising from such assignments are
	not something that the DEV URNs as such manage; they simply are there		not something that the DEV URNs as such manage; they simply are there
	to refer to a particular identifier. And of course, a single device		to refer to a particular identifier. And of course, a single device
	may (and often does) have multiple identifiers, e.g., identifiers		may (and often does) have multiple identifiers, e.g., identifiers
	associated with different link technologies it supports.		associated with different link technologies it supports.
	The DEV URN type SHOULD only be used for persistent identifiers, such		The DEV URN type SHOULD only be used for hardware-based identifiers
	as hardware-based identifiers.		that are expected to be persistent (with some limits, as discussed
			above).
	3.4. Security and Privacy		3.4. Security and Privacy
	Security and Privacy: As discussed in Section 6, care must be taken		Security and Privacy: As discussed in Section 6, care must be taken
	in the use of device-identifier-based identifiers due to their nature		in the use of device-identifier-based identifiers due to their nature
	as long-term identifiers that are not normally changeable. Leakage		as long-term identifiers that are not normally changeable. Leakage
	of these identifiers outside systems where their use is justified		of these identifiers outside systems where their use is justified
	should be controlled.		should be controlled.
	3.5. Interoperability		3.5. Interoperability
	skipping to change at page 8, line 27		skipping to change at page 8, line 31
	assigned by that organization.		assigned by that organization.
	In the DEV URN "mac" subtype the hexstring is simply the full EUI-64		In the DEV URN "mac" subtype the hexstring is simply the full EUI-64
	identifier represented as a hexadecimal string. It is always exactly		identifier represented as a hexadecimal string. It is always exactly
	16 characters long.		16 characters long.
	MAC-48 and EUI-48 identifiers are also supported by the same DEV URN		MAC-48 and EUI-48 identifiers are also supported by the same DEV URN
	subtype. To convert a MAC-48 address to an EUI-64 identifier, The		subtype. To convert a MAC-48 address to an EUI-64 identifier, The
	OUI of the MAC-48 address (the first three octets) becomes the		OUI of the MAC-48 address (the first three octets) becomes the
	organization identifier of the EUI-64 (the first three octets). The		organization identifier of the EUI-64 (the first three octets). The
	fourth and fifth octets of the EUI are set to the fixed value FFFF		fourth and fifth octets of the EUI are set to the fixed value 0xffff
	hexadecimal. The last three octets of the MAC-48 address become the		(hexadecimal). The last three octets of the MAC-48 address become
	last three octets of the EUI-64. The same process is used to convert		the last three octets of the EUI-64. The same process is used to
	an EUI-48 identifier, but the fixed value FFFE is used instead.		convert an EUI-48 identifier, but the fixed value 0xfffe is used
			instead.
	Identifier assignment for all of these identifiers rests within the		Identifier assignment for all of these identifiers rests within the
	IEEE Registration Authority.		IEEE Registration Authority.
			Note that where randomized MAC addresses are used, the resulting DEV
			URNs cannot be expected to have uniqueness, as discussed in
			Section 3.3.
	4.2. 1-Wire Device Identifiers		4.2. 1-Wire Device Identifiers
	The 1-Wire* system is a device communications bus system designed by		The 1-Wire* system is a device communications bus system designed by
	Dallas Semiconductor Corporation. 1-Wire devices are identified by a		Dallas Semiconductor Corporation. 1-Wire devices are identified by a
	64-bit identifier that consists of 8 bit family code, 48 bit		64-bit identifier that consists of 8 bit family code, 48 bit
	identifier unique within a family, and 8 bit CRC code [OW].		identifier unique within a family, and 8 bit CRC code [OW].
	*) 1-Wire is a registered trademark.		*) 1-Wire is a registered trademark.
	In DEV URNs with the "ow" subtype the hexstring is a representation		In DEV URNs with the "ow" subtype the hexstring is a representation
	of the full 64 bit identifier as a hexadecimal string. It is always		of the full 64-bit identifier as a hexadecimal string. It is always
	exactly 16 characters long. Note that the last two characters		exactly 16 characters long. Note that the last two characters
	represent the 8-bit CRC code. Implementations MAY check the validity		represent the 8-bit CRC code. Implementations MAY check the validity
	of this code.		of this code.
	Family code and identifier assignment for all 1-Wire devices rests		Family code and identifier assignment for all 1-Wire devices rests
	with the manufacturers.		with the manufacturers.
	4.3. Organization-Defined Identifiers		4.3. Organization-Defined Identifiers
	Device identifiers that have only a meaning within an organization		Device identifiers that have only a meaning within an organization
	skipping to change at page 12, line 33		skipping to change at page 12, line 33
	6.1. Privacy		6.1. Privacy
	Other devices in the same network may or may not be able to identify		Other devices in the same network may or may not be able to identify
	the device. For instance, on an Ethernet network, the MAC address of		the device. For instance, on an Ethernet network, the MAC address of
	a device is visible to all other devices.		a device is visible to all other devices.
	DEV URNs often represent long-term stable unique identifiers for		DEV URNs often represent long-term stable unique identifiers for
	devices. Such identifiers may have privacy and security implications		devices. Such identifiers may have privacy and security implications
	because they may enable correlating information about a specific		because they may enable correlating information about a specific
	device over a long period of time, location tracking, and device		device over a long period of time, location tracking, and device
	specific vulnerability exploitation [RFC7721]. Also, usually there		specific vulnerability exploitation [RFC7721]. Also, in some systems
	is no easy way to change the identifier. Therefore these identifiers		there is no easy way to change the identifier. Therefore these
	need to be used with care and especially care should be taken to		identifiers need to be used with care and especially care should be
	avoid leaking them outside of the system that is intended to use the		taken to avoid leaking them outside of the system that is intended to
	identifiers.		use the identifiers.
	6.2. Validity		6.2. Validity
	Information about identifiers may have significant effects in some		Information about identifiers may have significant effects in some
	applications. For instance, in many sensor systems the identifier		applications. For instance, in many sensor systems the identifier
	information is used for deciding how to use the data carried in a		information is used for deciding how to use the data carried in a
	measurement report. On some other systems, identifiers may be used		measurement report. On some other systems, identifiers may be used
	in policy decisions.		in policy decisions.
	It is important that systems are designed to take into account the		It is important that systems are designed to take into account the
	possibility of devices reporting incorrect identifiers (either		possibility of devices reporting incorrect identifiers (either
	accidentally or maliciously) and the manipulation of identifiers in		accidentally or maliciously) and the manipulation of identifiers in
	communications by illegitimate entities on the path. Integrity		communications by illegitimate entities. Integrity protection of
	protection of communications or data objects, the use of trusted		communications or data objects, the use of trusted devices, and
	devices, and various management practices can help address these		various management practices can help address these issues.
	issues.
			The advice from [RFC4122] Section 6 also applies: Do not assume that
			DEV URNs are hard to guess.
	7. IANA Considerations		7. IANA Considerations
	This document requests the registration of a new URN namespace for		This document requests the registration of a new URN namespace for
	"DEV", as described in Section 3.		"DEV", as described in Section 3.
	IANA is asked to create a "DEV URN Subtypes" registry. The initial		IANA is asked to create a "DEV URN Subtypes" registry. The initial
	values in this registry are as follows:		values in this registry are as follows:
	Subtype Description Reference		Subtype Description Reference
	skipping to change at page 16, line 29		skipping to change at page 16, line 34
	editor.org/info/rfc8464>.		editor.org/info/rfc8464>.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.		Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
	Stok, "CoRE Resource Directory", draft-ietf-core-resource-		Stok, "CoRE Resource Directory", draft-ietf-core-resource-
	directory-26 (work in progress), November 2020.		directory-26 (work in progress), November 2020.
	[LwM2M] "OMA Lightweight Machine to Machine Requirements", OMA		[LwM2M] "OMA Lightweight Machine to Machine Requirements", OMA
	Standard Candidate Version 1.2, January 2019.		Standard Candidate Version 1.2, January 2019.
	Appendix A. Changes from Previous Version		Appendix A. Changes from Previous Versions
	Editor's note: Please remove this section before publication.		Editor's note: Please remove this section before publication.
			Version -11 was created to address non-blocking comments from the
			IESG review. This version made the following changes:
			o Removed space after the "%s" in the ABNF RFC 7405 syntax.
			o Softened and clarified the recommendation regarding UUIDs in
			Section 1.
			o Added a paragraph about the impacts of using randomized MAC
			addresses.
			o Added advice regarding ease of guessing DEV URNs, in Section 6.2.
			o Simplified and clarified the "illegitimate entities" statement in
			Section 6.2.
			o Clarified the persistence statement in Section 3.3.
	Version -10 made the following changes:		Version -10 made the following changes:
	o Restricted the case of "mac", "ow", etc. any subtype to lower		o Restricted the case of "mac", "ow", etc. any subtype to lower
	case. This required the adoption of RFC 7405 syntax in the ABNF.		case. This required the adoption of RFC 7405 syntax in the ABNF.
	o Added a reserved "example" subtype to be used in examples.		o Added a reserved "example" subtype to be used in examples.
	o Clarified global applicability, particularly in cases with local		o Clarified global applicability, particularly in cases with local
	or manual assignment mechanisms.		or manual assignment mechanisms.
	skipping to change at page 20, line 39		skipping to change at page 21, line 16
	Version -03 made several minor corrections to the ABNF as well as		Version -03 made several minor corrections to the ABNF as well as
	some editorial corrections.		some editorial corrections.
	Appendix B. Acknowledgments		Appendix B. Acknowledgments
	The authors would like to thank Ari Keranen, Stephen Farrell,		The authors would like to thank Ari Keranen, Stephen Farrell,
	Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez,		Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez,
	Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim		Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim
	Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba,		Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba,
	Amanda Baber, Juha Hakala, Dale Worley, Brian Weis, John Klensin,		Amanda Baber, Juha Hakala, Dale Worley, Warren Kumari, Benjamin
	Dave Thaler, Russ Housley, Dan Romascanu, and Ahmad Muhanna for		Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ Housley, Dan
	feedback and interesting discussions in this problem space. We would		Romascanu, Eric Vyncke, Roman Danyliw, and Ahmad Muhanna for feedback
	also like to note prior documents that focused on specific device		and interesting discussions in this problem space. We would also
			like to note prior documents that focused on specific device
	identifiers, such as [RFC7254] or [RFC8464].		identifiers, such as [RFC7254] or [RFC8464].
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
	Finland		Finland
	Email: jari.arkko@piuha.net		Email: jari.arkko@piuha.net
	Cullen Jennings		Cullen Jennings
	Cisco		Cisco
	170 West Tasman Drive		170 West Tasman Drive
End of changes. 20 change blocks.
	41 lines changed or deleted		69 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/