draft-ietf-core-dev-urn-08.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: Informational C. Jennings		Intended status: Standards Track C. Jennings
	Expires: May 6, 2021 Cisco		Expires: July 9, 2021 Cisco
	Z. Shelby		Z. Shelby
	ARM		ARM
	November 2, 2020		January 5, 2021
	Uniform Resource Names for Device Identifiers		Uniform Resource Names for Device Identifiers
	draft-ietf-core-dev-urn-08		draft-ietf-core-dev-urn-09
	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 easily passed along in any application that		representation can be easily passed along in any application that
	needs the information.		needs the 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 May 6, 2021.		This Internet-Draft will expire on July 9, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	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. Requirements language . . . . . . . . . . . . . . . . . . . . 3		2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
	3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4		3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4		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 . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6
	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 . . . . . . . . . . . . . . . . . 7
	3.9. Revision Information . . . . . . . . . . . . . . . . . . 7		3.9. Revision Information . . . . . . . . . . . . . . . . . . 7
	4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7		4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7		4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8		4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8
	4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8		4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8
	4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9		4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9
	4.5. Organization Product and Serial Numbers . . . . . . . . . 9		4.5. Organization Product and Serial Numbers . . . . . . . . . 9
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6.2. Validity . . . . . . . . . . . . . . . . . . . . . . . . 12
			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 . . . . . . . . . . . 15		Appendix A. Changes from Previous Version . . . . . . . . . . . 16
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	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 easily passed along in any		A URN-based representation can be easily passed along in any
	skipping to change at page 3, line 4		skipping to change at page 3, line 5
	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 easily passed along in any		A URN-based representation can be easily passed along in any
	application that needs the information, as it fits in protocols		application that needs the information, as it fits in 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] or JSON
	[RFC8259] [RFC8428]. Using URNs in these formats is often preferable		[RFC8259] [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.		specific form of a MAC address, for instance.
	This document defines identity URN types for situations where no such		This document defines identifier URN types for situations where no
	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
	cellular systems, and [RFC8464] defines Mobile Equipment Identity		cellular systems, and [RFC8464] defines Mobile Equipment Identity
	(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 identities 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 of type of an identifier. However,		support MAC addresses as one of type of an identifier. However,
	UUIDs can be inconvenient in environments where it is important that		UUIDs can be inconvenient in environments where it is important that
	the identifiers are as simple as possible and where additional		the 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. UUID-based identifiers are recommended
	for all general purpose uses when MAC addresses are available as		for all general purpose uses when MAC addresses are available as
	identifiers. The device URN defined in this document is recommended		identifiers. The device URN defined in this document is recommended
	for constrained environments.		for 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, 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 or avoided as described		privacy reasons and should be used with care as described in
	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
	IANA registration for the new URN type and sets requirements for		IANA registration for the new URN type and sets requirements for
	subtype allocations within this type.		subtype allocations within this type.
	2. Requirements language		2. Requirements language
	skipping to change at page 4, line 22		skipping to change at page 4, line 22
	Date: 2020-06-24		Date: 2020-06-24
	Registrant: IETF and the CORE working group. Should the working		Registrant: IETF and the CORE working group. Should the working
	group cease to exist, discussion should be directed to the general		group cease to exist, discussion should be directed to the general
	IETF discussion forums or the IESG.		IETF discussion forums or the IESG.
	3.1. Purpose		3.1. Purpose
	Purpose: The DEV URNs identify devices with device-specific		Purpose: The DEV URNs identify devices with device-specific
	identifiers such as network card hardware addresses. DEV URN is		identifiers such as network card hardware addresses. DEV URNs are
	global in scope.		scoped to be globally applicable (see [RFC8141] Section 6.4.1) and
			enable systems to use these identifiers from multiple sources in an
			interoperable manner.
	Some typical applications include equipment inventories and smart		Some typical applications include equipment inventories and smart
	object systems.		object systems.
	DEV URNs can be used in various ways in applications, software		DEV URNs can be used in various ways in applications, software
	systems, and network components, in tasks ranging from discovery (for		systems, and network components, in tasks ranging from discovery (for
	instance when discovering 1-wire network devices or detecting MAC-		instance when discovering 1-wire network devices or detecting MAC-
	addressable devices on a LAN) to intrusion detection systems and		addressable devices on a LAN) to intrusion detection systems and
	simple catalogues of system information.		simple catalogues of system information.
	While it is possible to implement resolution systems for specific		While it is possible to implement resolution systems for specific
	applications or network locations, DEV URNs are typically not used in		applications or network locations, DEV URNs are typically not used in
	a way that requires resolution beyond direct observation of the		a way that requires resolution beyond direct observation of the
	relevant identity fields in local link communication. However, it is		relevant identifier fields in local link communication. However, it
	often useful to be able to pass device identity information in		is often useful to be able to pass device identifier information in
	generic URN fields in databases or protocol fields, which makes the		generic URN fields in databases or protocol fields, which makes the
	use of URNs for this purpose convenient.		use of URNs for this purpose convenient.
	The DEV URN name space complements existing name spaces such as those		The DEV URN name space complements existing name spaces such as those
	involving IMEI or UUID identifiers. DEV URNs are expected to be a		involving IMEI or UUID identifiers. DEV URNs are expected to be a
	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 = "mac:" hexstring		macbody = "mac:" hexstring
	owbody = "ow:" hexstring		owbody = "ow:" hexstring
	orgbody = "org:" number "-" identifier *( ":" identifier )		orgbody = "org:" posnumber "-" identifier *( ":" identifier )
	osbody = "os:" number "-" serial *( ":" identifier )		osbody = "os:" posnumber "-" serial *( ":" identifier )
	opsbody = "ops:" number "-" product "-" serial *( ":" identifier )		opsbody = "ops:" posnumber "-" product "-" serial *( ":" identifier )
	otherbody = subtype ":" identifier *( ":" identifier )		otherbody = subtype ":" identifier *( ":" identifier )
	subtype = ALPHA *(DIGIT / ALPHA)		subtype = ALPHA *(DIGIT / ALPHA)
	identifier = 1*unreserved		identifier = 1*devunreserved
	identifiernodash = 1*unreservednodash		identifiernodash = 1*devunreservednodash
	product = identifiernodash		product = identifiernodash
	serial = identifier		serial = identifier
	componentpart = *( "_" identifier )		componentpart = *( "_" identifier )
	unreservednodash = ALPHA / DIGIT / "."		devunreservednodash = ALPHA / DIGIT / "."
	unreserved = unreservednodash / "-"		devunreserved = devunreservednodash / "-"
	hexstring = 1*(hexdigit hexdigit)		hexstring = 1*(hexdigit hexdigit)
	hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"		hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
	number = 1*DIGIT		posnumber = NZDIGIT *DIGIT
	ALPHA = %x41-5A / %x61-7A		ALPHA = %x41-5A / %x61-7A
	DIGIT = %x30-39		NZDIGIT = %x31-39
			DIGIT = %x30-39
	The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and		The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
	ALPHA rules originally defined in [RFC5234], exactly as defined		ALPHA rules originally defined in [RFC5234], exactly as defined
	there.		there.
	The device identity namespace includes three subtypes (see Section 4,		The device identifier namespace includes five subtypes (see
	and more may be defined in the future as specified in Section 7.		Section 4, and more may be defined in the future as specified in
			Section 7.
	The optional underscore-separated components following the hexstring		The optional underscore-separated components following the hexstring
	are strings depicting individual aspects of a device. The specific		are strings depicting individual aspects of a device. The specific
	strings and their semantics are up to the designers of the device,		strings and their semantics are up to the designers of the device,
	but could be used to refer to specific interfaces or functions within		but could be used to refer to specific interfaces or functions within
	the device.		the device.
	With the exception of the MAC-address and 1-Wire DEV URNs, each DEV		With the exception of the MAC-address and 1-Wire DEV URNs, each DEV
	URN may also contain optional colon-separated identifiers. These are		URN may also contain optional colon-separated identifiers. These are
	provided for extensibility.		provided for extensibility.
	There are no special character encoding rules or considerations for		There are no special character encoding rules or considerations for
	conforming with the URN syntax, beyond those applicable for URNs in		conforming with the URN syntax, beyond those applicable for URNs in
	general [RFC8141], or the context where these URNs are carried (e.g.,		general [RFC8141], or the context where these URNs are carried (e.g.,
	inside JSON [RFC8259] or SenML [RFC8428]).		inside JSON [RFC8259] or SenML [RFC8428]). However, due to the SenML
			RFC 8428 Section 4.5.1 rules, DEV URNs do not support percent-
			encoding.
	DEV URNs do not use r-, q-, or f-components.		DEV URNs do not use r-, q-, or f-components.
	Specific subtypes of DEV URNs may be validated through mechanisms		Specific subtypes of DEV URNs may be validated through mechanisms
	discussed in Section 4.		discussed in Section 4.
	The string representation of the device identity URN and of the MEID		The string representation of the device identifier URN is fully
	sub namespace is fully compatible with the URN syntax.		compatible with the URN syntax.
	3.2.1. Character Case and URN-Equivalence		3.2.1. Character Case and URN-Equivalence
	The DEV URN syntax allows both upper and lower case characters. The		The DEV URN syntax allows both upper and lower case characters. The
	URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1,		URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1,
	i.e,. two URNs are URN-equivalent if their assigned-name portions are		i.e,. two URNs are URN-equivalent if their assigned-name portions are
	octet-by-octet equal after applying case normalization to the URI		octet-by-octet equal after applying case normalization to the URI
	scheme ("urn"), namespace identifier ("dev"), and any percent-encoded		scheme ("urn") and namespace identifier ("dev"). The rest of the DEV
	characters. The rest of the DEV URN is compared in a case sensitive		URN is compared in a case sensitive manner. It should be noted that
	manner. It should be noted that URN-equivalence matching merely		URN-equivalence matching merely quickly shows that two URNs are
	quickly shows that two URNs are definitely the same for the purposes		definitely the same for the purposes of caching and other similar
	of caching and other similar uses. Two DEV URNs may still refer to		uses. Two DEV URNs may still refer to the same entity, and not be
	the same entity, and not be found URN-equivalent according to the RFC		found URN-equivalent according to the RFC 8141 definition. For
	8141 definition. For instance, in the ABNF syntax strings are case-		instance, in ABNF, strings are case-insensitive (see [RFC5234]
	insensitive, and a MAC address could be represented either with		Section 2.3), and a MAC address could be represented either with
	uppercase or lowercase hexadecimal digits.		uppercase or lowercase hexadecimal digits.
	Character case is not otherwise significant for the DEV URN subtypes		Character case is not otherwise significant for the DEV URN subtypes
	defined in this document. However, future subtypes might include		defined in this document. However, future subtypes might include
	identifiers that use encodings such as BASE64, which encode strings		identifiers that use encodings such as BASE64, which encode strings
	in a larger variety of characters, and might even encode binary data.		in a larger variety of characters, and might even encode binary data.
	To facilitate equivalence checks, it is RECOMMENDED that		To facilitate equivalence checks, it is RECOMMENDED that
	implementations always use lower case letters where they have a		implementations always use lower case letters where they have a
	choice in case, unless there is a reason otherwise. (Such a reason		choice in case, unless there is a reason otherwise. (Such a reason
	might be, for instance, the use of a subtype that requires the use of		might be, for instance, the use of a subtype that requires the use of
	both upper case and lower case letters.)		both upper case and lower case letters.)
	3.3. Assignment		3.3. Assignment
	Assignment: The process for identifier assignment is dependent on the		Assignment: The process for identifier assignment is dependent on the
	used subtype, and documented in the specific subsection under		used subtype, and documented in the specific subsection under
	Section 4.		Section 4.
	Device identifiers are generally expected to be unique, barring the		Device identifiers are generally expected to identify a unique
	accidental issue of multiple devices with the same identifiers. In		device, barring the accidental issue of multiple devices with the
	many cases, device identifiers can also be changed by users, or		same identifiers. In many cases, device identifiers can also be
	sometimes assigned in an algorithmic fashion. Any potential		changed by users, or sometimes assigned in an algorithmic fashion.
	conflicts arising from such assignments are not something that the		Any potential conflicts arising from such assignments are not
	DEV URNs as such manage; they simply are there to refer to a		something that the DEV URNs as such manage; they simply are there to
	particular identifier.		refer to a particular identifier. And of course, a single device may
			(and often does) have multiple identifiers, e.g,. identifiers
			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 persistent identifiers, such
	as hardware-based identifiers or cryptographic identifiers based on		as hardware-based identifiers.
	keys intended for long-term usage.
	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
	Interoperability: There are no specific interoperability concerns.		Interoperability: There are no specific interoperability concerns.
	3.6. Resolution		3.6. Resolution
	Resolution: The device identities are not expected to be globally		Resolution: The device identifiers are not expected to be globally
	resolvable. No identity resolution system is expected. Systems may		resolvable. No identifier resolution system is expected. Systems
	perform local matching of identities to previously seen identities or		may perform local matching of identifiers to previously seen
	configured information, however.		identifiers or configured information, however.
	3.7. Documentation		3.7. Documentation
	See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the		See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the
	RFC number of this document).		RFC number of this document).
	3.8. Additional Information		3.8. Additional Information
	See Section 1 for a discussion of related name spaces.		See Section 1 for a discussion of related name spaces.
	skipping to change at page 8, line 46		skipping to change at page 9, line 13
	can also be used to represent vendor-specific or experimental		can also be used to represent vendor-specific or experimental
	identifiers or identifiers designed for use within the context of an		identifiers or identifiers designed for use within the context of an
	organisation.		organisation.
	Organisations are identified by their Private Enterprise Number (PEN)		Organisations are identified by their Private Enterprise Number (PEN)
	[RFC2578]. These numbers can be obtained from IANA. Current PEN		[RFC2578]. These numbers can be obtained from IANA. Current PEN
	assignments can be viewed at https://www.iana.org/assignments/		assignments can be viewed at https://www.iana.org/assignments/
	enterprise-numbers/enterprise-numbers and new assignments requested		enterprise-numbers/enterprise-numbers and new assignments requested
	at https://pen.iana.org/pen/PenApplication.page.		at https://pen.iana.org/pen/PenApplication.page.
	When included in an "org" DEV URN, the number MUST NOT be padded with		Note that when included in an "org" DEV URN, the number can not be
	extra leading zeroes.		zero or have leading zeroes, as the ABNF requires the number to start
			with a non-zero digit.
	4.4. Organization Serial Numbers		4.4. Organization Serial Numbers
	The "os" subtype specifies an organization and a serial number.		The "os" subtype specifies an organization and a serial number.
	Organizations are identified by their PEN. As with the organization-		Organizations are identified by their PEN. As with the organization-
	defined identifiers (Section 4.3), PEN number assignments are		defined identifiers (Section 4.3), PEN number assignments are
	maintained by IANA, and assignments for new organizations can be made		maintained by IANA, and assignments for new organizations can be made
	easily.		easily.
	Editor's Note (Please remove before publication): The DEV URN "os"		Editor's Note (Please remove before publication): The DEV URN "os"
	subtype has originally been defined in the LwM2M standard, but has		subtype has originally been defined in the LwM2M standard, but has
	been incorporated here to collect all syntax associated with DEV		been incorporated here to collect all syntax associated with DEV
	URNs in one place. At the same time, the syntax of this subtype		URNs in one place. At the same time, the syntax of this subtype
	was changed to avoid the possibility of characters that are not		was changed to avoid the possibility of characters that are not
	allowed in SenML Name field (see [RFC8428] Section 4.5.1).		allowed in SenML Name field (see [RFC8428] Section 4.5.1).
	When included in an "os" DEV URN, the PEN number MUST NOT be		Organizations are also encouraged to select serial number formats
	padded with extra leading zeroes. Organizations are also		that avoid possibility for ambiguity, in the form of leading
	encouraged to select serial number formats that avoid possibility		zeroes or otherwise.
	for ambiguity, in the form of leading zeroes or otherwise.
	Organization serial number DEV URNs consist of the PEN number and the		Organization serial number DEV URNs consist of the PEN number and the
	serial number. As with other DEV URNs, for carrying additional		serial number. As with other DEV URNs, for carrying additional
	information and extensibility, optional colon-separated identifiers		information and extensibility, optional colon-separated identifiers
	and underscore-separated components may also be included. The serial		and underscore-separated components may also be included. The serial
	numbers themselves are defined by the organization, and this		numbers themselves are defined by the organization, and this
	specification does not specify how they are allocated.		specification does not specify how they are allocated.
	4.5. Organization Product and Serial Numbers		4.5. Organization Product and Serial Numbers
	skipping to change at page 10, line 5		skipping to change at page 10, line 17
	LwM2M standard, and its format has been slightly changed.		LwM2M standard, and its format has been slightly changed.
	Organization product and serial number DEV URNs consist of the PEN		Organization product and serial number DEV URNs consist of the PEN
	number, product class, and the serial number. As with other DEV		number, product class, and the serial number. As with other DEV
	URNs, for carrying additional information and extensibility, optional		URNs, for carrying additional information and extensibility, optional
	colon-separated identifiers and underscore-separated components may		colon-separated identifiers and underscore-separated components may
	also be included. Both the product class and serial numbers		also be included. Both the product class and serial numbers
	themselves are defined by the organization, and this specification		themselves are defined by the organization, and this specification
	does not specify how thy are allocated.		does not specify how thy are allocated.
	When included in an "ops" DEV URN, the PEN number MUST NOT be padded		Organizations are also encouraged to select product and serial number
	with extra leading zeroes. Organizations are also encouraged to		formats that avoid possibility for ambiguity.
	select product and serial number formats that avoid possibility for
	ambiguity.
	5. Examples		5. Examples
	The following three examples provide examples of MAC-based, 1-Wire,		The following provides some examples of DEV URNs:
	and Cryptographic identifiers:
	urn:dev:mac:0024beffff804ff1 # The MAC-48 address of		urn:dev:mac:0024beffff804ff1 # The MAC-48 address of
	# 0024be804ff1, converted		# 0024be804ff1, converted
	# to EUI-64 format		# to EUI-64 format
	urn:dev:mac:0024befffe804ff1 # The EUI-48 address of		urn:dev:mac:0024befffe804ff1 # The EUI-48 address of
	# 0024be804ff1, converted		# 0024be804ff1, converted
	# to EUI-64 format		# to EUI-64 format
	urn:dev:mac:acde48234567019f # The EUI-64 address of		urn:dev:mac:acde48234567019f # The EUI-64 address of
	skipping to change at page 11, line 46		skipping to change at page 11, line 46
	# dashes in it		# dashes in it
	urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial		urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial
	# number 5002 in the		# number 5002 in the
	# RFC 5612 example		# RFC 5612 example
	# organisation		# organisation
	urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined		urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined
	# subtype		# subtype
			The DEV URNs themselves can then appear in various contexts. A
			simple example of this is the use of DEV URNs in SenML data. For
			example, this example from [RFC8428] shows a measurement from a
			1-Wire temperature gauge encoded in the JSON syntax.
			[
			{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
			]
	6. Security Considerations		6. Security Considerations
	On most devices, the user can display device identifiers. Depending		On most devices, the user can display device identifiers. Depending
	on circumstances, device identifiers may or may not be modified or		on circumstances, device identifiers may or may not be modified or
	tampered with by the user. An implementation of the DEV URN MUST NOT		tampered with by the user. An implementation of the DEV URN MUST NOT
	change these properties from what they were intended. In particular,		change these properties from what they were intended. In particular,
	a device identifier that is intended to be immutable should not		a device identifier that is intended to be immutable should not
	become mutable as a part of implementing the DEV URN type. More		become mutable as a part of implementing the DEV URN type. More
	generally, nothing in this document should be construed to override		generally, nothing in this document should be construed to override
	what the relevant device specifications have already said about the		what the relevant device specifications have already said about the
	identifiers.		identifiers.
	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.
	The URNs generated according to the rules defined in this document		DEV URNs often represent long-term stable unique identifiers for
	result in long-term stable unique identifiers for the devices. Such		devices. Such identifiers may have privacy and security implications
	identifiers may have privacy and security implications because they		because they may enable correlating information about a specific
	may enable correlating information about a specific device over a		device over a long period of time, location tracking, and device
	long period of time, location tracking, and device specific		specific vulnerability exploitation [RFC7721]. Also, usually there
	vulnerability exploitation [RFC7721]. Also, usually there is no easy		is no easy way to change the identifier. Therefore these identifiers
	way to change the identifier. Therefore these identifiers need to be		need to be used with care and especially care should be taken to
	used with care and especially care should be taken to avoid leaking		avoid leaking them outside of the system that is intended to use the
	them outside of the system that is intended to use the identifiers.		identifiers.
			6.2. Validity
			Information about identifiers may have significant effects in some
			applications. For instance, in many sensor systems the identifier
			information is used for deciding how to use the data carried in a
			measurement report. On some other systems, identifiers may be used
			in policy decisions.
			It is important that systems are designed to take into account the
			possibility of devices reporting incorrect identifiers (either
			accidentally or maliciously) and the manipulation of identifiers in
			communications by illegitimate entities on the path. Integrity
			protection of communications or data objects, the use of trusted
			devices, and various management practices can help address these
			issues.
	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 15, line 33		skipping to change at page 16, line 11
	the International Mobile station Equipment Identity		the International Mobile station Equipment Identity
	(IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,		(IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
	<https://www.rfc-editor.org/info/rfc7254>.		<https://www.rfc-editor.org/info/rfc7254>.
	[RFC8464] Atarius, R., "A URN Namespace for Device Identity and		[RFC8464] Atarius, R., "A URN Namespace for Device Identity and
	Mobile Equipment Identity (MEID)", RFC 8464,		Mobile Equipment Identity (MEID)", RFC 8464,
	DOI 10.17487/RFC8464, September 2018, <https://www.rfc-		DOI 10.17487/RFC8464, September 2018, <https://www.rfc-
	editor.org/info/rfc8464>.		editor.org/info/rfc8464>.
	[I-D.ietf-core-resource-directory]		[I-D.ietf-core-resource-directory]
	Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.		Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
	Amsuess, "CoRE Resource Directory", draft-ietf-core-		Stok, "CoRE Resource Directory", draft-ietf-core-resource-
	resource-directory-25 (work in progress), July 2020.		directory-26 (work in progress), November 2020.
	Appendix A. Changes from Previous Version		Appendix A. Changes from Previous Version
			Version -08 of the WG draft took into account IANA, SECDIR, Gen-ART,
			and OPSDIR reviews. The following changes were made:
			o Aligned the use of identifiers vs. identity terms.
			o Added a security considerations subsection on validity of claimed
			identifiers.
			o Focused on "care" in the RFC 7721 reference, rather than "care and
			avoidance".
			o Renamed the "unreserved" ABNF terminal to avoid confusion with the
			general URN ABN terminal with the same name.
			o Removed the mistakenly included text about MEID subtype.
			o Clarified URN syntax differences and normalization rules wrt the
			lack of percent-encoding in DEV URNs.
			o Required PEN numbers to start with non-zero digit in the ABNF and
			changed the associated language later in the draft.
			o Text about case-insensitivity in RFC 5234 was clarified.
			o Text about uniqueness was clarified.
			o Text about global scope was clarified.
			o An example of DEV URN usage in SenML was added.
			o Editorial changes.
	Version -08 of the WG draft took into account Barry Leiba's AD review		Version -08 of the WG draft took into account Barry Leiba's AD review
	comments. To address these comments, changes were made in		comments. To address these comments, changes were made in
	o Further updates of the upper/lower case rules for the DEV URNs.		o Further updates of the upper/lower case rules for the DEV URNs.
	o Further updates to the ABNF.		o Further updates to the ABNF.
	o The use of HEXDIG from RFC 5234.		o The use of HEXDIG from RFC 5234.
	o IANA considerations for the creation of separate registry for the		o IANA considerations for the creation of separate registry for the
	skipping to change at page 18, line 28		skipping to change at page 19, line 37
	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, Dan Romascanu,
	and Ahmad Muhanna for feedback and interesting discussions in this		and Ahmad Muhanna for feedback and interesting discussions in this
	problem space. We would also like to note prior documents that		problem space. We would also like to note prior documents that
	focused on specific device identifiers, such as [RFC7254] or		focused on specific device identifiers, such as [RFC7254] or
	[RFC8464].		[RFC8464].
	Authors' Addresses		Authors' Addresses
	Jari Arkko		Jari Arkko
	Ericsson		Ericsson
	Jorvas 02420		Jorvas 02420
End of changes. 33 change blocks.
	94 lines changed or deleted		156 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/