draft-ietf-core-dev-urn-09.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 9, 2021 Cisco		Expires: July 17, 2021 Cisco
	Z. Shelby		Z. Shelby
	ARM		ARM
	January 5, 2021		January 13, 2021
	Uniform Resource Names for Device Identifiers		Uniform Resource Names for Device Identifiers
	draft-ietf-core-dev-urn-09		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 easily passed along in any application that		representation can be passed along in applications that need the
	needs the information.		information.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 9, 2021.		This Internet-Draft will expire on July 17, 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
	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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 6		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 . . . . . . . . . . . . . . . . . 7
	3.9. Revision Information . . . . . . . . . . . . . . . . . . 7		3.9. Revision Information . . . . . . . . . . . . . . . . . . 8
	4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . 8		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 . . . . . . . . . 9		4.5. Organization Product and Serial Numbers . . . . . . . . . 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 Version . . . . . . . . . . . 16
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 19		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		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 easily passed along in any		A URN-based representation can be passed along in applications that
	application that needs the information, as it fits in 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] 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. Passing URNs may
			consume additional bytes compared to, for instance, passing 4-byte
			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
	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 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 of type of an identifier. However,		support MAC addresses as one type of an identifier. However, UUIDs
	UUIDs can be inconvenient in environments where it is important that		can be inconvenient in environments where it is important that the
	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. 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 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
	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
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	skipping to change at page 4, line 16		skipping to change at page 4, line 22
	3. DEV URN Definition		3. DEV URN Definition
	Namespace Identifier: "dev" requested		Namespace Identifier: "dev" requested
	Version: 1		Version: 1
	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
	IETF discussion forums or the IESG.		application area or general 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 URNs are		identifiers such as network card hardware addresses. DEV URNs are
	scoped to be globally applicable (see [RFC8141] Section 6.4.1) and		scoped to be globally applicable (see [RFC8141] Section 6.4.1) and,
	enable systems to use these identifiers from multiple sources in an		in general, enable systems to use these identifiers from multiple
	interoperable manner.		sources in an interoperable manner. Note that in some deployments,
			ensuring uniqueness requires care if manual or local assignment
			mechanisms are used, as discussed in Section 3.3.
	Some typical applications include equipment inventories and smart		Some typical DEV URN applications include equipment inventories and
	object systems.		smart 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 identifier fields in local link communication. However, it		relevant identifier fields in local link communication. However, it
	is often useful to be able to pass device identifier 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.
	skipping to change at page 5, line 12		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 = "mac:" hexstring		macbody = %s "mac:" hexstring
	owbody = "ow:" hexstring		owbody = %s "ow:" hexstring
	orgbody = "org:" posnumber "-" identifier *( ":" identifier )		orgbody = %s "org:" posnumber "-" identifier *( ":" identifier )
	osbody = "os:" posnumber "-" serial *( ":" identifier )		osbody = %s "os:" posnumber "-" serial *( ":" identifier )
	opsbody = "ops:" posnumber "-" product "-" serial *( ":" identifier )		opsbody = %s "ops:" posnumber "-" product "-" serial *( ":" identifier )
	otherbody = subtype ":" identifier *( ":" identifier )		otherbody = subtype ":" identifier *( ":" identifier )
	subtype = ALPHA *(DIGIT / ALPHA)		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)
	hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"		hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
	posnumber = NZDIGIT *DIGIT		posnumber = NZDIGIT *DIGIT
	ALPHA = %x41-5A / %x61-7A		ALPHA = %x41-5A / %x61-7A
			LALPHA = %x41-5A
	NZDIGIT = %x31-39		NZDIGIT = %x31-39
	DIGIT = %x30-39		DIGIT = %x30-39
	The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and		The above syntax is represented in Augmented Backus-Naur Form (ABNF)
	ALPHA rules originally defined in [RFC5234], exactly as defined		form as defined in [RFC5234] and [RFC7405]. The syntax also copies
	there.		the DIGIT and ALPHA rules originally defined in [RFC5234], exactly as
			defined there.
	The device identifier namespace includes five subtypes (see		The device identifier namespace includes five subtypes (see
	Section 4, and more may be defined in the future as specified in		Section 4, and more may be defined in the future as specified in
	Section 7.		Section 7.
	The optional underscore-separated components following the hexstring		The optional underscore-separated components at the end of the DEV
	are strings depicting individual aspects of a device. The specific		URN depict individual aspects of a device. The specific strings and
	strings and their semantics are up to the designers of the device,		their semantics are up to the designers of the device, but could be
	but could be used to refer to specific interfaces or functions within		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]). However, due to the SenML		inside JSON [RFC8259] or SenML [RFC8428]). Due to the SenML RFC 8428
	RFC 8428 Section 4.5.1 rules, DEV URNs do not support percent-		Section 4.5.1 rules, it is not desirable to use percent-encoding in
	encoding.		DEV URNs, and the subtypes defined in this specification do not
			really benefit from percent-encoding. However, this specification
			does not deviate from the general syntax of URNs or their processing
			and normalization rules as specified in [RFC3986] and [RFC8141].
	DEV URNs do not use r-, q-, or f-components.		DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].
	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 identifier URN is fully		The string representation of the device identifier URN 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") and namespace identifier ("dev"). The rest of the DEV		scheme ("urn") and namespace identifier ("dev"). The rest of the DEV
	URN is compared in a case sensitive manner. It should be noted that		URN is compared in a case sensitive manner. It should be noted that
	URN-equivalence matching merely quickly shows that two URNs are		URN-equivalence matching merely quickly shows that two URNs are
	definitely the same for the purposes of caching and other similar		definitely the same for the purposes of caching and other similar
	uses. Two DEV URNs may still refer to the same entity, and not be		uses. Two DEV URNs may still refer to the same entity, and not be
	found URN-equivalent according to the RFC 8141 definition. For		found URN-equivalent according to the RFC 8141 definition. For
	instance, in ABNF, strings are case-insensitive (see [RFC5234]		instance, in ABNF, strings are case-insensitive (see [RFC5234]
	Section 2.3), 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.
	skipping to change at page 7, line 5		skipping to change at page 7, line 14
	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 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 fashion.		changed by users, or sometimes assigned in an algorithmic or local
	Any potential conflicts arising from such assignments are not		fashion. Any potential conflicts arising from such assignments are
	something that the DEV URNs as such manage; they simply are there to		not something that the DEV URNs as such manage; they simply are there
	refer to a particular identifier. And of course, a single device may		to refer to a particular identifier. And of course, a single device
	(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 persistent identifiers, such
	as hardware-based identifiers.		as hardware-based identifiers.
	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
	skipping to change at page 8, line 18		skipping to change at page 8, line 25
	The EUI-64 is formed from 24 or 36 bits of organization identifier		The EUI-64 is formed from 24 or 36 bits of organization identifier
	followed by 40 or 28 bits of device-specific extension identifier		followed by 40 or 28 bits of device-specific extension identifier
	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 Ethernet 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 FFFF
	hexadecimal. The last three octets of the Ethernet address become		hexadecimal. The last three octets of the MAC-48 address become the
	the last three octets of the EUI-64. The same process is used to		last three octets of the EUI-64. The same process is used to convert
	convert an EUI-48 identifier, but the fixed value FFFE is used		an EUI-48 identifier, but the fixed value FFFE is used instead.
	instead.
	Identifier assignment for all of these identifiers rests within the		Identifier assignment for all of these identifiers rests within the
	IEEE.		IEEE Registration Authority.
	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 byte 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 organisation		Device identifiers that have only a meaning within an organization
	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.		organization.
	Organisations are identified by their Private Enterprise Number (PEN)		Organizations 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.
	Note that when included in an "org" DEV URN, the number can not be		Note that when included in an "org" DEV URN, the number can not be
	zero or have leading zeroes, as the ABNF requires the number to start		zero or have leading zeroes, as the ABNF requires the number to start
	with a non-zero digit.		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"		Historical note: The "os" subtype was originally been defined in
	subtype has originally been defined in the LwM2M standard, but has		the Open Mobile Alliance "Lightweight Machine to Machine" standard
	been incorporated here to collect all syntax associated with DEV		[LwM2M], but has been incorporated here to collect all syntax
	URNs in one place. At the same time, the syntax of this subtype		associated with DEV URNs in one place. At the same time, the
	was changed to avoid the possibility of characters that are not		syntax of this subtype was changed to avoid the possibility of
	allowed in SenML Name field (see [RFC8428] Section 4.5.1).		characters that are not allowed in SenML Name field (see [RFC8428]
			Section 4.5.1).
	Organizations are also encouraged to select serial number formats
	that avoid possibility 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.
			Organizations are also encouraged to select serial number formats
			that avoid possibility for ambiguity, in the form of leading zeroes
			or otherwise.
	4.5. Organization Product and Serial Numbers		4.5. Organization Product and Serial Numbers
	The DEV URN "ops" subtype has originally been defined in the LwM2M		The DEV URN "ops" subtype has originally been defined in the LwM2M
	standard, but has been incorporated here to collect all syntax		standard, but has been incorporated here to collect all syntax
	associated with DEV URNs in one place. The "ops" subtype specifies		associated with DEV URNs in one place. The "ops" subtype specifies
	an organization, product class, and a serial number. Organizations		an organization, product class, and a serial number. Organizations
	are identified by their PEN. Again, as with the organization-defined		are identified by their PEN. Again, as with the organization-defined
	identifiers (Section 4.3), PEN number assignments are maintained by		identifiers (Section 4.3), PEN number assignments are maintained by
	IANA.		IANA.
	Editor's Note (Please remove before publication): As with the "os"		Historical note: As with the "os" subtype, the "ops" subtype has
	subtype, the "ops" subtype has originally been defined in the		originally been defined in OMA.
	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 they are allocated.
	Organizations are also encouraged to select product and serial number		Organizations are also encouraged to select product and serial number
	formats that avoid possibility for ambiguity.		formats that avoid possibility for ambiguity.
			4.6. Future Subtypes
			Additional subtypes may be defined in other, future specifications.
			See Section 7.
			The DEV URN "example" subtype is reserved for use in examples. It
			has no specific requirements beyond those expressed by the ABNF in
			Section 3.2.
	5. Examples		5. Examples
	The following provides some examples of DEV URNs:		The following provides some examples of DEV URNs:
	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
	# acde48234567019f		# acde48234567019f
	urn:dev:ow:10e2073a01080063 # The 1-Wire temperature		urn:dev:ow:10e2073a01080063 # A 1-Wire temperature
	# sensor in Jari's		# sensor
	# kitchen
	urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's		urn:dev:ow:264437f5000000ed_humidity # The humidity
	# humidity part		# part of a multi-sensor
			# device
	urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's		urn:dev:ow:264437f5000000ed_temperature # The temperature
	# temperature part		# part of a multi-sensor
			# device
	urn:dev:org:32473-foo # An organization-		urn:dev:org:32473-foo # An organization-
	# specific URN in		# specific URN in
	# the RFC 5612 example		# the RFC 5612 example
	# organisation, 32473.		# organization, 32473.
	urn:dev:os:32473-123456 # Device 123456 in		urn:dev:os:32473-123456 # Device 123456 in
	# the RFC 5612 example		# the RFC 5612 example
	# organisation		# organization
	urn:dev:os:32473-12-34-56 # A serial number with		urn:dev:os:32473-12-34-56 # A serial number with
	# 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		# organization
	urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined		urn:dev:example:new-1-2-3_comp # An example of something
	# subtype		# that is not defined today,
			# and is not one of the
			# mac, ow, os, or ops
			# subtypes
	The DEV URNs themselves can then appear in various contexts. A		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		simple example of this is the use of DEV URNs in SenML data. For
	example, this example from [RFC8428] shows a measurement from a		example, this example from [RFC8428] shows a measurement from a
	1-Wire temperature gauge encoded in the JSON syntax.		1-Wire temperature gauge encoded in the JSON syntax.
	[		[
	{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}		{"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
	change these properties from what they were intended. In particular,		preserve such limitations and behaviors associated with the device
	a device identifier that is intended to be immutable should not		identifiers. In particular, a device identifier that is intended to
	become mutable as a part of implementing the DEV URN type. More		be immutable should not become mutable as a part of implementing the
	generally, nothing in this document should be construed to override		DEV URN type. More generally, nothing in this document should be
	what the relevant device specifications have already said about the		construed to override what the relevant device specifications have
	identifiers.		already said about the 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.
	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
	skipping to change at page 13, line 20		skipping to change at page 13, line 22
	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
	------------------------------------------------------------------------		------------------------------------------------------------------------
	mac MAC Addresses (THIS RFC) Section 4.1		mac MAC Addresses (THIS RFC) Section 4.1
	ow 1-Wire Device Identifiers (THIS RFC) Section 4.2		ow 1-Wire Device Identifiers (THIS RFC) Section 4.2
	org Organization-Defined Identifiers (THIS RFC) Section 4.3		org Organization-Defined Identifiers (THIS RFC) Section 4.3
	os Organization Serial Numbers (THIS RFC) Section 4.4		os Organization Serial Numbers (THIS RFC) Section 4.4
	ops Organization Product and Serial Numbers (THIS RFC) Section 4.5		ops Organization Product and Serial Numbers (THIS RFC) Section 4.5
			example Reserved for examples (THIS RFC) Section 4.6
	Additional subtypes for DEV URNs can be defined through Specification		Additional subtypes for DEV URNs can be defined through Specification
	Required or IESG Approval [RFC8126]. These allocations are		Required or IESG Approval [RFC8126]. These allocations are
	appropriate when there is a new namespace of some type of device		appropriate when there is a new namespace of some type of device
	identifiers, defined in stable fashion and with a publicly available		identifiers, defined in stable fashion and with a publicly available
	specification that can be pointed to.		specification.
	Note that the organisation (Section 4.3) device identifiers can also		Note that the organization (Section 4.3) device identifiers can also
	be used in some cases, at least as a temporary measure. It is		be used in some cases, at least as a temporary measure. It is
	preferable, however, that long-term usage of a broadly employed		preferable, however, that long-term usage of a broadly employed
	device identifier be registered with IETF rather than used through		device identifier be registered with IETF rather than used through
	the organisation device identifier type.		the organization device identifier type.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	editor.org/info/rfc2119>.		editor.org/info/rfc2119>.
	skipping to change at page 14, line 29		skipping to change at page 14, line 34
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[IEEE.EUI64]		[IEEE.EUI64]
	IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",		IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
	IEEE , unknown year,		IEEE , unknown year,
	<https://standards.ieee.org/content/dam/ieee-		<https://standards.ieee.org/content/dam/ieee-
	standards/standards/web/documents/tutorials/eui.pdf>.		standards/standards/web/documents/tutorials/eui.pdf>.
	[OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use",		[OW] Maxim, "Guide to 1-Wire Communication", MAXIM
	MAXIM		https://www.maximintegrated.com/en/design/technical-
	http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June		documents/tutorials/1/1796.html, June 2008,
	2008,		<https://www.maximintegrated.com/en/design/technical-
	<http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.		documents/tutorials/1/1796.html>.
	8.2. Informative References		8.2. Informative References
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002, <https://www.rfc-		DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
	editor.org/info/rfc3261>.		editor.org/info/rfc3261>.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122,		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	DOI 10.17487/RFC4122, July 2005, <https://www.rfc-		DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
	editor.org/info/rfc4122>.		editor.org/info/rfc4122>.
			[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
			Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
			<https://www.rfc-editor.org/info/rfc4648>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext		[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,		Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015, <https://www.rfc-		DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
	editor.org/info/rfc7540>.		editor.org/info/rfc7540>.
	skipping to change at page 16, line 5		skipping to change at page 16, line 12
	Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,		Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
	<https://www.rfc-editor.org/info/rfc6920>.		<https://www.rfc-editor.org/info/rfc6920>.
	[RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P.		[RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P.
	Gosden, "A Uniform Resource Name Namespace for the Global		Gosden, "A Uniform Resource Name Namespace for the Global
	System for Mobile Communications Association (GSMA) and		System for Mobile Communications Association (GSMA) and
	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>.
			[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
			RFC 7405, DOI 10.17487/RFC7405, December 2014,
			<https://www.rfc-editor.org/info/rfc7405>.
	[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]
	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
			Standard Candidate Version 1.2, January 2019.
	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,		Editor's note: Please remove this section before publication.
			Version -11 made the following changes:
			o Removed space after the "%s" in the ABNF RFC 7405 syntax.
			Version -10 made the following changes:
			o Restricted the case of "mac", "ow", etc. any subtype to lower
			case. This required the adoption of RFC 7405 syntax in the ABNF.
			o Added a reserved "example" subtype to be used in examples.
			o Clarified global applicability, particularly in cases with local
			or manual assignment mechanisms.
			o Corrected byte/bit counts in for 1-Wire identifiers in
			Section 4.2.
			o Clarified that optional underscore-separated components come at
			the end of the DEV URN, not just "after the hexstring".
			o Changed the requirement to not use percent-encoding to a
			preference instead of a hard rule, based on the needs of SenML but
			not wishing to break rules of RFC 8141.
			o Added a description of tradeoffs involving using URNs instead of
			some more compact but more specific formats, in Section 1.
			o Several minor corrections to the names in the ABNF.
			o Added a reference for Base64 for clarity.
			o Made the history of the OS and OPS subtypes a part of the
			permanent text, rather than an editor's note.
			o Updated the 1-Wire reference URL.
			o Some editorial corrections.
			Version -09 of the WG draft took into account IANA, SECDIR, Gen-ART,
	and OPSDIR reviews. The following changes were made:		and OPSDIR reviews. The following changes were made:
	o Aligned the use of identifiers vs. identity terms.		o Aligned the use of identifiers vs. identity terms.
	o Added a security considerations subsection on validity of claimed		o Added a security considerations subsection on validity of claimed
	identifiers.		identifiers.
	o Focused on "care" in the RFC 7721 reference, rather than "care and		o Focused on "care" in the RFC 7721 reference, rather than "care and
	avoidance".		avoidance".
	o Renamed the "unreserved" ABNF terminal to avoid confusion with the		o Renamed the "unreserved" ABNF terminal to avoid confusion with the
	general URN ABN terminal with the same name.		general URN ABNF terminal with the same name.
	o Removed the mistakenly included text about MEID subtype.		o Removed the mistakenly included text about MEID subtype.
	o Clarified URN syntax differences and normalization rules wrt the		o Clarified URN syntax differences and normalization rules wrt the
	lack of percent-encoding in DEV URNs.		lack of percent-encoding in DEV URNs.
	o Required PEN numbers to start with non-zero digit in the ABNF and		o Required PEN numbers to start with non-zero digit in the ABNF and
	changed the associated language later in the draft.		changed the associated language later in the draft.
	o Text about case-insensitivity in RFC 5234 was clarified.		o Text about case-insensitivity in RFC 5234 was clarified.
	skipping to change at page 18, line 46		skipping to change at page 20, line 5
	Version -05 made a change to the delimiter for parameters within a		Version -05 made a change to the delimiter for parameters within a
	DEV URN. Given discussions on allowed character sets in SenML		DEV URN. Given discussions on allowed character sets in SenML
	[RFC8428], we would like to suggest that the "_" character be used		[RFC8428], we would like to suggest that the "_" character be used
	instead of ";", to avoid the need to translate DEV URNs in SenML-		instead of ";", to avoid the need to translate DEV URNs in SenML-
	formatted communications or files. However, this reverses the		formatted communications or files. However, this reverses the
	earlier decision to not use unreserved characters. This also means		earlier decision to not use unreserved characters. This also means
	that device IDs cannot use "_" characters, and have to employ other		that device IDs cannot use "_" characters, and have to employ other
	characters instead. Feedback on this decision is sought.		characters instead. Feedback on this decision is sought.
	Version -05 also introduced local or organisation-specific device		Version -05 also introduced local or organization-specific device
	identifiers. Organisations are identified by their PEN number		identifiers. Organizations are identified by their PEN number
	(although we considered FQDNs as a potential alternative. The		(although we considered FQDNs as a potential alternative. The
	authors belive an organisation-specific device identifier type will		authors belive an organization-specific device identifier type will
	make experiments and local use easier, but feedback on this point and		make experiments and local use easier, but feedback on this point and
	the choice of PEN numbers vs. other possible organisation identifiers		the choice of PEN numbers vs. other possible organization identifiers
	would be very welcome.		would be very welcome.
	Version -05 also added some discussion of privacy concerns around		Version -05 also added some discussion of privacy concerns around
	long-term stable identifiers.		long-term stable identifiers.
	Finally, version -05 clarified the situations when new allocations		Finally, version -05 clarified the situations when new allocations
	within the registry of possible device identifier subtypes is		within the registry of possible device identifier subtypes is
	appropriate.		appropriate.
	Version -04 is a refresh, as the need and interest for this		Version -04 is a refresh, as the need and interest for this
	specification has re-emerged. And the editing author has emerged		specification has re-emerged. And the editing author has emerged
	back to actual engineering from the depths of IETF administration.		back to actual engineering from the depths of IETF administration.
	Version -02 introduced several changes. The biggest change is that		Version -02 introduced several changes. The biggest change is that
	with the NI URNs [RFC6920], it was no longer necessary to define		with the NI URNs [RFC6920], it was no longer necessary to define
	cryptographic identifiers in this specification. Another change was		cryptographic identifiers in this specification. Another change was
	that we incorporated a more generic syntax for future extensions;		that we incorporated a more generic syntax for future extensions;
	non-hexstring identifiers can now also be supported, if some future		non-hexstring identifiers can now also be supported, if some future
	device identifiers for some reason would, for instance, use BASE64.		device identifiers for some reason would, for instance, use some kind
	As a part of this change, we also changed the component part		of encoding such as Base64 [RFC4648]. As a part of this change, we
	separator character from '-' to ';' so that the general format of the		also changed the component part separator character from '-' to ';'
	rest of the URN can employ the unreserved characters [RFC3986].		so that the general format of the rest of the URN can employ the
			unreserved characters [RFC3986].
	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,		Amanda Baber, Juha Hakala, Dale Worley, Brian Weis, John Klensin,
	and Ahmad Muhanna for feedback and interesting discussions in this		Dave Thaler, Russ Housley, Dan Romascanu, and Ahmad Muhanna for
	problem space. We would also like to note prior documents that		feedback and interesting discussions in this problem space. We would
	focused on specific device identifiers, such as [RFC7254] or		also like to note prior documents that focused on specific device
	[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
	San Jose, CA 95134		San Jose, CA 95134
	USA		USA
	Phone: +1 408 421-9990		Phone: +1 408 421-9990
	Email: fluffy@cisco.com		Email: fluffy@cisco.com
	Zach Shelby		Zach Shelby
End of changes. 69 change blocks.
	138 lines changed or deleted		213 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/