rfc9039.original   rfc9039.txt 
Network Working Group J. Arkko Internet Engineering Task Force (IETF) J. Arkko
Internet-Draft Ericsson Request for Comments: 9039 Ericsson
Intended status: Standards Track C. Jennings Category: Standards Track C. Jennings
Expires: August 27, 2021 Cisco ISSN: 2070-1721 Cisco
Z. Shelby Z. Shelby
ARM Edge Impulse
February 23, 2021 June 2021
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
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 in equipment inventories. A URN-based
representation can be passed along in applications that need the representation can be passed along in applications that need the
information. information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on August 27, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9039.
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 (https://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. Requirements language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4 3. DEV URN Definition
3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Purpose
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Syntax
3.2.1. Character Case and URN-Equivalence . . . . . . . . . 6 3.2.1. Character Case and URN-Equivalence
3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Assignment
3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 7 3.4. Security and Privacy
3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 7 3.5. Interoperability
3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 7 3.6. Resolution
3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Documentation
3.8. Additional Information . . . . . . . . . . . . . . . . . 8 3.8. Additional Information
3.9. Revision Information . . . . . . . . . . . . . . . . . . 8 3.9. Revision Information
4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 8 4. DEV URN Subtypes
4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 8 4.1. MAC Addresses
4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8 4.2. 1-Wire Device Identifiers
4.3. Organization-Defined Identifiers . . . . . . . . . . . . 9 4.3. Organization-Defined Identifiers
4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9 4.4. Organization Serial Numbers
4.5. Organization Product and Serial Numbers . . . . . . . . . 10 4.5. Organization Product and Serial Numbers
4.6. Future Subtypes . . . . . . . . . . . . . . . . . . . . . 10 4.6. Future Subtypes
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Examples
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations
6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Privacy
6.2. Validity . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Validity
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 14 8.2. Informative References
Appendix A. Changes from Previous Versions . . . . . . . . . . . 16 Acknowledgments
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 21 Authors' Addresses
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 or in equipment inventories [RFC7252]
[RFC7252], [I-D.ietf-core-resource-directory]. [RFC8428] [CoRE-RD].
A URN-based representation can be passed along in applications that A URN-based representation can be passed along in applications that
need the information. It fits particularly well for protocols need the information. It fits particularly well for protocols
mechanisms that are designed to carry URNs [RFC7230], [RFC7540], mechanisms that are designed to carry URNs [RFC7230] [RFC7540]
[RFC3261], [RFC7252]. Finally, URNs can also be easily carried and [RFC3261] [RFC7252]. Finally, URNs can also be easily carried and
stored in formats such as XML [W3C.REC-xml-19980210], JSON [RFC8259] stored in formats such as XML [W3C.REC-xml-19980210], JSON [RFC8259],
or SenML [RFC8428]. Using URNs in these formats is often preferable or SenML [RFC8428]. Using URNs in these formats is often preferable
as they are universally recognized and self-describing, and therefore as they are universally recognized and self-describing and therefore
avoid the need for agreeing to interpret an octet string as a avoid the need to agree to interpret an octet string as a specific
specific form of a MAC address, for instance. Passing URNs may form of a Media Access Control (MAC) address, for instance. Passing
consume additional bytes compared to, for instance, passing 4-byte URNs may consume additional bytes compared to, for instance, passing
binary IPv4 addresses, but offers some flexibility in return. 4-byte binary IPv4 addresses, but the former 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 to represent device identifiers and already support
support MAC addresses as one type of an identifier. However, UUIDs MAC addresses as one type of identifier. However, UUIDs can be
can be inconvenient in environments where it is important that the inconvenient in environments where it is important that the
identifiers are as simple as possible and where additional identifiers be 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. Often, UUID-based identifiers are length can be prohibitive. Often, UUID-based identifiers are
preferred for general purpose uses instead of MAC-based device URNs preferred for general purpose uses instead of the MAC-based device
defined in this document. The device URNs are recommended for URNs defined in this document. The device URNs are recommended for
constrained environments. constrained environments.
Future device identifier types can extend the device URN type defined Future device identifier types can extend the device URN type defined
here (see Section 7), or define their own URNs. in this document (see Section 7), or they can 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.
gives examples. Section 6 discusses the security and privacy Section 5 gives examples. Section 6 discusses the security and
considerations of the new URN type. Finally, Section 7 specifies the privacy considerations of the new URN type. Finally, Section 7
IANA registration for the new URN type and sets requirements for specifies the IANA registration for the new URN type and sets
subtype allocations within this type. requirements for 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DEV URN Definition 3. DEV URN Definition
Namespace Identifier: "dev" requested Namespace Identifier: "dev"
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 group cease to exist, discussion should be directed to the
application area or general IETF discussion forums, or the IESG. Applications and Real-Time Area or general IETF discussion forums,
or the IESG.
3.1. Purpose 3.1. Purpose
Purpose: The DEV URNs identify devices with device-specific The DEV URNs identify devices with device-specific identifiers such
identifiers such as network card hardware addresses. DEV URNs are as network card hardware addresses. DEV URNs are scoped to be
scoped to be globally applicable (see [RFC8141] Section 6.4.1) and, globally applicable (see [RFC8141], Section 6.4.1) and, in general,
in general, enable systems to use these identifiers from multiple enable systems to use these identifiers from multiple sources in an
sources in an interoperable manner. Note that in some deployments, interoperable manner. Note that in some deployments, ensuring
ensuring uniqueness requires care if manual or local assignment uniqueness requires care if manual or local assignment mechanisms are
mechanisms are used, as discussed in Section 3.3. used, as discussed in Section 3.3.
Some typical DEV URN applications include equipment inventories and Some typical DEV URN applications include equipment inventories and
smart 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.
The DEV URN name space complements existing name spaces such as those The DEV URN namespace complements existing namespaces such as those
involving IMEI or UUID identifiers. DEV URNs are expected to be a involving IMEI or UUID identifiers. DEV URNs are expected to be a
part of the IETF-provided basic URN types, covering identifiers that part of the IETF-provided basic URN types, covering identifiers that
have previously not been possible to use in URNs. have previously not been possible to use in URNs.
3.2. Syntax 3.2. Syntax
Syntax: The identifier is expressed in ASCII characters and has a The identifier is expressed in ASCII characters and has a
hierarchical structure as follows: hierarchical structure as follows:
devurn = "urn:dev:" body componentpart devurn = "urn:dev:" body componentpart
body = macbody / owbody / orgbody / osbody / opsbody / otherbody body = macbody / owbody / orgbody / osbody / opsbody / otherbody
macbody = %s"mac:" hexstring macbody = %s"mac:" hexstring
owbody = %s"ow:" hexstring owbody = %s"ow:" hexstring
orgbody = %s"org:" posnumber "-" identifier *( ":" identifier ) orgbody = %s"org:" posnumber "-" identifier *( ":" identifier )
osbody = %s"os:" posnumber "-" serial *( ":" identifier ) osbody = %s"os:" posnumber "-" serial *( ":" identifier )
opsbody = %s"ops:" posnumber "-" product "-" serial *( ":" identifier ) opsbody = %s"ops:" posnumber "-" product "-" serial
otherbody = subtype ":" identifier *( ":" identifier ) *( ":" identifier )
subtype = LALPHA *(DIGIT / LALPHA) otherbody = subtype ":" identifier *( ":" identifier )
identifier = 1*devunreserved subtype = LALPHA *(DIGIT / LALPHA)
identifiernodash = 1*devunreservednodash identifier = 1*devunreserved
product = identifiernodash identifiernodash = 1*devunreservednodash
serial = identifier product = identifiernodash
componentpart = *( "_" identifier ) serial = identifier
devunreservednodash = ALPHA / DIGIT / "." componentpart = *( "_" identifier )
devunreserved = devunreservednodash / "-" devunreservednodash = ALPHA / DIGIT / "."
hexstring = 1*(hexdigit hexdigit) devunreserved = devunreservednodash / "-"
hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hexstring = 1*(hexdigit hexdigit)
posnumber = NZDIGIT *DIGIT hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
ALPHA = %x41-5A / %x61-7A posnumber = NZDIGIT *DIGIT
LALPHA = %x41-5A ALPHA = %x41-5A / %x61-7A
NZDIGIT = %x31-39 LALPHA = %x41-5A
DIGIT = %x30-39 NZDIGIT = %x31-39
DIGIT = %x30-39
The above syntax is represented in Augmented Backus-Naur Form (ABNF) The above syntax is represented in Augmented Backus-Naur Form (ABNF)
form as defined in [RFC5234] and [RFC7405]. The syntax also copies as defined in [RFC5234] and [RFC7405]. The syntax also copies the
the DIGIT and ALPHA rules originally defined in [RFC5234], exactly as DIGIT and ALPHA rules originally defined in [RFC5234], exactly as
defined there. 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 at the end of the DEV The optional underscore-separated components at the end of the DEV
URN depict individual aspects of a device. The specific strings and URN depict individual aspects of a device. The specific strings and
their semantics are up to the designers of the device, but could be their semantics are up to the designers of the device but could be
used to refer to specific interfaces or functions within the device. used to refer to specific interfaces or functions within 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]). Due to the SenML RFC 8428 inside JSON [RFC8259] or SenML [RFC8428]). Due to the SenML rules in
Section 4.5.1 rules, it is not desirable to use percent-encoding in [RFC8428], Section 4.5.1, it is not desirable to use percent-encoding
DEV URNs, and the subtypes defined in this specification do not in DEV URNs, and the subtypes defined in this specification do not
really benefit from percent-encoding. However, this specification really benefit from percent-encoding. However, this specification
does not deviate from the general syntax of URNs or their processing does not deviate from the general syntax of URNs or their processing
and normalization rules as specified in [RFC3986] and [RFC8141]. and normalization rules as specified in [RFC3986] and [RFC8141].
DEV URNs do not use r-, q-, or f-components as defined in [RFC8141]. 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 uppercase and lowercase characters.
URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1, The URN-equivalence of the DEV URNs is defined per [RFC8141],
i.e., two URNs are URN-equivalent if their assigned-name portions are Section 3.1, i.e., two URNs are URN-equivalent if their assigned-name
octet-by-octet equal after applying case normalization to the URI portions are octet-by-octet equal after applying case normalization
scheme ("urn") and namespace identifier ("dev"). The rest of the DEV to the URI scheme ("urn") and namespace identifier ("dev"). The rest
URN is compared in a case sensitive manner. It should be noted that of the DEV URN is compared in a case-sensitive manner. It should be
URN-equivalence matching merely quickly shows that two URNs are noted that URN-equivalence matching merely quickly shows that two
definitely the same for the purposes of caching and other similar URNs are definitely the same for the purposes of caching and other
uses. Two DEV URNs may still refer to the same entity, and not be similar uses. Two DEV URNs may still refer to the same entity and
found URN-equivalent according to the RFC 8141 definition. For may not be found to be URN-equivalent according to the [RFC8141]
instance, in ABNF, strings are case-insensitive (see [RFC5234] definition. For instance, in ABNF, strings are case insensitive (see
Section 2.3), and a MAC address could be represented either with [RFC5234], Section 2.3), and a MAC address could be represented
uppercase or lowercase hexadecimal digits. either with uppercase or lowercase hexadecimal digits.
Character case is not otherwise significant for the DEV URN subtypes Character case is not otherwise significant for the DEV URN subtypes
defined in this document. However, future subtypes might include defined in this document. However, future subtypes might include
identifiers that use encodings such as BASE64, which encode strings identifiers that use encodings such as base64, which encodes strings
in a larger variety of characters, and might even encode binary data. in a larger variety of characters and might even encode binary data.
To facilitate equivalence checks, it is RECOMMENDED that To facilitate equivalence checks, it is RECOMMENDED that
implementations always use lower case letters where they have a implementations always use lowercase letters where they have a choice
choice in case, unless there is a reason otherwise. (Such a reason in case, unless there is a reason otherwise. (Such a reason might
might be, for instance, the use of a subtype that requires the use of be, for instance, the use of a subtype that requires the use of both
both upper case and lower case letters.) uppercase and lowercase letters.)
3.3. Assignment 3.3. Assignment
Assignment: The process for identifier assignment is dependent on the The process for identifier assignment is dependent on the used
used subtype, and documented in the specific subsection under subtype and is 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 or local changed by users or are sometimes assigned in an algorithmic or local
fashion. Any potential conflicts arising from such assignments are fashion. Any potential conflicts arising from such assignments are
not something that the DEV URNs as such manage; they simply are there not something that the DEV URNs as such manage; they simply are there
to refer to a particular identifier. And of course, a single device to refer to a particular identifier. And, of course, a single device
may (and often does) have multiple identifiers, e.g., identifiers may (and often does) have multiple identifiers, e.g., identifiers
associated with different link technologies it supports. associated with different link technologies it supports.
The DEV URN type SHOULD only be used for hardware-based identifiers The DEV URN type SHOULD only be used for hardware-based identifiers
that are expected to be persistent (with some limits, as discussed that are expected to be persistent (with some limits, as discussed
above). above).
3.4. Security and Privacy 3.4. Security and Privacy
Security and Privacy: As discussed in Section 6, care must be taken As discussed in Section 6, care must be taken in the use of device-
in the use of device-identifier-based identifiers due to their nature identifier-based identifiers due to their nature as long-term
as long-term identifiers that are not normally changeable. Leakage identifiers that are not normally changeable. Leakage of these
of these identifiers outside systems where their use is justified identifiers outside systems where their use is justified should be
should be controlled. controlled.
3.5. Interoperability 3.5. Interoperability
Interoperability: There are no specific interoperability concerns. There are no specific interoperability concerns.
3.6. Resolution 3.6. Resolution
Resolution: The device identifiers are not expected to be globally The device identifiers are not expected to be globally resolvable.
resolvable. No identifier resolution system is expected. Systems No identifier resolution system is expected. Systems may perform
may perform local matching of identifiers to previously seen local matching of identifiers to previously seen identifiers or
identifiers or configured information, however. configured information, however.
3.7. Documentation 3.7. Documentation
See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the See RFC 9039.
RFC number of this document).
3.8. Additional Information 3.8. Additional Information
See Section 1 for a discussion of related name spaces. See Section 1 for a discussion of related namespaces.
3.9. Revision Information 3.9. Revision Information
Revision Information: This is the first version of this registration. This is the first version of this registration.
4. DEV URN Subtypes 4. DEV URN Subtypes
4.1. MAC Addresses 4.1. MAC Addresses
DEV URNs of the "mac" subtype are based on the EUI-64 identifier DEV URNs of the "mac" subtype are based on the EUI-64 identifier
[IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64.
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 MAC-48 address (the first three octets) becomes the Organizationally Unique Identifier (OUI) of the MAC-48 address (the
organization identifier of the EUI-64 (the first three octets). The first three octets) becomes the organization identifier of the EUI-64
fourth and fifth octets of the EUI are set to the fixed value 0xffff (the first three octets). The fourth and fifth octets of the EUI are
(hexadecimal). The last three octets of the MAC-48 address become set to the fixed value 0xffff (hexadecimal). The last three octets
the last three octets of the EUI-64. The same process is used to of the MAC-48 address become the last three octets of the EUI-64.
convert an EUI-48 identifier, but the fixed value 0xfffe is used The same process is used to convert an EUI-48 identifier, but the
instead. fixed value 0xfffe is used instead.
Identifier assignment for all of these identifiers rests within the Identifier assignment for all of these identifiers rests within the
IEEE Registration Authority. IEEE Registration Authority.
Note that where randomized MAC addresses are used, the resulting DEV Note that where randomized MAC addresses are used, the resulting DEV
URNs cannot be expected to have uniqueness, as discussed in URNs cannot be expected to have uniqueness, as discussed in
Section 3.3. Section 3.3.
4.2. 1-Wire Device Identifiers 4.2. 1-Wire Device Identifiers
The 1-Wire* system is a device communications bus system designed by The 1-Wire system is a device communications bus system designed by
Dallas Semiconductor Corporation. 1-Wire devices are identified by a Dallas Semiconductor Corporation. (1-Wire is a registered trademark.)
64-bit identifier that consists of 8 bit family code, 48 bit 1-Wire devices are identified by a 64-bit identifier that consists of
identifier unique within a family, and 8 bit CRC code [OW]. an 8-bit family code, a 48-bit identifier unique within a family, and
an 8-bit Cyclic Redundancy Check (CRC) code [OW].
*) 1-Wire is a registered trademark.
In DEV URNs with the "ow" subtype the hexstring is a representation In DEV URNs with the "ow" subtype, the hexstring is a representation
of the full 64-bit identifier as a hexadecimal string. It is always of the full 64-bit identifier as a hexadecimal string. It is always
exactly 16 characters long. Note that the last two characters exactly 16 characters long. Note that the last two characters
represent the 8-bit CRC code. Implementations MAY check the validity represent the 8-bit CRC code. Implementations MAY check the validity
of this code. of this code.
Family code and identifier assignment for all 1-Wire devices rests Family code and identifier assignment for all 1-Wire devices rests
with the manufacturers. with the manufacturers.
4.3. Organization-Defined Identifiers 4.3. Organization-Defined Identifiers
Device identifiers that have only a meaning within an organization Device identifiers that have only a meaning within an organization
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
organization. organization.
Organizations 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 are
at https://pen.iana.org/pen/PenApplication.page. requested 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 cannot 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 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.
Historical note: The "os" subtype was originally been defined in | Historical note: The "os" subtype was originally defined in the
the Open Mobile Alliance "Lightweight Machine to Machine" standard | Open Mobile Alliance "Lightweight Machine to Machine" standard
[LwM2M], but has been incorporated here to collect all syntax | [LwM2M] but has been incorporated here to collect all syntaxes
associated with DEV URNs in one place. At the same time, the | associated with DEV URNs in one place. At the same time, the
syntax of this subtype was changed to avoid the possibility of | syntax of this subtype was changed to avoid the possibility of
characters that are not allowed in SenML Name field (see [RFC8428] | characters that are not allowed in the SenML Name field (see
Section 4.5.1). | [RFC8428], Section 4.5.1).
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 Organizations are also encouraged to select serial number formats
that avoid possibility for ambiguity, in the form of leading zeroes that avoid the possibility of ambiguity in the form of leading zeroes
or otherwise. 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 was originally defined in the LwM2M
standard, but has been incorporated here to collect all syntax standard but has been incorporated here to collect all syntaxes
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.
Historical note: As with the "os" subtype, the "ops" subtype has | Historical note: As with the "os" subtype, the "ops" subtype
originally been defined in OMA. | was originally defined in the Open Mobile Alliance "Lightweight
| Machine to Machine" standard [LwM2M].
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 they 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 4.6. Future Subtypes
Additional subtypes may be defined in other, future specifications. Additional subtypes may be defined in future specifications. See
See Section 7. Section 7.
The DEV URN "example" subtype is reserved for use in examples. It The DEV URN "example" subtype is reserved for use in examples. It
has no specific requirements beyond those expressed by the ABNF in has no specific requirements beyond those expressed by the ABNF in
Section 3.2. 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 +=========================================+=========================+
# 0024be804ff1, converted | URN | Description |
# to EUI-64 format +=========================================+=========================+
| urn:dev:mac:0024beffff804ff1 | The MAC-48 address of |
urn:dev:mac:0024befffe804ff1 # The EUI-48 address of | | 0024be804ff1, |
# 0024be804ff1, converted | | converted to EUI-64 |
# to EUI-64 format | | format |
+-----------------------------------------+-------------------------+
urn:dev:mac:acde48234567019f # The EUI-64 address of | urn:dev:mac:0024befffe804ff1 | The EUI-48 address of |
# acde48234567019f | | 0024be804ff1, |
| | converted to EUI-64 |
urn:dev:ow:10e2073a01080063 # A 1-Wire temperature | | format |
# sensor +-----------------------------------------+-------------------------+
| urn:dev:mac:acde48234567019f | The EUI-64 address of |
urn:dev:ow:264437f5000000ed_humidity # The humidity | | acde48234567019f |
# part of a multi-sensor +-----------------------------------------+-------------------------+
# device | urn:dev:ow:10e2073a01080063 | A 1-Wire temperature |
| | sensor |
urn:dev:ow:264437f5000000ed_temperature # The temperature +-----------------------------------------+-------------------------+
# part of a multi-sensor | urn:dev:ow:264437f5000000ed_humidity | The humidity part of |
# device | | a multi-sensor device |
+-----------------------------------------+-------------------------+
urn:dev:org:32473-foo # An organization- | urn:dev:ow:264437f5000000ed_temperature | The temperature part |
# specific URN in | | of a multi-sensor |
# the RFC 5612 example | | device |
# organization, 32473. +-----------------------------------------+-------------------------+
| urn:dev:org:32473-foo | An organization- |
urn:dev:os:32473-123456 # Device 123456 in | | specific URN in the |
# the RFC 5612 example | | example organization |
# organization | | 32473 in [RFC5612] |
+-----------------------------------------+-------------------------+
urn:dev:os:32473-12-34-56 # A serial number with | urn:dev:os:32473-123456 | Device 123456 in the |
# dashes in it | | example organization |
| | in [RFC5612] |
urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial +-----------------------------------------+-------------------------+
# number 5002 in the | urn:dev:os:32473-12-34-56 | A serial number with |
# RFC 5612 example | | dashes in it |
# organization +-----------------------------------------+-------------------------+
| urn:dev:ops:32473-Refrigerator-5002 | Refrigerator serial |
| | number 5002 in the |
| | example organization |
| | in [RFC5612] |
+-----------------------------------------+-------------------------+
| urn:dev:example:new-1-2-3_comp | An example of |
| | something that is not |
| | defined today, and is |
| | not one of the mac, |
| | ow, os, or ops |
| | subtypes |
+-----------------------------------------+-------------------------+
urn:dev:example:new-1-2-3_comp # An example of something Table 1
# 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. This
example, this example from [RFC8428] shows a measurement from a example from [RFC8428] shows a measurement from a 1-Wire temperature
1-Wire temperature gauge encoded in the JSON syntax. 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 tampered with by the user. An implementation of the DEV URN MUST
skipping to change at page 12, line 32 skipping to change at line 548
6.1. Privacy 6.1. Privacy
Other devices in the same network may or may not be able to identify Other devices in the same network may or may not be able to identify
the device. For instance, on an Ethernet network, the MAC address of the device. For instance, on an Ethernet network, the MAC address of
a device is visible to all other devices. a device is visible to all other devices.
DEV URNs often represent long-term stable unique identifiers for DEV URNs often represent long-term stable unique identifiers for
devices. Such identifiers may have privacy and security implications devices. Such identifiers may have privacy and security implications
because they may enable correlating information about a specific because they may enable correlating information about a specific
device over a long period of time, location tracking, and device device over a long period of time, location tracking, and device-
specific vulnerability exploitation [RFC7721]. Also, in some systems specific vulnerability exploitation [RFC7721]. Also, in some
there is no easy way to change the identifier. Therefore these systems, there is no easy way to change the identifier. Therefore,
identifiers need to be used with care and especially care should be these identifiers need to be used with care, and special care should
taken to avoid leaking them outside of the system that is intended to be taken to avoid leaking identifiers outside of the system that is
use the identifiers. intended to use them.
6.2. Validity 6.2. Validity
Information about identifiers may have significant effects in some Information about identifiers may have significant effects in some
applications. For instance, in many sensor systems the identifier applications. For instance, in many sensor systems, the identifier
information is used for deciding how to use the data carried in a information is used for deciding how to use the data carried in a
measurement report. On some other systems, identifiers may be used measurement report. In some other systems, identifiers may be used
in policy decisions. in policy decisions.
It is important that systems are designed to take into account the It is important that systems be designed to take into account the
possibility of devices reporting incorrect identifiers (either possibility of devices reporting incorrect identifiers (either
accidentally or maliciously) and the manipulation of identifiers in accidentally or maliciously) and the manipulation of identifiers in
communications by illegitimate entities. Integrity protection of communications by illegitimate entities. Integrity protection of
communications or data objects, the use of trusted devices, and communications or data objects, the use of trusted devices, and
various management practices can help address these issues. various management practices can help address these issues.
The advice from [RFC4122] Section 6 also applies: Do not assume that Similar to the advice in [RFC4122], Section 6: Do not assume that DEV
DEV URNs are hard to guess. URNs are hard to guess.
7. IANA Considerations 7. IANA Considerations
This document requests the registration of a new URN namespace for Per this document, IANA has registered a new URN namespace for "dev",
"DEV", as described in Section 3. as described in Section 3.
IANA is asked to create a "DEV URN Subtypes" registry. The initial IANA has created a "DEV URN Subtypes" registry under "Device
values in this registry are as follows: Identification". The initial values in this registry are as follows:
Subtype Description Reference +=========+===========================+=======================+
mac MAC Addresses (THIS RFC) Section 4.1 | Subtype | Description | Reference |
ow 1-Wire Device Identifiers (THIS RFC) Section 4.2 +=========+===========================+=======================+
org Organization-Defined Identifiers (THIS RFC) Section 4.3 | mac | MAC Addresses | RFC 9039, Section 4.1 |
os Organization Serial Numbers (THIS RFC) Section 4.4 +---------+---------------------------+-----------------------+
ops Organization Product and Serial Numbers (THIS RFC) Section 4.5 | ow | 1-Wire Device Identifiers | RFC 9039, Section 4.2 |
example Reserved for examples (THIS RFC) Section 4.6 +---------+---------------------------+-----------------------+
| org | Organization-Defined | RFC 9039, Section 4.3 |
| | Identifiers | |
+---------+---------------------------+-----------------------+
| os | Organization Serial | RFC 9039, Section 4.4 |
| | Numbers | |
+---------+---------------------------+-----------------------+
| ops | Organization Product and | RFC 9039, Section 4.5 |
| | Serial Numbers | |
+---------+---------------------------+-----------------------+
| example | Reserved for examples | RFC 9039, Section 4.6 |
+---------+---------------------------+-----------------------+
Table 2
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 identifier that is defined in a stable fashion and has a publicly
specification. available specification.
Note that the organization (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 organization device identifier type. the organization device identifier type.
8. References 8. References
8.1. Normative References 8.1. Normative References
[IEEE.EUI64]
IEEE, "Guidelines for Use of Extended Unique Identifier
(EUI), Organizationally Unique Identifier (OUI), and
Company ID (CID)", August 2017,
<https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>.
[OW] Maxim, "Guide to 1-Wire Communication", June 2008,
<https://www.maximintegrated.com/en/design/technical-
documents/tutorials/1/1796.html>.
[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,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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,
editor.org/info/rfc2578>. <https://www.rfc-editor.org/info/rfc2578>.
[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>.
[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,
editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[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] 8.2. Informative References
IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
IEEE , unknown year,
<https://standards.ieee.org/content/dam/ieee-
standards/standards/web/documents/tutorials/eui.pdf>.
[OW] Maxim, "Guide to 1-Wire Communication", MAXIM [CoRE-RD] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
https://www.maximintegrated.com/en/design/technical- P. van der Stok, "CoRE Resource Directory", Work in
documents/tutorials/1/1796.html, June 2008, Progress, Internet-Draft, draft-ietf-core-resource-
<https://www.maximintegrated.com/en/design/technical- directory-28, 7 March 2021, <https://tools.ietf.org/html/
documents/tutorials/1/1796.html>. draft-ietf-core-resource-directory-28>.
8.2. Informative References [LwM2M] Alliance, O. M., "OMA Lightweight Machine to Machine
Requirements", OMA Standard Candidate Version 1.2, January
2019, <https://www.openmobilealliance.org/release/
LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-
V1_2-20190124-C.pdf>.
[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,
editor.org/info/rfc3261>. <https://www.rfc-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,
editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
<https://www.rfc-editor.org/info/rfc4648>. 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>.
[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
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
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, <https://www.rfc-
editor.org/info/rfc8259>.
[W3C.REC-xml-19980210]
Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0
Recommendation", World Wide Web Consortium FirstEdition
REC-xml-19980210, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>.
[OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage,
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, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, <https://www.rfc- DOI 10.17487/RFC7252, June 2014,
editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
DOI 10.17487/RFC8428, August 2018, <https://www.rfc-
editor.org/info/rfc8428>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<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", [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014, RFC 7405, DOI 10.17487/RFC7405, December 2014,
<https://www.rfc-editor.org/info/rfc7405>. <https://www.rfc-editor.org/info/rfc7405>.
[RFC8464] Atarius, R., "A URN Namespace for Device Identity and [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Mobile Equipment Identity (MEID)", RFC 8464, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC8464, September 2018, <https://www.rfc- DOI 10.17487/RFC7540, May 2015,
editor.org/info/rfc8464>. <https://www.rfc-editor.org/info/rfc7540>.
[I-D.ietf-core-resource-directory]
Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P.
Stok, "CoRE Resource Directory", draft-ietf-core-resource-
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 Versions
Editor's note: Please remove this section before publication.
Version -11 was created to address non-blocking comments from the
IESG review. This version made the following changes:
o Removed space after the "%s" in the ABNF RFC 7405 syntax.
o Softened and clarified the recommendation regarding UUIDs in
Section 1.
o Added a paragraph about the impacts of using randomized MAC
addresses.
o Added advice regarding ease of guessing DEV URNs, in Section 6.2.
o Simplified and clarified the "illegitimate entities" statement in
Section 6.2.
o Clarified the persistence statement in Section 3.3.
Version -10 made the following changes:
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:
o Aligned the use of identifiers vs. identity terms.
o Added a security considerations subsection on validity of claimed
identifiers.
o Focused on "care" in the RFC 7721 reference, rather than "care and
avoidance".
o Renamed the "unreserved" ABNF terminal to avoid confusion with the
general URN ABNF terminal with the same name.
o Removed the mistakenly included text about MEID subtype.
o Clarified URN syntax differences and normalization rules wrt the
lack of percent-encoding in DEV URNs.
o Required PEN numbers to start with non-zero digit in the ABNF and
changed the associated language later in the draft.
o Text about case-insensitivity in RFC 5234 was clarified.
o Text about uniqueness was clarified.
o Text about global scope was clarified.
o An example of DEV URN usage in SenML was added.
o Editorial changes.
Version -08 of the WG draft took into account Barry Leiba's AD review
comments. To address these comments, changes were made in
o Further updates of the upper/lower case rules for the DEV URNs.
o Further updates to the ABNF.
o The use of HEXDIG from RFC 5234.
o IANA considerations for the creation of separate registry for the
own parameters of DEV URNs.
o Editorial improvements.
Version -07 of the WG draft took into account Carsten Bormann's
feedback, primarily on character case issues and editorials.
Version -06 of the WG draft took into account Marco Tiloca's feedback
before a second WGLC, primarily on further cleanup of references and
editorial issues.
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:
o Parts of the ANBF now allow for use cases for the component part
that were not previously covered: the syntax now allows the
character "." to appear, and serial numbers can have dashes in
them.
o The syntax was also extended to allow for extensibility by adding
additional ":" separated parts for the org, op, ops, and other
subtypes.
o The ABNF was changed to include directly the ALPHA and DIGIT parts
imported from RFC 5234, instead of just having a verbal comment
about it. (Note that the style in existing RFCs differs on this.)
In addition, in -04 the MAC example was corrected to use the inserted
value ffff instead of fffe, required by Section 4.1, the org example
was corrected, the os: examples and otherbody examples were added.
The IANA rules for allocating new subtypes was slightly relaxed in
order to cover for new subtype cases that are brought up regularly,
and often not from inside the IETF. Finally, the allocation of PEN
numbers and the use of product classes and serial numbers was better
explained.
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
the dev:urn syntax from LwM2M, as they seemed to match well what
already existed in this document under the "org" branch. However, as
a part of this three changes were incorporated:
o The syntax for the "org:" changes to use "-" rather than ":"
between the OUI and the rest of the URN.
o The organizations for the "ops" and "os" branches have been
changed to use PEN numbers rather than OUI numbers [OUI]. The
reason for this is that PEN numbers are allocated through a
simpler and less costly process. However, this is a significant
change to how LwM2M identifiers were specified before.
o There were also changes to what general characters can be used in
the otherbody branch of the ABNF.
The rationale for all these changes is that it would be helpful for
the community collect and unify syntax between the different uses of
DEV URNs. If there is significant use of either the org:, os:, or
ops: subtypes, then changes at this point may not be warranted, but
otherwise unified syntax, as well as the use of PEN numbers would
probably be beneficial. Comments on this topic are appreciated.
Version -01 of the WG draft converted the draft to use the new URN
registration template from [RFC8141].
Version -00 of the WG draft renamed the file name and fixed the ABNF
to correctly use "org:" rather than "dn:".
Version -05 made a change to the delimiter for parameters within a
DEV URN. Given discussions on allowed character sets in SenML
[RFC8428], we would like to suggest that the "_" character be used
instead of ";", to avoid the need to translate DEV URNs in SenML-
formatted communications or files. However, this reverses the
earlier decision to not use unreserved characters. This also means
that device IDs cannot use "_" characters, and have to employ other
characters instead. Feedback on this decision is sought.
Version -05 also introduced local or organization-specific device
identifiers. Organizations are identified by their PEN number
(although we considered FQDNs as a potential alternative. The
authors belive an organization-specific device identifier type will
make experiments and local use easier, but feedback on this point and
the choice of PEN numbers vs. other possible organization identifiers
would be very welcome.
Version -05 also added some discussion of privacy concerns around [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
long-term stable identifiers. Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
Finally, version -05 clarified the situations when new allocations [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
within the registry of possible device identifier subtypes is Interchange Format", STD 90, RFC 8259,
appropriate. DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
Version -04 is a refresh, as the need and interest for this [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
specification has re-emerged. And the editing author has emerged Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
back to actual engineering from the depths of IETF administration. DOI 10.17487/RFC8428, August 2018,
<https://www.rfc-editor.org/info/rfc8428>.
Version -02 introduced several changes. The biggest change is that [RFC8464] Atarius, R., "A URN Namespace for Device Identity and
with the NI URNs [RFC6920], it was no longer necessary to define Mobile Equipment Identity (MEID)", RFC 8464,
cryptographic identifiers in this specification. Another change was DOI 10.17487/RFC8464, September 2018,
that we incorporated a more generic syntax for future extensions; <https://www.rfc-editor.org/info/rfc8464>.
non-hexstring identifiers can now also be supported, if some future
device identifiers for some reason would, for instance, use some kind
of encoding such as Base64 [RFC4648]. As a part of this change, we
also changed the component part separator character from '-' to ';'
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 [W3C.REC-xml-19980210]
some editorial corrections. Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible
Markup Language (XML) 1.0", W3C Recommendation, February
1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
Appendix B. Acknowledgments Acknowledgments
The authors would like to thank Ari Keranen, Stephen Farrell, The authors would like to thank Ari Keränen, 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, Warren Kumari, Benjamin Amanda Baber, Juha Hakala, Dale Worley, Warren Kumari, Benjamin
Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ Housley, Dan Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ Housley, Dan
Romascanu, Eric Vyncke, Roman Danyliw, and Ahmad Muhanna for feedback Romascanu, Éric Vyncke, Roman Danyliw, and Ahmad Muhanna for their
and interesting discussions in this problem space. We would also feedback and interesting discussions in this problem space. We would
like to note prior documents that focused on specific device also like to note prior documents that focused on specific device
identifiers, such as [RFC7254] or [RFC8464]. identifiers, such as [RFC7254] and [RFC8464].
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 FI-02420 Jorvas
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 United States of America
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@iii.ca
Zach Shelby Zach Shelby
ARM Edge Impulse
Kidekuja 2 3031 Tisch Way
Vuokatti 88600 San Jose, CA 95128
FINLAND United States of America
Phone: +358407796297 Email: zach@edgeimpulse.com
Email: Zach.Shelby@arm.com
 End of changes. 94 change blocks. 
567 lines changed or deleted 367 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/