draft-ietf-core-dev-urn-02.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: Informational C. Jennings
	Expires: January 3, 2019 Cisco		Expires: April 25, 2019 Cisco
	Z. Shelby		Z. Shelby
	ARM		ARM
	July 2, 2018		October 22, 2018
	Uniform Resource Names for Device Identifiers		Uniform Resource Names for Device Identifiers
	draft-ietf-core-dev-urn-02		draft-ietf-core-dev-urn-03
	Abstract		Abstract
	This memo describes a new Uniform Resource Name (URN) namespace for		This memo describes a new Uniform Resource Name (URN) namespace for
	hardware device identifiers. A general representation of device		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 January 3, 2019.		This Internet-Draft will expire on April 25, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 3		3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6
	3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6		3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6
	3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6		3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6
	3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6		3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
	3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 6		3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 6
	3.8. Additional Information . . . . . . . . . . . . . . . . . 6		3.8. Additional Information . . . . . . . . . . . . . . . . . 7
	3.9. Revision Information . . . . . . . . . . . . . . . . . . 6		3.9. Revision Information . . . . . . . . . . . . . . . . . . 7
	4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7		4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7
	4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7		4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7		4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7
	4.3. Organization-Defined Identifiers . . . . . . . . . . . . 7		4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8
	4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8		4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8
	4.5. Organization Product and Serial Numbers . . . . . . . . . 8		4.5. Organization Product and Serial Numbers . . . . . . . . . 8
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9		6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	8.1. Normative References . . . . . . . . . . . . . . . . . . 9		8.1. Normative References . . . . . . . . . . . . . . . . . . 10
	8.2. Informative References . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 11
	Appendix A. Changes from Previous Version . . . . . . . . . . . 12		Appendix A. Changes from Previous Version . . . . . . . . . . . 13
	Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14		Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	This memo describes a new Uniform Resource Name (URN) [RFC8141]		This memo describes a new Uniform Resource Name (URN) [RFC8141]
	[RFC3406] namespace for hardware device identifiers. A general		[RFC3406] namespace for hardware device identifiers. A general
	representation of device identity can be useful in many applications,		representation of device identity can be useful in many applications,
	such as in sensor data streams and storage, or equipment inventories		such as in sensor data streams and storage, or equipment inventories
	[RFC7252], [I-D.ietf-core-senml]. A URN-based representation can be		[RFC7252], [RFC8428]. A URN-based representation can be easily
	easily passed along in any application that needs the information, as		passed along in any application that needs the information, as it
	it fits in protocols mechanisms that are designed to carry URNs		fits in protocols mechanisms that are designed to carry URNs
	[RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily		[RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily
	carried and stored in formats such as XML [W3C.REC-xml-19980210] or		carried and stored in formats such as XML [W3C.REC-xml-19980210] or
	JSON [I-D.ietf-core-senml] [RFC4627]. Using URNs in these formats is		JSON [RFC8428] [RFC4627]. Using URNs in these formats is often
	often preferable as they are universally recognized, self-describing,		preferable as they are universally recognized, self-describing, and
	and therefore avoid the need for agreeing to interpret an octet		therefore avoid the need for agreeing to interpret an octet string as
	string as a specific form of a MAC address, for instance.		a specific form of a MAC address, for instance.
	This memo defines identity URN types for situations where no such		This memo defines identity URN types for situations where no such
	convenient type already exist. For instance, [RFC6920] defines		convenient type already exist. 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 [I-D.atarius-dispatch-meid-urn] defines Mobile		cellular systems, and [I-D.atarius-dispatch-meid-urn] defines Mobile
	Equipment Identity (MEID) identifiers for use with 3GPP2 cellular		Equipment Identity (MEID) identifiers for use with 3GPP2 cellular
	systems. Those URN types should be employed when such identities are		systems. Those URN types should be employed when such identities are
	transported; this memo does not redefine these identifiers in any		transported; this memo does not redefine these identifiers in any
	way.		way.
	skipping to change at page 4, line 50		skipping to change at page 5, line 10
	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 expeced to be a		involving IMEI or UUID identifiers. DEV URNs are expeced 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		orgbody = "org:" number "-" identifier
	osbody = "os:" number "-" serial		osbody = "os:" number "-" serial
	opsbody = "ops:" number "-" product "-" serial		opsbody = "ops:" number "-" product "-" serial
	otherbody = subtype ":" identifier		otherbody = subtype ":" identifier
	subtype = ALPHA *(DIGIT / ALPHA)		subtype = ALPHA *(DIGIT / ALPHA)
	identifier = 1*unreservednout		identifier = 1*unreservednout
	product = identifier		product = identifier
	serial = identifier		serial = identifier
	unreservednout = ALPHA / DIGIT / "_" / pct-encoding		unreservednout = ALPHA / DIGIT / "_"
	componentpart = [ "_" component [ componentpart ]]		componentpart = [ "_" component [ componentpart ]]
	component = *1(DIGIT / ALPHA)		component = *1(DIGIT / ALPHA)
	hexstring = hexbyte /		hexstring = hexbyte /
	hexbyte hexstring		hexbyte hexstring
	hexbyte = hexdigit hexdigit		hexbyte = hexdigit hexdigit
	hexdigit = DIGIT / hexletter		hexdigit = DIGIT / hexletter
	hexletter = "a" / "b" / "c" / "d" / "e" / "f"		hexletter = "a" / "b" / "c" / "d" / "e" / "f"
	number = *1DIGIT		number = *1DIGIT
	The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA		The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA
	rules defined in [RFC5234], which are not repeated here. The rule		rules defined in [RFC5234], which are not repeated here. The rule
	for pct-encoding is defined in Section 2.1 of [RFC3986].		for pct-encoding is defined in Section 2.1 of [RFC3986].
	The device identity namespace includes three subtypes (see Section 4,		The device identity namespace includes three subtypes (see Section 4,
	and more may be defined in the future as specified in Section 7.		and more may be defined in the future as specified in Section 7.
	The optional components following the hexstring are strings depicting		The optional components following the hexstring are strings depicting
	individual aspects of a device. The specific strings and their		individual aspects of a device. The specific strings and their
	semantics are up to the designers of the device, but could be used to		semantics are up to the designers of the device, but could be used to
	refer to specific interfaces or functions within the device.		refer to specific interfaces or functions within the device.
	There are no special character encoding rules or considerations for		There are no special character encoding rules or considerations for
	comforming with the URN syntax, beyond those applicable for URNs in		comforming 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 [I-D.ietf-core-senml]).		inside JSON [RFC8259] or SenML [RFC8428]).
	The lexical equivalence of the DEV URNs is defined as an exact and		The lexical equivalence of the DEV URNs is defined as an exact and
	case sensitive string match. Note that the two subtypes defined in		case sensitive string match. Note that the two subtypes defined in
	this document use only lower case letters, however. Future types		this document use only lower case letters, however. Future types
	might use identifiers that require other encodings that require a		might use identifiers that require other encodings that require a
	more full-blown character set (such as BASE64), however.		more full-blown character set (such as BASE64), however.
	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
	skipping to change at page 8, line 4		skipping to change at page 8, line 11
	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 organisation
	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. Organisations are identified by their Private		organisation. Organisations are identified by their Private
	Enterprise Number (PEN) [RFC2578].		Enterprise Number (PEN) [RFC2578].
	4.4. Organization Serial Numbers		4.4. Organization Serial Numbers
	The DEV URN "os" subtype has originally been defined in the LwM2M		The "os" subtype specifies an organization and a serial number.
	standard, but has been incorporated here to collect all syntax		Organizations are identified by their PEN.
	associated with DEV URNs in one place. The "os" subtype specifies an
	organization and a serial number. Organizations are identified by		Note: The DEV URN "os" subtype has originally been defined in the
	their PEN.		LwM2M standard, but has been incorporated here to collect all
			syntax associated with DEV URNs in one place. At the same time,
			the syntax of this subtype was changed to avoid the possibility of
			characters that are not allowed in SenML Name field (see [RFC8428]
			Section 4.5.1).
	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.		are identified by their PEN.
			Note: As with the "os" subtype, the "ops" subtype has originally
			been defined in the LwM2M standard, and its format has been
			slightly changed.
	5. Examples		5. Examples
	The following three examples provide examples of MAC-based, 1-Wire,		The following three examples provide examples of MAC-based, 1-Wire,
	and Cryptographic identifiers:		and Cryptographic identifiers:
	urn:dev:mac:0024befffe804ff1 # The MAC address of		urn:dev:mac:0024befffe804ff1 # The MAC address of
	# Jari's laptop		# Jari's laptop
	urn:dev:ow:10e2073a01080063 # The 1-Wire temperature		urn:dev:ow:10e2073a01080063 # The 1-Wire temperature
	# sensor in Jari's		# sensor in Jari's
	skipping to change at page 10, line 6		skipping to change at page 10, line 28
	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
	preferrable, however, that long-term usage of a broadly employed		preferrable, 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 organisation 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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	rfc2119>.		editor.org/info/rfc2119>.
	[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names		[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
	(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,		(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
	<https://www.rfc-editor.org/info/rfc8141>.		<https://www.rfc-editor.org/info/rfc8141>.
	[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.		[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
	Schoenwaelder, Ed., "Structure of Management Information		Schoenwaelder, Ed., "Structure of Management Information
	Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/		Version 2 (SMIv2)", STD 58, RFC 2578,
	RFC2578, April 1999, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2578, April 1999, <https://www.rfc-
	rfc2578>.		editor.org/info/rfc2578>.
	[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,		[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
	"Uniform Resource Names (URN) Namespace Definition		"Uniform Resource Names (URN) Namespace Definition
	Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,		Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
	<https://www.rfc-editor.org/info/rfc3406>.		<https://www.rfc-editor.org/info/rfc3406>.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66, RFC		Resource Identifier (URI): Generic Syntax", STD 66,
	3986, DOI 10.17487/RFC3986, January 2005, <https://www		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226, DOI		IANA Considerations Section in RFCs", RFC 5226,
	10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/		DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
	info/rfc5226>.		editor.org/info/rfc5226>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/		Specifications: ABNF", STD 68, RFC 5234,
	RFC5234, January 2008, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
	rfc5234>.		editor.org/info/rfc5234>.
	[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,
	<http://standards.ieee.org/db/oui/tutorials/EUI64.html>.		<http://standards.ieee.org/db/oui/tutorials/EUI64.html>.
	[OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use",		[OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use",
	MAXIM http://www.maxim-ic.com/app-notes/index.mvp/id/1796,		MAXIM
	June 2008,		http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June
			2008,
	<http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.		<http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.
	8.2. Informative References		8.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/		Transfer Protocol -- HTTP/1.1", RFC 2616,
	RFC2616, June 1999, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC2616, June 1999, <https://www.rfc-
	rfc2616>.		editor.org/info/rfc2616>.
	[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>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487
	/RFC3971, March 2005, <https://www.rfc-editor.org/info/
	rfc3971>.
	[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
	RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www
	.rfc-editor.org/info/rfc3972>.
	[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, DOI		Unique IDentifier (UUID) URN Namespace", RFC 4122,
	10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/		DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
	info/rfc4122>.		editor.org/info/rfc4122>.
	[RFC4627] Crockford, D., "The application/json Media Type for		[RFC4627] Crockford, D., "The application/json Media Type for
	JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487		JavaScript Object Notation (JSON)", RFC 4627,
	/RFC4627, July 2006, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC4627, July 2006, <https://www.rfc-
	rfc4627>.		editor.org/info/rfc4627>.
	[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
	Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
	2009, <https://www.rfc-editor.org/info/rfc5612>.
	[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy		[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
	Considerations for IPv6 Address Generation Mechanisms",		Considerations for IPv6 Address Generation Mechanisms",
	RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www		RFC 7721, DOI 10.17487/RFC7721, March 2016,
	.rfc-editor.org/info/rfc7721>.		<https://www.rfc-editor.org/info/rfc7721>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259, DOI 10.17487/		Interchange Format", STD 90, RFC 8259,
	RFC8259, December 2017, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC8259, December 2017, <https://www.rfc-
	rfc8259>.		editor.org/info/rfc8259>.
	[W3C.REC-xml-19980210]		[W3C.REC-xml-19980210]
	Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0		Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0
	Recommendation", World Wide Web Consortium FirstEdition		Recommendation", World Wide Web Consortium FirstEdition
	REC-xml-19980210, February 1998,		REC-xml-19980210, February 1998,
	<http://www.w3.org/TR/1998/REC-xml-19980210>.		<http://www.w3.org/TR/1998/REC-xml-19980210>.
	[OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage,		[OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage,
	2018, <http://standards.ieee.org/develop/regauth/oui/>.		2018, <http://standards.ieee.org/develop/regauth/oui/>.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, DOI 10.17487/		Application Protocol (CoAP)", RFC 7252,
	RFC7252, June 2014, <https://www.rfc-editor.org/info/		DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
	rfc7252>.		editor.org/info/rfc7252>.
	[I-D.ietf-core-senml]		[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
	Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.		Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
	Bormann, "Media Types for Sensor Measurement Lists		DOI 10.17487/RFC8428, August 2018, <https://www.rfc-
	(SenML)", draft-ietf-core-senml-13 (work in progress),		editor.org/info/rfc8428>.
	March 2018.
	[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,		[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
	Keranen, A., and P. Hallam-Baker, "Naming Things with		Keranen, A., and P. Hallam-Baker, "Naming Things with
	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, <https:		(IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
	//www.rfc-editor.org/info/rfc7254>.		<https://www.rfc-editor.org/info/rfc7254>.
	[I-D.atarius-dispatch-meid-urn]		[I-D.atarius-dispatch-meid-urn]
	Atarius, R., "A Uniform Resource Name Namespace for the		Atarius, R., "A Uniform Resource Name Namespace for the
	Device Identity and the Mobile Equipment Identity (MEID)",		Device Identity and the Mobile Equipment Identity (MEID)",
	draft-atarius-dispatch-meid-urn-15 (work in progress),		draft-atarius-dispatch-meid-urn-18 (work in progress),
	January 2018.		June 2018.
	Appendix A. Changes from Previous Version		Appendix A. Changes from Previous Version
			Version -03 of the WG draft removed some unnecessary references,
			updated some other references, removed pct-encoding to ensure the DEV
			URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the
			original source of the "os" and "ops" subtypes.
	Version -02 of the WG draft folded in the "ops" and "os" branches of		Version -02 of the WG draft folded in the "ops" and "os" branches of
	the dev:urn syntax from LwM2M, as they seemed to match well what		the dev:urn syntax from LwM2M, as they seemed to match well what
	already existed in this memo under the "org" branch. However, as a		already existed in this memo under the "org" branch. However, as a
	part of this three changes were incorporated:		part of this three changes were incorporated:
	o The syntax for the "org:" changes to use "-" rather than ":"		o The syntax for the "org:" changes to use "-" rather than ":"
	between the OUI and the rest of the URN.		between the OUI and the rest of the URN.
	o The organizations for the "ops" and "os" branches have been		o The organizations for the "ops" and "os" branches have been
	changed to use PEN numbers rather than OUI numbers [OUI]. The		changed to use PEN numbers rather than OUI numbers [OUI]. The
	skipping to change at page 13, line 25		skipping to change at page 13, line 44
	probably be beneficial. Comments on this topic are appreciated.		probably be beneficial. Comments on this topic are appreciated.
	Version -01 of the WG draft converted the draft to use the new URN		Version -01 of the WG draft converted the draft to use the new URN
	registration template from [RFC8141].		registration template from [RFC8141].
	Version -00 of the WG draft renamed the file name and fixed the ABNF		Version -00 of the WG draft renamed the file name and fixed the ABNF
	to correctly use "org:" rather than "dn:".		to correctly use "org:" rather than "dn:".
	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
	[I-D.ietf-core-senml], we would like to suggest that the "_"		[RFC8428], we would like to suggest that the "_" character be used
	character be used instead of ";", to avoid the need to translate DEV		instead of ";", to avoid the need to translate DEV URNs in SenML-
	URNs in SenML-formatted communications or files. However, this		formatted communications or files. However, this reverses the
	reverses the earlier decision to not use unreserved characters. This		earlier decision to not use unreserved characters. This also means
	also means that device IDs cannot use "_" characters, and have to		that device IDs cannot use "_" characters, and have to employ other
	employ other characters instead. Feedback on this decision is		characters instead. Feedback on this decision is sought.
	sought.
	Version -05 also introduced local or organisation-specific device		Version -05 also introduced local or organisation-specific device
	identifiers. Organisations are identified by their PEN number		identifiers. Organisations 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 organisation-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 organisation 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
	skipping to change at page 14, line 19		skipping to change at page 14, line 35
	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 BASE64.
	As a part of this change, we also changed the component part		As a part of this change, we also changed the component part
	separator character from '-' to ';' so that the general format of the		separator character from '-' to ';' so that the general format of the
	rest of the URN can employ the unreserved characters [RFC3986].		rest of the URN can employ the unreserved characters [RFC3986].
	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,
	and Ahmad Muhanna for interesting discussions in this problem space.		Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, and Ahmad Muhanna
	We would also like to note prior documents that focused on specific		for interesting discussions in this problem space. We would also
	device identifiers, such as [RFC7254] or		like to note prior documents that focused on specific device
	[I-D.atarius-dispatch-meid-urn].		identifiers, such as [RFC7254] or [I-D.atarius-dispatch-meid-urn].
	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. 37 change blocks.
	117 lines changed or deleted		116 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/