draft-ietf-core-dev-urn-04.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: June 15, 2020 Cisco Expires: December 26, 2020 Cisco
Z. Shelby Z. Shelby
ARM ARM
December 13, 2019 June 24, 2020
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-04 draft-ietf-core-dev-urn-05
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 June 15, 2020. This Internet-Draft will expire on December 26, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 . . . . . . . . . . . . . . . . . 7 3.8. Additional Information . . . . . . . . . . . . . . . . . 7
3.9. Revision Information . . . . . . . . . . . . . . . . . . 7 3.9. Revision Information . . . . . . . . . . . . . . . . . . 7
4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7
4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7
4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8 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 . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security and Privacy Considerations . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from Previous Version . . . . . . . . . . . 14 Appendix A. Changes from Previous Version . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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 namespace for hardware device identifiers. A general representation
representation of device identity can be useful in many applications, of device identity can be useful in many applications, such as in
such as in sensor data streams and storage, or equipment inventories sensor data streams and storage, or equipment inventories [RFC7252],
[RFC7252], [RFC8428]. A URN-based representation can be easily [RFC8428]. A URN-based representation can be easily passed along in
passed along in any application that needs the information, as it any application that needs the information, as it fits in protocols
fits in protocols mechanisms that are designed to carry URNs mechanisms that are designed to carry URNs [RFC7230], [RFC7540],
[RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily [RFC3261], [RFC7252]. Finally, URNs can also be easily carried and
carried and stored in formats such as XML [W3C.REC-xml-19980210] or stored in formats such as XML [W3C.REC-xml-19980210] or JSON
JSON [RFC8428] [RFC4627]. Using URNs in these formats is often [RFC8428] [RFC4627]. Using URNs in these formats is often preferable
preferable as they are universally recognized, self-describing, and as they are universally recognized, self-describing, and therefore
therefore avoid the need for agreeing to interpret an octet string as avoid the need for agreeing to interpret an octet string as a
a specific form of a MAC address, for instance. 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 [RFC8464] defines Mobile Equipment Identity
Equipment Identity (MEID) identifiers for use with 3GPP2 cellular (MEID) identifiers for use with 3GPP2 cellular systems. Those URN
systems. Those URN types should be employed when such identities are types should be employed when such identities are transported; this
transported; this memo does not redefine these identifiers in any memo does not redefine these identifiers in any way.
way.
Universally Unique IDentifier (UUID) URNs [RFC4122] are another Universally Unique IDentifier (UUID) URNs [RFC4122] are another
alternative way for representing device identifiers, and already alternative way for representing device identifiers, and already
support MAC addresses as one of type of an identifier. However, support MAC addresses as one of type of an identifier. However,
UUIDs can be inconvenient in environments where it is important that UUIDs can be inconvenient in environments where it is important that
the identifiers are as simple as possible and where additional the identifiers are as simple as possible and where additional
requirements on stable storage, real-time clocks, and identifier requirements on stable storage, real-time clocks, and identifier
length can be prohibitive. UUID-based identifiers are recommended length can be prohibitive. UUID-based identifiers are recommended
for all general purpose uses when MAC addresses are available as for all general purpose uses when MAC addresses are available as
identifiers. The device URN defined in this memo is recommended for identifiers. The device URN defined in this memo is recommended for
skipping to change at page 3, line 45 skipping to change at page 3, line 44
The rest of this memo is organized as follows. Section 3 defines the The rest of this memo is organized as follows. Section 3 defines the
"DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, "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 considerations of gives examples. Section 6 discusses the security considerations of
the new URN type. Finally, Section 7 specifies the IANA registration the new URN type. Finally, Section 7 specifies the IANA registration
for the new URN type and sets requirements for subtype allocations for the new URN type and sets requirements for subtype allocations
within this type. within this type.
2. Requirements language 2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. DEV URN Definition 3. DEV URN Definition
Namespace Identifier: "dev" requested Namespace Identifier: "dev" requested
Version: 1 Version: 1
Date: 2018-03-19 Date: 2020-06-24
Registration Information: This is the first registration of this
namespace, 2018-03-19.
Registrant: IETF and the CORE working group. Should the working Registrant: IETF and the CORE working group. Should the working
group cease to exist, discussion should be directed to the general group cease to exist, discussion should be directed to the general
IETF discussion forums or the IESG. IETF discussion forums or the IESG.
3.1. Purpose 3.1. Purpose
Purpose: The DEV URNs identify devices with device-specific Purpose: The DEV URNs identify devices with device-specific
identifiers such as network card hardware addresses. DEV URN is identifiers such as network card hardware addresses. DEV URN is
global in scope. global in scope.
skipping to change at page 4, line 44 skipping to change at page 4, line 41
While it is possible to implement resolution systems for specific While it is possible to implement resolution systems for specific
applications or network locations, DEV URNs are typically not used in applications or network locations, DEV URNs are typically not used in
a way that requires resolution beyond direct observation of the a way that requires resolution beyond direct observation of the
relevant identity fields in local link communication. However, it is relevant identity fields in local link communication. However, it is
often useful to be able to pass device identity information in often useful to be able to pass device identity information in
generic URN fields in databases or protocol fields, which makes the generic URN fields in databases or protocol fields, which makes the
use of URNs for this purpose convenient. use of URNs for this purpose convenient.
The DEV URN name space complements existing name spaces such as those The DEV URN name space complements existing name spaces such as those
involving IMEI or UUID identifiers. DEV URNs are expeced to be a involving IMEI or UUID identifiers. DEV URNs are expected to be a
part of the IETF-provided basic URN types, covering identifiers that part of the IETF-provided basic URN types, covering identifiers that
have previously not been possible to use in URNs. have previously not been possible to use in URNs.
3.2. Syntax 3.2. Syntax
Syntax: The identifier is expressed in ASCII characters and has a Syntax: The identifier is expressed in ASCII characters and has a
hierarchical structure as follows: hierarchical structure as follows:
devurn = "urn:dev:" body componentpart devurn = "urn:dev:" body componentpart
body = macbody / owbody / orgbody / osbody / opsbody / otherbody body = macbody / owbody / orgbody / osbody / opsbody / otherbody
skipping to change at page 5, line 49 skipping to change at page 5, line 49
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
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 [RFC8428]). 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 subtypes defined in this
this document use only lower case letters, however. Future types document do not require the specific case, 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). For equivalance
checks, it is RECOMMENDED that lower case letters are used throughout
by implementations unless there is a reason otherwise.
DEV URNs do not use r-, q-, or f-components. DEV URNs do not use r-, q-, or f-components.
Specific subtypes of DEV URNs may be validated through mechanisms Specific subtypes of DEV URNs may be validated through mechanisms
discussed in Section 4. discussed in Section 4.
Finally, the string representation of the device identity URN and of Finally, the string representation of the device identity URN and of
the MEID sub namespace is fully compatible with the URN syntax. the MEID sub namespace is fully compatible with the URN syntax.
3.3. Assignment 3.3. Assignment
skipping to change at page 6, line 31 skipping to change at page 6, line 33
This URN type SHOULD only be used for persistent identifiers, such as This URN type SHOULD only be used for persistent identifiers, such as
hardware-based identifiers or cryptographic identifiers based on keys hardware-based identifiers or cryptographic identifiers based on keys
intended for long-term usage. intended for long-term usage.
3.4. Security and Privacy 3.4. Security and Privacy
Security and Privacy: As discussed in Section 6, care must be taken Security and Privacy: As discussed in Section 6, care must be taken
to use device identifier-based identifiers due to their nature as a to use device identifier-based identifiers due to their nature as a
long-term identifier that is often not changeable. Leakage of these long-term identifier that is often not changeable. Leakage of these
identifiers outside systems where their use is justfied should be identifiers outside systems where their use is justified should be
controlled. controlled.
3.5. Interoperability 3.5. Interoperability
Interoperability: There are no specific interoperability concerns. Interoperability: There are no specific interoperability concerns.
3.6. Resolution 3.6. Resolution
Resolution: The device identities are not expected to be globally Resolution: The device identities are not expected to be globally
resolvable. No identity resolution system is expected. Systems may resolvable. No identity resolution system is expected. Systems may
skipping to change at page 8, line 23 skipping to change at page 8, line 23
can also be used to represent vendor-specific or experimental can also be used to represent vendor-specific or experimental
identifiers or identifiers designed for use within the context of an identifiers or identifiers designed for use within the context of an
organisation. organisation.
Organisations are identified by their Private Enterprise Number (PEN) Organisations are identified by their Private Enterprise Number (PEN)
[RFC2578]. These numbers can be obtained from IANA. Current PEN [RFC2578]. These numbers can be obtained from IANA. Current PEN
assignments can be viewed at https://www.iana.org/assignments/ assignments can be viewed at https://www.iana.org/assignments/
enterprise-numbers/enterprise-numbers and new assignemnts requested enterprise-numbers/enterprise-numbers and new assignemnts requested
at https://pen.iana.org/pen/PenApplication.page. at https://pen.iana.org/pen/PenApplication.page.
When included in an "org" DEV URN, the number MUST NOT be padded with
extra leading zeroes.
4.4. Organization Serial Numbers 4.4. Organization Serial Numbers
The "os" subtype specifies an organization and a serial number. The "os" subtype specifies an organization and a serial number.
Organizations are identified by their PEN. As with the organization- Organizations are identified by their PEN. As with the organization-
defined identifiers (Section 4.3), PEN number assignments are defined identifiers (Section 4.3), PEN number assignments are
maintained by IANA, and assignments for new organizations can be made maintained by IANA, and assignments for new organizations can be made
easily. easily.
Editor's Note (Please remove before publication): The DEV URN "os" Editor's Note (Please remove before publication): The DEV URN "os"
subtype has originally been defined in the LwM2M standard, but has subtype has originally been defined in the LwM2M standard, but has
been incorporated here to collect all syntax associated with DEV been incorporated here to collect all syntax associated with DEV
URNs in one place. At the same time, the syntax of this subtype URNs in one place. At the same time, the syntax of this subtype
was changed to avoid the possibility of characters that are not was changed to avoid the possibility of characters that are not
allowed in SenML Name field (see [RFC8428] Section 4.5.1). allowed in SenML Name field (see [RFC8428] Section 4.5.1).
When included in an "os" DEV URN, the PEN number MUST NOT be
padded with extra leading zeroes. Organizations are also
encouraged to select serial number formats that avoid possibility
for ambiquity, 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 thy are allocated. specification does not specify how they are allocated.
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.
skipping to change at page 9, line 19 skipping to change at page 9, line 27
LwM2M standard, and its format has been slightly changed. LwM2M standard, and its format has been slightly changed.
Organization product and serial number DEV URNs consist of the PEN Organization product and serial number DEV URNs consist of the PEN
number, product class, and the serial number. As with other DEV number, product class, and the serial number. As with other DEV
URNs, for carrying additional information and extensibility, optional URNs, for carrying additional information and extensibility, optional
colon-separated identifiers and underscore-separated components may colon-separated identifiers and underscore-separated components may
also be included. Both the product class and serial numbers also be included. Both the product class and serial numbers
themselves are defined by the organization, and this specification themselves are defined by the organization, and this specification
does not specify how thy are allocated. does not specify how thy are allocated.
When included in an "ops" DEV URN, the PEN number MUST NOT be padded
with extra leading zeroes. Organizations are also encouraged to
select product and serial number formats that avoid possibility for
ambiquity.
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:0024beffff804ff1 # The MAC address of urn:dev:mac:0024beffff804ff1 # The MAC-48 address of
# Jari's laptop, for # 0024be804ff1, converted
# the MAC address # to EUI-64 format
# 0024be804ff1
urn:dev:mac:0024befffe804ff1 # The EUI-48 address of
# 0024be804ff1, converted
# to EUI-64 format
urn:dev:mac:acde48234567019f # The EUI-64 address of
# acde48234567019f
urn:dev:ow:10e2073a01080063 # The 1-Wire temperature urn:dev:ow:10e2073a01080063 # The 1-Wire temperature
# sensor in Jari's # sensor in Jari's
# kitchen # kitchen
urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's
# humidity part # humidity part
urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
# temperature part # temperature part
skipping to change at page 10, line 40 skipping to change at page 10, line 46
# dashes in it # dashes in it
urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial
# number 5002 in the # number 5002 in the
# RFC 5612 example # RFC 5612 example
# organisation # organisation
urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined
# subtype # subtype
6. Security Considerations 6. Security and Privacy 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 by the user. An implementation of the DEV URN MUST NOT tampered by the user. An implementation of the DEV URN MUST NOT
change these properties from what they were intended. In particular, change these properties from what they were intended. In particular,
a device identifier that is intended to be immutable should not a device identifier that is intended to be immutable should not
become mutable as a part of implementing the DEV URN type. More become mutable as a part of implementing the DEV URN type. More
generally, nothing in this memo should be construed to override what generally, nothing in this memo should be construed to override what
the relevant device specifications have already said about the the relevant device specifications have already said about the
identifiers. identifiers.
skipping to change at page 11, line 16 skipping to change at page 11, line 20
the device. For instance, on Ethernet network, the MAC address of a the device. For instance, on Ethernet network, the MAC address of a
device is visible to all other devices. device is visible to all other devices.
The URNs generated according to the rules defined in this document The URNs generated according to the rules defined in this document
result in long-term stable unique identifiers for the devices. Such result in long-term stable unique identifiers for the devices. Such
identifiers may have privacy and security implications because they identifiers may have privacy and security implications because they
may enable correlating information about a specific device over a may enable correlating information about a specific device over a
long period of time, location tracking, and device specific long period of time, location tracking, and device specific
vulnerability exploitation [RFC7721]. Also, usually there is no easy vulnerability exploitation [RFC7721]. Also, usually there is no easy
way to change the identifier. Therefore these identifiers need to be way to change the identifier. Therefore these identifiers need to be
used with care and especially care should be taken avoid leaking them used with care and especially care should be taken to avoid leaking
outside of the system that is intended to use the identifiers. them outside of the system that is intended to use the identifiers.
7. IANA Considerations 7. IANA Considerations
This document requests the registration of a new URN namespace for This document requests the registration of a new URN namespace for
"DEV", as described in Section 3. "DEV", as described in Section 3.
Additional subtypes for DEV URNs can be defined through Specification Additional subtypes for DEV URNs can be defined through Specification
Required or IESG Approval [RFC5226]. Required or IESG Approval [RFC8126].
Such allocations are appropriate when there is a new namespace of Such allocations are appropriate when there is a new namespace of
some type of device identifiers, defined in stable fashion and with a some type of device identifiers, defined in stable fashion and with a
publicly available specification that can be pointed to. publicly available specification that can be pointed to.
Note that the organisation (Section 4.3) device identifiers can also Note that the organisation (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
preferrable, 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 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, 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>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<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, Version 2 (SMIv2)", STD 58, RFC 2578,
DOI 10.17487/RFC2578, April 1999, <https://www.rfc- DOI 10.17487/RFC2578, April 1999, <https://www.rfc-
editor.org/info/rfc2578>. editor.org/info/rfc2578>.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
<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, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
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, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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] IEEE, "Overview of 1-Wire(R) Technology and Its Use",
MAXIM MAXIM
http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June
2008, 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.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999, <https://www.rfc-
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>.
[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>.
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, <https://www.rfc- DOI 10.17487/RFC4627, July 2006, <https://www.rfc-
editor.org/info/rfc4627>. editor.org/info/rfc4627>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
editor.org/info/rfc7540>.
[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, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.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, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, <https://www.rfc- DOI 10.17487/RFC8259, December 2017, <https://www.rfc-
editor.org/info/rfc8259>. editor.org/info/rfc8259>.
skipping to change at page 14, line 17 skipping to change at page 14, line 17
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>.
[I-D.atarius-dispatch-meid-urn] [RFC8464] Atarius, R., "A URN Namespace for Device Identity and
Atarius, R., "A Uniform Resource Name Namespace for the Mobile Equipment Identity (MEID)", RFC 8464,
Device Identity and the Mobile Equipment Identity (MEID)", DOI 10.17487/RFC8464, September 2018, <https://www.rfc-
draft-atarius-dispatch-meid-urn-18 (work in progress), editor.org/info/rfc8464>.
June 2018.
Appendix A. Changes from Previous Version Appendix A. Changes from Previous Version
Version -05 of the WG draft made some updates based on WGLC input:
examples for MAC-48 and EUI-48, clarification with regards to leading
zeroes, new recommendation with the use of lower-case letters to
avoid comparison problems, small update of the RFC 8141 template
usage, reference updates, and editorial corrections.
Version -04 of the WG draft cleaned up the ABNF: Version -04 of the WG draft cleaned up the ABNF:
o Parts of the ANBF now allow for use cases for the component part o Parts of the ANBF now allow for use cases for the component part
that were not previously covered: the syntax now allows the that were not previously covered: the syntax now allows the
character "." to appear, and serial numbers can have dashes in character "." to appear, and serial numbers can have dashes in
them. them.
o The syntax was also extended to allow for extensibility by adding o The syntax was also extended to allow for extensibility by adding
additional ":" separated parts for the org, op, ops, and other additional ":" separated parts for the org, op, ops, and other
subtypes. subtypes.
skipping to change at page 16, line 33 skipping to change at page 16, line 36
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].
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, and Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim
Ahmad Muhanna for interesting discussions in this problem space. We Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, and Ahmad
would also like to note prior documents that focused on specific Muhanna for interesting discussions in this problem space. We would
device identifiers, such as [RFC7254] or also like to note prior documents that focused on specific device
[I-D.atarius-dispatch-meid-urn]. 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
 End of changes. 33 change blocks. 
76 lines changed or deleted 103 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/