rfc9039xml2.original.xml   rfc9039.xml 
<?xml version="1.0" encoding="iso-8859-1" ?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2578.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5234.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3261.xml">
<!ENTITY RFC3971 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3971.xml">
<!ENTITY RFC3972 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3972.xml">
<!ENTITY RFC4122 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4122.xml">
<!ENTITY RFC4648 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4648.xml">
<!ENTITY RFC5612 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5612.xml">
<!ENTITY RFC6920 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6920.xml">
<!ENTITY RFC7230 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7230.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7252.xml">
<!ENTITY RFC7254 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7254.xml">
<!ENTITY RFC7405 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7405.xml">
<!ENTITY RFC7540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7540.xml">
<!ENTITY RFC7721 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7721.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC8141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8141.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8259 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8259.xml">
<!ENTITY RFC8428 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8428.xml">
<!ENTITY RFC8464 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8464.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public
/rfc/bibxml3/reference.I-D.ietf-core-resource-directory.xml">
]>
<rfc ipr="trust200902"
docName="draft-ietf-core-dev-urn-11"
category="std">
<?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>
<front>
<title abbrev="DEV URN">Uniform Resource Names for Device Identifiers</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<organization>Ericsson</organization> -ietf-core-dev-urn-11" number="9039" obsoletes="" updates="" submissionType="IET
<address> F" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true
<postal> " sortRefs="true" version="3">
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<!-- xml2rfc v2v3 conversion 3.5.0 -->
<front>
<title abbrev="DEV URN">Uniform Resource Names for Device Identifiers</title
>
<seriesInfo name="RFC" value="9039"/>
<author initials="J." surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city>
<code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings"> <author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>170 West Tasman Drive</street> <street>170 West Tasman Drive</street>
<city>San Jose</city> <city>San Jose</city>
<region>CA</region> <region>CA</region>
<code>95134</code> <code>95134</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<phone>+1 408 421-9990</phone> <phone>+1 408 421-9990</phone>
<email>fluffy@iii.ca</email>
<email>fluffy@cisco.com</email>
</address> </address>
</author> </author>
<author initials="Z." surname="Shelby" fullname="Zach Shelby">
<author initials="Z" surname="Shelby" fullname="Zach Shelby"> <organization>
<organization> Edge Impulse
ARM </organization>
</organization> <address>
<address> <postal>
<postal> <street>3031 Tisch Way</street>
<street>Kidekuja 2</street> <city>San Jose</city>
<city>Vuokatti</city> <region>CA</region>
<code>88600</code> <code>95128</code>
<country>FINLAND</country> <country>United States of America</country>
</postal> </postal>
<phone>+358407796297</phone> <email>zach@edgeimpulse.com</email>
<email>Zach.Shelby@arm.com</email> </address>
</address> </author>
</author> <date month="June" year="2021"/>
<keyword>URN</keyword>
<date month="February" year="2021" /> <keyword>device identifier</keyword>
<keyword>IMEI</keyword>
<keyword>URN</keyword> <keyword>1-Wire</keyword>
<keyword>device identifier</keyword> <keyword>MAC address</keyword>
<keyword>IMEI</keyword> <keyword>EUI-48</keyword>
<keyword>1-Wire</keyword> <keyword>EUI-64</keyword>
<keyword>MAC address</keyword> <abstract>
<keyword>EUI-48</keyword> <t>This document describes a new Uniform Resource Name (URN) namespace for
<keyword>EUI-64</keyword>
<abstract>
<t>This document 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 in equipment inventories. A URN-based
representation can be passed along in applications that representation can be passed along in applications that
need the information.</t> need the information.</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
</abstract> <t>This document describes a new Uniform Resource Name (URN) <xref target=
"RFC8141" format="default"/> namespace for hardware
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>This document describes a new Uniform Resource Name (URN) <xref
target="RFC8141"/> namespace for hardware
device identifiers. A general representation of device identity device identifiers. A general representation of device identity
can be useful in many applications, such as in sensor data streams can be useful in many applications, such as in sensor data streams
and storage and storage
<xref target="RFC8428"/>, or equipment inventories <xref target="RFC7252"/>, or in equipment inventories <xref target="RFC7252" format="default"/> <xref
<xref target="I-D.ietf-core-resource-directory"/>.</t> target="RFC8428" format="default"/> <xref target="I-D.ietf-core-resource-direct
ory" format="default"/>.</t>
<t>A URN-based representation can be passed along in applications <t>A URN-based representation can be passed along in applications
that need the information. It fits particularly well for protocols that need the information. It fits particularly well for protocols
mechanisms that are designed to carry URNs <xref mechanisms that are designed to carry URNs <xref target="RFC7230" format="de
target="RFC7230"/>, <xref target="RFC7540"/>, <xref fault"/> <xref target="RFC7540" format="default"/> <xref target="RFC3261" format
target="RFC3261"/>, <xref target="RFC7252"/>. Finally, URNs can ="default"/> <xref target="RFC7252" format="default"/>. Finally, URNs can
also be easily carried and stored in formats such as XML <xref also be easily carried and stored in formats such as XML <xref target="W3C.R
target="W3C.REC-xml-19980210"/>, JSON <xref target="RFC8259"/> or EC-xml-19980210" format="default"/>, JSON <xref target="RFC8259" format="default
SenML <xref target="RFC8428"/>. Using URNs in these formats is "/>, or
SenML <xref target="RFC8428" format="default"/>. Using URNs in these format
s is
often preferable as they are universally recognized and often preferable as they are universally recognized and
self-describing, and therefore avoid the need for agreeing to self-describing and therefore avoid the need to agree to
interpret an octet string as a specific form of a MAC address, for interpret an octet string as a specific form of a Media Access Control (MAC)
address, for
instance. Passing URNs may consume additional bytes compared to, instance. Passing URNs may consume additional bytes compared to,
for instance, passing 4-byte binary IPv4 addresses, but offers for instance, passing 4-byte binary IPv4 addresses, but the former offers
some flexibility in return.</t> some flexibility in return.</t>
<t>This document defines identifier URN types for situations where no
<t>This document defines identifier URN types for situations where no such convenient type already exists. For instance, <xref target="RFC6920" fo
such convenient type already exists. For instance, <xref rmat="default"/> defines cryptographic identifiers, <xref target="RFC7254" forma
target="RFC6920"/> defines cryptographic identifiers, <xref t="default"/> defines International Mobile station Equipment
target="RFC7254"/> defines International Mobile station Equipment
Identity (IMEI) identifiers for use with 3GPP cellular systems, Identity (IMEI) identifiers for use with 3GPP cellular systems,
and <xref target="RFC8464"/> defines Mobile and <xref target="RFC8464" format="default"/> defines Mobile
Equipment Identity (MEID) identifiers for use with 3GPP2 cellular Equipment Identity (MEID) identifiers for use with 3GPP2 cellular
systems. Those URN types should be employed when such identifiers systems. Those URN types should be employed when such identifiers
are transported; this document does not redefine these identifiers in are transported; this document does not redefine these identifiers in
any way.</t> any way.</t>
<t>Universally Unique IDentifier (UUID) URNs <xref <t>Universally Unique Identifier (UUID) URNs <xref target="RFC4122" format
target="RFC4122"/> are another alternative way for representing ="default"/> are another alternative way to represent
device identifiers, and already support MAC addresses as one type device identifiers and already support MAC addresses as one type
of an identifier. However, UUIDs can be inconvenient in of identifier. However, UUIDs can be inconvenient in
environments where it is important that the identifiers are as environments where it is important that the identifiers be as
simple as possible and where additional requirements on stable simple as possible and where additional requirements on stable
storage, real-time clocks, and identifier length can be storage, real-time clocks, and identifier length can be
prohibitive. Often, UUID-based identifiers are preferred for prohibitive. Often, UUID-based identifiers are preferred for
general purpose uses instead of MAC-based device URNs defined in general purpose uses instead of the MAC-based device URNs defined in
this document. The device URNs are recommended for constrained this document. The device URNs are recommended for constrained
environments.</t> environments.</t>
<t>Future device identifier types can extend the device URN
<t>Future device identifier types can extend the device URN type defined in this document (see <xref target="iana" format="default"/>),
type defined here (see <xref target="iana"/>), or define their own URNs.</t> or they can define their own URNs.</t>
<t>Note that long-term stable unique identifiers are problematic
<t>Note that long-term stable unique identifiers are problematic
for privacy reasons and should be used with care as for privacy reasons and should be used with care as
described in <xref target="RFC7721"/>.</t> described in <xref target="RFC7721" format="default"/>.</t>
<t>The rest of this document is organized as follows. <xref target="devurn
<t>The rest of this document is organized as follows. <xref " format="default"/> defines the "DEV" URN type, and <xref target="subtypes" for
target="devurn"/> defines the "DEV" URN type, and <xref mat="default"/> defines subtypes for IEEE MAC-48, EUI-48 and
target="subtypes"/> defines subtypes for IEEE MAC-48, EUI-48 and EUI-64 addresses, and 1-Wire device identifiers. <xref target="ex" format="
EUI-64 addresses and 1-Wire device identifiers. <xref default"/> gives examples. <xref target="sec" format="default"/> discusses the
target="ex"/> gives examples. <xref target="sec"/> discusses the security and privacy considerations of the new URN type. Finally, <xref targ
security and privacy considerations of the new URN type. Finally, <xref et="iana" format="default"/> specifies the IANA registration for the new URN
target="iana"/> specifies the IANA registration for the new URN
type and sets requirements for subtype allocations within this type and sets requirements for subtype allocations within this
type.</t> type.</t>
</section>
</section> <section anchor="kwd" numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="kwd" title='Requirements language'> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
"OPTIONAL" in this document are to be interpreted as described in BCP RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
when, they appear in all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section anchor="devurn" title="DEV URN Definition"> </section>
<section anchor="devurn" numbered="true" toc="default">
<t>Namespace Identifier: "dev" requested</t> <name>DEV URN Definition</name>
<dl>
<t>Version: 1</t> <dt>Namespace Identifier:</dt><dd>"dev"</dd>
<dt>Version:</dt><dd>1</dd>
<t>Date: 2020-06-24</t> <dt>Date:</dt><dd>2020-06-24</dd>
<dt>Registrant:</dt><dd>IETF and the CORE Working Group. Should the workin
<t>Registrant: IETF and the CORE working group. Should the working g
group cease to exist, discussion should be directed to the application group cease to exist, discussion should be directed to the
area or general IETF discussion forums, or the IESG.</t> Applications and Real-Time Area or general IETF discussion forums, or the
IESG.</dd></dl>
<section title="Purpose"> <section numbered="true" toc="default">
<name>Purpose</name>
<t>Purpose: The DEV URNs identify devices with device-specific <t>The DEV URNs identify devices with device-specific
identifiers such as network card hardware addresses. DEV URNs identifiers such as network card hardware addresses. DEV URNs
are scoped to be globally applicable (see <xref are scoped to be globally applicable (see <xref target="RFC8141" sectionF
target="RFC8141"/> Section 6.4.1) and, in general, enable ormat="comma" section="6.4.1"/>) and, in general, enable
systems to use these identifiers from multiple sources in an systems to use these identifiers from multiple sources in an
interoperable manner. Note that in some deployments, ensuring interoperable manner. Note that in some deployments, ensuring
uniqueness requires care if manual or local assignment uniqueness requires care if manual or local assignment
mechanisms are used, as discussed in <xref mechanisms are used, as discussed in <xref target="assignment" format="de
target="assignment"/>. fault"/>.
<vspace blankLines="1"/> </t>
<t>
Some typical DEV URN applications include equipment Some typical DEV URN applications include equipment
inventories and smart object systems.<vspace blankLines="1"/> inventories and smart object systems.
</t>
<t>
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 systems, and network components, in tasks ranging from
discovery (for instance when discovering 1-Wire network discovery (for instance, when discovering 1-Wire network
devices or detecting MAC-addressable devices on a LAN) to devices or detecting MAC-addressable devices on a LAN) to
intrusion detection systems and simple catalogues of system intrusion detection systems and simple catalogues of system
information.<vspace blankLines="1"/> information.
</t>
<t>
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 is relevant identifier fields in local link communication. However, it is
often useful to be able to pass device identifier information in generic often useful to be able to pass device identifier information in generic
URN fields in databases or protocol fields, which makes the use of URN fields in databases or protocol fields, which makes the use of
URNs for this purpose convenient.<vspace blankLines="1"/> URNs for this purpose convenient.
</t>
The DEV URN name space complements existing name spaces such as those <t>
The DEV URN namespace complements existing namespaces such as those
involving IMEI or UUID identifiers. DEV URNs are expected to be a part involving IMEI or UUID identifiers. DEV URNs are expected to be a part
of the IETF-provided basic URN types, covering identifiers that have of the IETF-provided basic URN types, covering identifiers that have
previously not been possible to use in URNs.</t> previously not been possible to use in URNs.
</t>
</section> </section>
<section anchor="syntax" numbered="true" toc="default">
<section anchor="syntax" title="Syntax"> <name>Syntax</name>
<t>The identifier is expressed in
<t>Syntax: The identifier is expressed in
ASCII characters and has a hierarchical structure as ASCII characters and has a hierarchical structure as
follows:</t> follows:</t>
<sourcecode name="" type="abnf"><![CDATA[
<figure> devurn = "urn:dev:" body componentpart
<artwork> body = macbody / owbody / orgbody / osbody / opsbody / otherbody
devurn = "urn:dev:" body componentpart macbody = %s"mac:" hexstring
body = macbody / owbody / orgbody / osbody / opsbody / otherbody owbody = %s"ow:" hexstring
macbody = %s"mac:" hexstring orgbody = %s"org:" posnumber "-" identifier *( ":" identifier )
owbody = %s"ow:" hexstring osbody = %s"os:" posnumber "-" serial *( ":" identifier )
orgbody = %s"org:" posnumber "-" identifier *( ":" identifier ) opsbody = %s"ops:" posnumber "-" product "-" serial
osbody = %s"os:" posnumber "-" serial *( ":" identifier ) *( ":" identifier )
opsbody = %s"ops:" posnumber "-" product "-" serial *( ":" identifier ) otherbody = subtype ":" identifier *( ":" identifier )
otherbody = subtype ":" identifier *( ":" identifier ) subtype = LALPHA *(DIGIT / LALPHA)
subtype = LALPHA *(DIGIT / LALPHA) identifier = 1*devunreserved
identifier = 1*devunreserved identifiernodash = 1*devunreservednodash
identifiernodash = 1*devunreservednodash product = identifiernodash
product = identifiernodash serial = identifier
serial = identifier componentpart = *( "_" identifier )
componentpart = *( "_" identifier ) devunreservednodash = ALPHA / DIGIT / "."
devunreservednodash = ALPHA / DIGIT / "." devunreserved = devunreservednodash / "-"
devunreserved = devunreservednodash / "-" hexstring = 1*(hexdigit hexdigit)
hexstring = 1*(hexdigit hexdigit) hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" posnumber = NZDIGIT *DIGIT
posnumber = NZDIGIT *DIGIT ALPHA = %x41-5A / %x61-7A
ALPHA = %x41-5A / %x61-7A LALPHA = %x41-5A
LALPHA = %x41-5A NZDIGIT = %x31-39
NZDIGIT = %x31-39 DIGIT = %x30-39
DIGIT = %x30-39 ]]></sourcecode>
</artwork> <t>The above syntax is represented in Augmented Backus-Naur
</figure> Form (ABNF) as defined in <xref target="RFC5234" format="default"/> and
<xref target="RFC7405" format="default"/>. The syntax also copies the DIG
<t>The above syntax is represented in Augmented Backus-Naur IT and
Form (ABNF) form as defined in <xref target="RFC5234"/> and ALPHA rules originally defined in <xref target="RFC5234" format="default"
<xref target="RFC7405"/>. The syntax also copies the DIGIT and />,
ALPHA rules originally defined in <xref target="RFC5234"/>,
exactly as defined there.</t> exactly as defined there.</t>
<t>The device identifier namespace includes five subtypes (see
<t>The device identifier namespace includes five subtypes (see <xref target="subtypes" format="default"/>), and more may be defined in t
<xref target="subtypes"/>, and more may be defined in the future as he future as
specified in <xref target="iana"/>.</t> specified in <xref target="iana" format="default"/>.</t>
<t>The optional underscore-separated components at the end of
<t>The optional underscore-separated components at the end of
the DEV URN depict individual aspects of a the DEV URN depict individual aspects of a
device. The specific strings and their semantics are up to the device. The specific strings and their semantics are up to the
designers of the device, but could be used to refer to designers of the device but could be used to refer to
specific interfaces or functions within the device.</t> specific interfaces or functions within the device.</t>
<t>With the exception of the MAC address and 1-Wire DEV URNs,
<t>With the exception of the MAC-address and 1-Wire DEV URNs,
each DEV URN may also contain optional colon-separated each DEV URN may also contain optional colon-separated
identifiers. These are provided for extensibility.</t> identifiers. These are provided for extensibility.</t>
<t>There are no special character encoding rules or
<t>There are no special character encoding rules or considerations for conforming with the URN syntax beyond
considerations for conforming with the URN syntax, beyond those applicable for URNs in general <xref target="RFC8141" format="defau
those applicable for URNs in general <xref target="RFC8141"/>, lt"/>
or the context where these URNs are carried (e.g., inside JSON or the context where these URNs are carried (e.g., inside JSON
<xref target="RFC8259"/> or SenML <xref <xref target="RFC8259" format="default"/> or SenML <xref target="RFC8428"
target="RFC8428"/>). Due to the SenML RFC 8428 Section 4.5.1 format="default"/>). Due to the SenML rules in <xref target="RFC8428" sectionFo
rules, it is not desirable to use percent-encoding in DEV rmat="comma" section="4.5.1"/>, it is not desirable to use percent-encoding in D
EV
URNs, and the subtypes defined in this specification do not URNs, and the subtypes defined in this specification do not
really benefit from percent-encoding. However, this really benefit from percent-encoding. However, this
specification does not deviate from the general syntax of URNs specification does not deviate from the general syntax of URNs
or their processing and normalization rules as specified in or their processing and normalization rules as specified in
<xref target="RFC3986"/> and <xref target="RFC8141"/>.</t> <xref target="RFC3986" format="default"/> and <xref target="RFC8141" form
at="default"/>.</t>
<t>DEV URNs do not use r-, q-, or f-components as defined in <t>DEV URNs do not use r-, q-, or f-components as defined in
<xref target="RFC8141"/>.</t> <xref target="RFC8141" format="default"/>.</t>
<t>Specific subtypes of DEV URNs may be validated through
<t>Specific subtypes of DEV URNs may be validated through mechanisms discussed in <xref target="subtypes" format="default"/>.</t>
mechanisms discussed in <xref target="subtypes"/>.</t> <t>The string representation of the device
<t>The string representation of the device
identifier URN is fully compatible with identifier URN is fully compatible with
the URN syntax.</t> the URN syntax.</t>
<section numbered="true" toc="default">
<section title="Character Case and URN-Equivalence"> <name>Character Case and URN-Equivalence</name>
<t>The DEV URN syntax allows both uppercase and lowercase
<t>The DEV URN syntax allows both upper and lower case
characters. The URN-equivalence of the DEV URNs is defined per characters. The URN-equivalence of the DEV URNs is defined per
<xref target="RFC8141"/> Section 3.1, i.e., two URNs are <xref target="RFC8141" sectionFormat="comma" section="3.1"/>, i.e., two U RNs are
URN-equivalent if their assigned-name portions are URN-equivalent if their assigned-name portions are
octet-by-octet equal after applying case normalization to the octet-by-octet equal after applying case normalization to the
URI scheme ("urn") and namespace identifier ("dev"). URI scheme ("urn") and namespace identifier ("dev").
The rest of the DEV URN is The rest of the DEV URN is
compared in a case sensitive manner. It should be noted that compared in a case-sensitive manner. It should be noted that
URN-equivalence matching merely quickly shows that two URNs URN-equivalence matching merely quickly shows that two URNs
are definitely the same for the purposes of caching and other are definitely the same for the purposes of caching and other
similar uses. Two DEV URNs may still refer to the same entity, similar uses. Two DEV URNs may still refer to the same entity and may not
and not be found URN-equivalent according to the RFC 8141 be found to be URN-equivalent according to the <xref target="RFC8141" format="d
efault"/>
definition. For instance, in ABNF, strings are definition. For instance, in ABNF, strings are
case-insensitive (see <xref target="RFC5234"/> Section 2.3), case insensitive (see <xref target="RFC5234" sectionFormat="comma" sectio n="2.3"/>),
and a MAC address could be represented either with uppercase and a MAC address could be represented either with uppercase
or lowercase hexadecimal digits.</t> or lowercase hexadecimal digits.</t>
<t>Character case is not otherwise significant for the DEV URN
<t>Character case is not otherwise significant for the DEV URN
subtypes defined in this document. However, future subtypes subtypes defined in this document. However, future subtypes
might include identifiers that use encodings such as BASE64, might include identifiers that use encodings such as base64,
which encode strings in a larger variety of characters, and which encodes strings in a larger variety of characters and
might even encode binary data.</t> might even encode binary data.</t>
<t>To facilitate equivalence checks, it is <bcp14>RECOMMENDED</bcp14>
<t>To facilitate equivalence checks, it is RECOMMENDED that that
implementations always use lower case letters where they have implementations always use lowercase letters where they have
a choice in case, unless there is a reason otherwise. (Such a a choice in case, unless there is a reason otherwise. (Such a
reason might be, for instance, the use of a subtype that reason might be, for instance, the use of a subtype that
requires the use of both upper case and lower case requires the use of both uppercase and lowercase
letters.)</t> letters.)</t>
</section> </section>
</section> </section>
<section anchor="assignment" numbered="true" toc="default">
<section anchor="assignment" title="Assignment"> <name>Assignment</name>
<t>The process for identifier
<t>Assignment: The process for identifier assignment is dependent on the used subtype and is documented in the
assignment is dependent on the used subtype, and documented in the specific subsection under <xref target="subtypes" format="default"/>.</t>
specific subsection under <xref target="subtypes"/>.</t> <t>Device identifiers are generally expected to identify a
<t>Device identifiers are generally expected to identify a
unique device, unique device,
barring the accidental issue of multiple devices with the same barring the accidental issue of multiple devices with the same
identifiers. In many cases, device identifiers can also be identifiers. In many cases, device identifiers can also be
changed by users, or sometimes assigned in an algorithmic changed by users or are sometimes assigned in an algorithmic
or local fashion. Any potential conflicts arising from such or local fashion. Any potential conflicts arising from such
assignments are not something that the DEV URNs as such assignments are not something that the DEV URNs as such
manage; they simply are there to refer to a particular manage; they simply are there to refer to a particular
identifier. And of course, a single device may (and often identifier. And, of course, a single device may (and often
does) have multiple identifiers, e.g., identifiers associated does) have multiple identifiers, e.g., identifiers associated
with different link technologies it supports.</t> with different link technologies it supports.</t>
<t>The DEV URN type <bcp14>SHOULD</bcp14> only be used for
<t>The DEV URN type SHOULD only be used for
hardware-based identifiers that are expected to be hardware-based identifiers that are expected to be
persistent (with some limits, as discussed above).</t> persistent (with some limits, as discussed above).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Security and Privacy"> <name>Security and Privacy</name>
<t>As discussed in <xref target="sec" format="default"/>,
<t>Security and Privacy: As discussed in <xref target="sec"/>,
care must be taken in the use of device-identifier-based care must be taken in the use of device-identifier-based
identifiers due to their nature as long-term identifiers that identifiers due to their nature as long-term identifiers that
are not normally changeable. Leakage of these identifiers are not normally changeable. Leakage of these identifiers
outside systems where their use is justified should be outside systems where their use is justified should be
controlled.</t> controlled.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Interoperability"> <name>Interoperability</name>
<t>There are no specific interoperability
<t>Interoperability: There are no specific interoperability
concerns.</t> concerns.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Resolution"> <name>Resolution</name>
<t>The device identifiers are not expected to be globally
<t>Resolution: The device identifiers are not expected to be globally
resolvable. No identifier resolution system is expected. Systems may resolvable. No identifier resolution system is expected. Systems may
perform local matching of identifiers to previously seen identifiers perform local matching of identifiers to previously seen identifiers
or configured information, however.</t> or configured information, however.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Documentation"> <name>Documentation</name>
<t>See RFC 9039.</t>
<t>See RFC NNNN (RFC Editor: Please replace NNNN by a reference to
the RFC number of this document).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Additional Information"> <name>Additional Information</name>
<t>See <xref target="intro" format="default"/> for a discussion of relat
<t>See <xref target="intro"/> for a discussion of related name spaces.</t ed namespaces.</t>
>
</section> </section>
<section numbered="true" toc="default">
<section title="Revision Information"> <name>Revision Information</name>
<t>This is the first version of this registration.</t>
<t>Revision Information: This is the first version of this registration.<
/t>
</section> </section>
</section> </section>
<section anchor="subtypes" numbered="true" toc="default">
<section anchor="subtypes" title="DEV URN Subtypes"> <name>DEV URN Subtypes</name>
<section anchor="mac" numbered="true" toc="default">
<section anchor="mac" title="MAC Addresses"> <name>MAC Addresses</name>
<t>DEV URNs of the "mac" subtype are based on the EUI-64 identifier
<t>DEV URNs of the "mac" subtype are based on the EUI-64 identifier <xref target="IEEE.EUI64" format="default"/> derived from a device with a built-
<xref target="IEEE.EUI64"/> derived from a device with a built-in in
64-bit EUI-64. The EUI-64 is formed from 24 or 36 bits of organization 64-bit EUI-64. 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.</t> identifier assigned by that organization.</t>
<t>In the DEV URN "mac" subtype, the hexstring is simply the full
<t>In the DEV URN "mac" subtype the hexstring is simply the full
EUI-64 identifier represented as a hexadecimal string. It is always EUI-64 identifier represented as a hexadecimal string. It is always
exactly 16 characters long.</t> exactly 16 characters long.</t>
<t>MAC-48 and EUI-48 identifiers are also supported by the same DEV
<t>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
URN subtype. To convert a MAC-48 address to an EUI-64 identifier, The Organizationally Unique Identifier (OUI) of the MAC-48 address (the first three
OUI of the MAC-48 address (the first three octets) becomes the octets) becomes the
organization identifier of the EUI-64 (the first three octets). The organization identifier of the EUI-64 (the first three octets). The
fourth and fifth octets of the EUI are set to the fixed value 0xffff fourth and fifth octets of the EUI are set to the fixed value 0xffff
(hexadecimal). The last three octets of the MAC-48 address become the (hexadecimal). The last three octets of the MAC-48 address become the
last three octets of the EUI-64. The same process is used to convert last three octets of the EUI-64. The same process is used to convert
an EUI-48 identifier, but the fixed value 0xfffe is used instead.</t> an EUI-48 identifier, but the fixed value 0xfffe is used instead.</t>
<t>Identifier assignment for all of these identifiers rests within the
<t>Identifier assignment for all of these identifiers rests within the
IEEE Registration Authority.</t> IEEE Registration Authority.</t>
<t>Note that where randomized MAC addresses are used, the resulting
DEV URNs cannot be expected to have uniqueness, as discussed in <xref target="as
signment" format="default"/>.</t>
</section>
<section anchor="s1wire" numbered="true" toc="default">
<name>1-Wire Device Identifiers</name>
<t>Note that where randomized MAC addresses are used, the resulting <t>The 1-Wire system is a device communications bus system designed
DEV URNs cannot be expected to have uniqueness, as discussed in <xref by Dallas Semiconductor Corporation. (1-Wire is a registered trademark.) 1-Wire
target="assignment"/>.</t> devices are identified by
a 64-bit identifier that consists of an 8-bit family code, a 48-bit
</section> identifier unique within a family, and an 8-bit Cyclic Redundancy Check (CRC) co
de <xref target="OW" format="default"/>.
<section anchor="s1wire" title="1-Wire Device Identifiers">
<t>The 1-Wire* system is a device communications bus system designed
by Dallas Semiconductor Corporation. 1-Wire devices are identified by
a 64-bit identifier that consists of 8 bit family code, 48 bit
identifier unique within a family, and 8 bit CRC code <xref
target="OW"/>.
<list style="empty">
<t>*) 1-Wire is a registered trademark.</t>
</list>
</t> </t>
<t>In DEV URNs with the "ow" subtype the hexstring is a representation <t>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 <bcp14>MAY</bcp14> check the valid ity
of this code.</t> of this code.</t>
<t>Family code and identifier assignment for all 1-Wire devices rests
<t>Family code and identifier assignment for all 1-Wire devices rests
with the manufacturers.</t> with the manufacturers.</t>
</section>
</section> <section anchor="org" numbered="true" toc="default">
<name>Organization-Defined Identifiers</name>
<section anchor="org" title="Organization-Defined Identifiers"> <t>Device identifiers that have only a meaning within an
<t>Device identifiers that have only a meaning within an
organization can also be used to represent vendor-specific or organization can also be used to represent vendor-specific or
experimental identifiers or identifiers designed for use within the experimental identifiers or identifiers designed for use within the
context of an organization.</t> context of an organization.</t>
<t>Organizations are identified by their Private Enterprise Number
<t>Organizations are identified by their Private Enterprise Number (PEN) <xref target="RFC2578" format="default"/>. These numbers can be obtained
(PEN) <xref target="RFC2578"/>. These numbers can be obtained from from
IANA. Current PEN assignments can be viewed at IANA. Current PEN assignments can be viewed at <eref brackets="angle" target=
https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers "https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers"/>,
and new assignments requested at and new assignments are requested at <eref brackets="angle" target="https://pen
https://pen.iana.org/pen/PenApplication.page.</t> .iana.org/pen/PenApplication.page"/>.</t>
<t>Note that when included in an "org" DEV URN, the number cannot
<t>Note that when included in an "org" DEV URN, the number can not
be zero or have leading zeroes, as the ABNF requires the number to be zero or have leading zeroes, as the ABNF requires the number to
start with a non-zero digit.</t> start with a non-zero digit.</t>
</section>
</section> <section anchor="os" numbered="true" toc="default">
<name>Organization Serial Numbers</name>
<section anchor="os" title="Organization Serial Numbers"> <t>The "os" subtype specifies an organization and serial
<t>The "os" subtype specifies an organization and a serial
number. Organizations are identified by their PEN. As with the number. Organizations are identified by their PEN. As with the
organization-defined identifiers (<xref target="org"/>), PEN number organization-defined identifiers (<xref target="org" format="default"/>), PEN number
assignments are maintained by IANA, and assignments for new assignments are maintained by IANA, and assignments for new
organizations can be made easily. organizations can be made easily.
<list style="empty"> </t>
<aside><t>
<t>Historical note: The "os" subtype was originally been defined Historical note: The "os" subtype was originally defined
in the Open Mobile Alliance "Lightweight Machine to Machine" in the Open Mobile Alliance "Lightweight Machine to Machine"
standard <xref target="LwM2M"/>, but has been incorporated here standard <xref target="LwM2M" format="default"/> but has been incorporated
to collect all syntax associated with DEV URNs in one place. At here
to collect all syntaxes associated with DEV URNs in one place. At
the same time, the syntax of this subtype was changed to avoid the same time, the syntax of this subtype was changed to avoid
the possibility of characters that are not allowed in SenML Name the possibility of characters that are not allowed in the SenML Name
field (see <xref target="RFC8428"/> Section 4.5.1).</t> field (see <xref target="RFC8428" sectionFormat="comma" section="4.5.1"/>)
.</t>
</list></t> </aside>
<t>Organization serial number DEV URNs consist of the PEN number and
<t>Organization serial number DEV URNs consist of the PEN number and
the serial number. As with other DEV URNs, for carrying additional the 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.</t> specification does not specify how they are allocated.</t>
<t>Organizations are also encouraged to select serial number formats
<t>Organizations are also encouraged to select serial number formats that avoid the possibility of ambiguity in the form of leading zeroes
that avoid possibility for ambiguity, in the form of leading zeroes
or otherwise.</t> or otherwise.</t>
</section>
</section> <section anchor="ops" numbered="true" toc="default">
<name>Organization Product and Serial Numbers</name>
<section anchor="ops" title="Organization Product and Serial Numbers"> <t>The DEV URN "ops" subtype was originally defined in the
LwM2M standard but has been incorporated here to collect all syntaxes
<t>The DEV URN "ops" subtype has originally been defined in the
LwM2M 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 are identified by their PEN. Again, as with the
organization-defined identifiers (<xref target="org"/>), PEN number organization-defined identifiers (<xref target="org" format="default"/>), PEN number
assignments are maintained by IANA. assignments are maintained by IANA.
</t>
<list style="empty"> <aside><t>
Historical note: As with the "os" subtype, the "ops" subtype
<t>Historical note: As with the "os" subtype, the "ops" subtype was originally defined in the Open Mobile Alliance "Lightweight Machine to M
has originally been defined in OMA.</t> achine" standard <xref target="LwM2M" format="default"/>.
</t></aside>
</list></t> <t>Organization product and serial number DEV URNs consist of the
<t>Organization product and serial number DEV URNs consist of the
PEN number, product class, and the serial number. As with other DEV PEN number, product class, and the serial number. As with other DEV
URNs, for carrying additional information and extensibility, URNs, for carrying additional information and extensibility,
optional colon-separated identifiers and underscore-separated optional colon-separated identifiers and underscore-separated
components may also be included. Both the product class and serial components may also be included. Both the product class and 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.</t> specification does not specify how they are allocated.</t>
<t>Organizations are also encouraged to select product and serial
<t>Organizations are also encouraged to select product and serial
number formats that avoid possibility for ambiguity.</t> number formats that avoid possibility for ambiguity.</t>
</section>
</section> <section anchor="futuresubtypes" numbered="true" toc="default">
<name>Future Subtypes</name>
<section anchor="futuresubtypes" title="Future Subtypes"> <t>Additional subtypes may be defined in future
specifications. See <xref target="iana" format="default"/>.</t>
<t>Additional subtypes may be defined in other, future <t>The DEV URN "example" subtype is reserved for use in examples. It
specifications. See <xref target="iana"/>.</t>
<t>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
<xref target="syntax"/>.</t> <xref target="syntax" format="default"/>.</t>
</section>
</section> </section>
<section anchor="ex" numbered="true" toc="default">
</section> <name>Examples</name>
<t>The following provides some examples of DEV URNs:
<section anchor="ex" title="Examples"> </t>
<table>
<t>The following provides some examples of DEV URNs: <thead>
<tr>
<figure> <th>URN</th>
<artwork> <th>Description</th>
urn:dev:mac:0024beffff804ff1 # The MAC-48 address of </tr>
# 0024be804ff1, converted </thead>
# to EUI-64 format <tbody>
<tr>
urn:dev:mac:0024befffe804ff1 # The EUI-48 address of <td>urn:dev:mac:0024beffff804ff1</td>
# 0024be804ff1, converted <td>The MAC-48 address of 0024be804ff1, converted to EUI-64 format</td>
# to EUI-64 format </tr>
<tr>
urn:dev:mac:acde48234567019f # The EUI-64 address of <td> urn:dev:mac
# acde48234567019f :0024befffe804ff1</td>
<td> The
urn:dev:ow:10e2073a01080063 # A 1-Wire temperature EUI-48 address of 0024be804ff1, converted to EUI-64 format</td>
# sensor </tr>
<tr>
urn:dev:ow:264437f5000000ed_humidity # The humidity <td>urn:dev:mac:acde48234567019f</td>
# part of a multi-sensor <td>The EUI-64 address of acde482
# device 34567019f
</td>
urn:dev:ow:264437f5000000ed_temperature # The temperature </tr>
# part of a multi-sensor <tr> <td>
# device urn:dev:ow:10e2073a01080063</td>
<td>A 1-Wire temperature sensor</td
urn:dev:org:32473-foo # An organization- >
# specific URN in </tr>
# the RFC 5612 example <tr>
# organization, 32473. <td>urn:dev:ow:264437f5000000ed_humidity</td>
<td>The humidity part of a multi-sensor
urn:dev:os:32473-123456 # Device 123456 in device
# the RFC 5612 example </td>
# organization </tr>
<tr>
<td>urn:dev:ow:264437f5000000ed_temperature</td>
<td>The temperature part of a multi-sensor device</td>
</tr>
<tr>
<td>urn:dev:org:32473-foo</td>
<td>An organization-specific URN in the example organization 32473 in <xref ta
rget="RFC5612"/>
</td>
</tr>
urn:dev:os:32473-12-34-56 # A serial number with <tr>
# dashes in it <td>urn:dev:os:32473-123456</td>
<td>Device 123456 in the example organization in <xref target="RFC5612"/></td>
</tr>
urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial <tr>
# number 5002 in the <td>urn:dev:os:32473-12-34-56</td>
# RFC 5612 example <td>A serial number with dashes in it</td>
# organization </tr>
urn:dev:example:new-1-2-3_comp # An example of something <tr>
# that is not defined today, <td>urn:dev:ops:32473-Refrigerator-5002</td>
# and is not one of the <td>Refrigerator serial number 5002 in the example organization in <xref targe
# mac, ow, os, or ops t="RFC5612"/></td>
# subtypes </tr>
</artwork> <tr>
</figure> <td>urn:dev:example:new-1-2-3_comp</td>
</t> <td>An example of something that is not defined today, and is not one of the m
ac, ow, os, or ops subtypes</td>
</tr>
<t>The DEV URNs themselves can then appear in various contexts. A </tbody>
simple example of this is the use of DEV URNs in SenML data. For </table>
example, this example from <xref target="RFC8428"/> shows a <t>The DEV URNs themselves can then appear in various contexts. A
simple example of this is the use of DEV URNs in SenML data. This example from
<xref target="RFC8428" format="default"/> shows a
measurement from a 1-Wire temperature gauge encoded in the JSON measurement from a 1-Wire temperature gauge encoded in the JSON
syntax. syntax:
<figure> </t>
<artwork> <sourcecode name="" type="json"><![CDATA[
[ [
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
] ]
</artwork> ]]></sourcecode>
</figure> </section>
</t> <section anchor="sec" numbered="true" toc="default">
<name>Security Considerations</name>
</section> <t>On most devices, the user can display device identifiers. Depending
<section anchor="sec" title="Security Considerations">
<t>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 preserve tampered with by the user. An implementation of the DEV URN <bcp14>MUST</bcp14> preserve
such limitations and behaviors associated with the device identifiers. In partic ular, such limitations and behaviors associated with the device identifiers. In partic ular,
a device identifier that is intended to be immutable should not become mutable a device identifier that is intended to be immutable should not become mutable
as a part of implementing the DEV URN type. More generally, nothing in as a part of implementing the DEV URN type. More generally, nothing in
this document should be construed to override what the relevant device this document should be construed to override what the relevant device
specifications have already said about the identifiers.</t> specifications have already said about the identifiers.</t>
<section anchor="priv" numbered="true" toc="default">
<section anchor="priv" title="Privacy"> <name>Privacy</name>
<t>Other devices in the same network may or may not be able to
<t>Other devices in the same network may or may not be able to
identify the device. For instance, on an Ethernet network, the MAC identify the device. For instance, on an Ethernet network, the MAC
address of a device is visible to all other devices.</t> address of a device is visible to all other devices.</t>
<t>DEV URNs often represent long-term stable unique identifiers for
<t>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 vulner
specific vulnerability exploitation <xref target="RFC7721"/>. Also, in ability exploitation <xref target="RFC7721" format="default"/>. Also, in
some systems there is no easy way to change the identifier. Therefore some systems, there is no easy way to change the identifier. Therefore,
these identifiers need to be used with care and especially care should these identifiers need to be used with care, and special care should
be taken to avoid leaking them outside of the system that is intended be taken to avoid leaking identifiers outside of the system that is intended
to use the identifiers.</t> to use them.</t>
</section>
</section> <section anchor="valid" numbered="true" toc="default">
<name>Validity</name>
<section anchor="valid" title="Validity"> <t>Information about identifiers may have significant effects in some
applications. For instance, in many sensor systems, the identifier
<t>Information about identifiers may have significant effects in some
applications. For instance, in many sensor systems the identifier
information is used for deciding how to use the data carried in a information is used for deciding how to use the data carried in a
measurement report. On some other systems, identifiers may be used in measurement report. In some other systems, identifiers may be used in
policy decisions.</t> policy decisions.</t>
<t>It is important that systems be designed to take into account the
<t>It is important that systems are 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 communications by illegitimate entities. Integrity
protection of communications or data objects, the use of trusted protection of communications or data objects, the use of trusted
devices, and various management practices can help address these devices, and various management practices can help address these
issues. </t> issues. </t>
<t>Similar to the advice in <xref target="RFC4122" sectionFormat="comma"
<t>The advice from <xref target="RFC4122"/> Section 6 also applies: section="6"/>:
Do not assume that DEV URNs are hard to guess.</t> Do not assume that DEV URNs are hard to guess.</t>
</section>
</section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>Per this document, IANA has registered a new URN namespace
for "dev", as described in <xref target="devurn" format="default"/>.</t>
</section> <t>IANA has created a "DEV URN Subtypes" registry under "Device Identifica
tion". The initial values in this registry are as follows:
</section> </t>
<table>
<section anchor="iana" title="IANA Considerations"> <thead>
<tr>
<t>This document requests the registration of a new URN namespace <th>Subtype</th>
for "DEV", as described in <xref target="devurn"/>.</t> <th>Description</th>
<th>Reference</th>
<t>IANA is asked to create a "DEV URN Subtypes" registry. The initial values </tr>
in this registry are as follows: </thead>
<tbody>
<figure> <tr>
<artwork> <td>mac</td>
Subtype Description Reference <td>MAC Addresses</td>
mac MAC Addresses (THIS RFC) Section 4.1 <td>RFC 9039, <xref target="mac"/></td>
ow 1-Wire Device Identifiers (THIS RFC) Section 4.2 </tr>
org Organization-Defined Identifiers (THIS RFC) Section 4.3 <tr>
os Organization Serial Numbers (THIS RFC) Section 4.4 <td>ow</td>
ops Organization Product and Serial Numbers (THIS RFC) Section 4.5 <td>1-Wire Device Identifiers</td>
example Reserved for examples (THIS RFC) Section 4.6 <td>RFC 9039, <xref target="s1wire"/></td>
</artwork> </tr>
</figure></t> <tr>
<td>org</td>
<t>Additional subtypes for DEV URNs can be defined through <td>Organization-Defined Identifiers</td>
Specification Required or IESG Approval <xref <td>RFC 9039, <xref target="org"/></td>
target="RFC8126"/>. These allocations are appropriate when there is </tr>
a new namespace of some type of device identifiers, defined in <tr>
stable fashion and with a publicly available specification.</t> <td>os</td>
<td>Organization Serial Numbers</td>
<t>Note that the organization (<xref target="org"/>) device <td>RFC 9039, <xref target="os"/></td>
</tr>
<tr>
<td>ops</td>
<td>Organization Product and Serial Numbers</td>
<td>RFC 9039, <xref target="ops"/></td>
</tr>
<tr>
<td>example</td>
<td>Reserved for examples</td>
<td>RFC 9039, <xref target="futuresubtypes"/></td>
</tr>
</tbody>
</table>
<t>Additional subtypes for DEV URNs can be defined through
Specification Required or IESG Approval <xref target="RFC8126" format="default
"/>. These allocations are appropriate when there is
a new namespace of some type of device identifier that is defined in
a stable fashion and has a publicly available specification.</t>
<t>Note that the organization (<xref target="org" format="default"/>) devi
ce
identifiers can also be used in some cases, at least as a temporary identifiers can also be used in some cases, at least as a temporary
measure. It is preferable, however, that long-term usage of a measure. It is preferable, however, that long-term usage of a
broadly employed device identifier be registered with IETF rather broadly employed device identifier be registered with IETF rather
than used through the organization device identifier type.</t> than used through the organization device identifier type.</t>
</section>
</middle>
<back>
</section> <displayreference target="I-D.ietf-core-resource-directory" to="CoRE-RD"/>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2578;
&RFC3986;
&RFC5234;
&RFC8126;
&RFC8141;
&RFC8174;
<reference
anchor="IEEE.EUI64"
target="https://standards.ieee.org/content/dam/ieee-standards/standards/we
b/documents/tutorials/eui.pdf">
<front>
<title>Guidelines For 64-bit Global Identifier (EUI-64)</title>
<author>
<organization>IEEE</organization>
</author>
<date year='unknown year' />
</front>
<seriesInfo name="IEEE" value=" " />
</reference>
<reference
anchor="OW"
target="https://www.maximintegrated.com/en/design/technical-documents/tuto
rials/1/1796.html">
<front>
<title>Guide to 1-Wire Communication</title>
<author>
<organization>Maxim</organization>
</author>
<date month='June' year='2008' />
</front>
<seriesInfo name="MAXIM" value=" https://www.maximintegrated.com/en/design/t
echnical-documents/tutorials/1/1796.html" />
</reference>
</references>
<references title="Informative References">
&RFC3261;
&RFC4122;
&RFC4648;
&RFC7230;
&RFC7540;
&RFC7721;
&RFC8259;
<reference anchor='W3C.REC-xml-19980210'
target='http://www.w3.org/TR/1998/REC-xml-19980210'>
<front>
<title>XML 1.0 Recommendation</title>
<author initials='C.' surname='Sperberg-McQueen' fullname='C. M. Sperberg-
McQueen'>
<organization />
</author>
<author initials='T.' surname='Bray' fullname='Tim Bray'>
<organization />
</author>
<author initials='J.' surname='Paoli' fullname='Jean Paoli'>
<organization />
</author>
<date month='February' day='10' year='1998' />
</front>
<seriesInfo name='World Wide Web Consortium FirstEdition' value='REC-xml-199
80210' />
<format type='HTML' target='http://www.w3.org/TR/1998/REC-xml-19980210' />
</reference>
<reference anchor='OUI'
target='http://standards.ieee.org/develop/regauth/oui/'>
<front>
<title>Registration Authority</title>
<author initials="SA" surname="IEEE" fullname='IEEE-SA'>
<organization />
</author>
<date year='2018' />
</front>
<seriesInfo name='IEEE-SA' value='webpage'/>
<format type='HTML' target='http://standards.ieee.org/develop/regauth/oui/'
/>
</reference>
&RFC7252;
&RFC8428;
&RFC6920;
&RFC7254;
&RFC7405;
&RFC8464;
&I-D.ietf-core-resource-directory;
<reference anchor="LwM2M">
<front>
<title>OMA Lightweight Machine to Machine Requirements</title>
<author fullname="Open Mobile Alliance"></author>
<date year='2019' month='January'/>
</front>
<seriesInfo name="OMA Standard" value="Candidate Version 1.2"/>
<format type='HTML' target='http://www.openmobilealliance.org/wp/Overviews/lig
htweightm2m_overview.html' />
</reference>
</references>
<section title="Changes from Previous Versions">
<t>Editor's note: Please remove this section before publication.</t>
<t>Version -11 was created to address non-blocking comments from the
IESG review. This version made the following changes:
<list style="symbols">
<t>Removed space after the "%s" in the ABNF RFC 7405
syntax.</t>
<t>Softened and clarified the recommendation regarding UUIDs
in <xref target="intro"/>.</t>
<t>Added a paragraph about the impacts of using randomized
MAC addresses.</t>
<t>Added advice regarding ease of guessing DEV URNs, in <xref target="va
lid"/>.</t>
<t>Simplified and clarified the "illegitimate entities" statement in <xr
ef target="valid"/>.</t>
<t>Clarified the persistence statement in <xref target="assignment"/>.</
t>
</list></t>
<t>Version -10 made the following changes:
<list style="symbols">
<t>Restricted the case of "mac", "ow", etc. any subtype to lower
case. This required the adoption of RFC 7405 syntax in the
ABNF.</t>
<t>Added a reserved "example" subtype to be used in examples.</t>
<t>Clarified global applicability, particularly in cases with
local or manual assignment mechanisms.</t>
<t>Corrected byte/bit counts in for 1-Wire identifiers in <xref target="s1wi
re"/>.</t>
<t>Clarified that optional underscore-separated components come
at the end of the DEV URN, not just "after the hexstring".</t>
<t>Changed the requirement to not use percent-encoding to a preference inste
ad of a hard rule, based on the needs of SenML but not wishing to break rules of
RFC 8141.</t>
<t>Added a description of tradeoffs involving using URNs instead of some mor
e compact but more specific formats, in <xref target="intro"/>.</t>
<t>Several minor corrections to the names in the ABNF.</t>
<t>Added a reference for Base64 for clarity.</t>
<t>Made the history of the OS and OPS subtypes a part of the permanent text,
rather than an editor's note.</t>
<t>Updated the 1-Wire reference URL.</t>
<t>Some editorial corrections.</t>
</list></t>
<t>Version -09 of the WG draft took into account IANA, SECDIR,
Gen-ART, and OPSDIR reviews. The following changes were made:
<list style="symbols">
<t>Aligned the use of identifiers vs. identity terms.</t>
<t>Added a security considerations subsection on validity of
claimed identifiers.</t>
<t>Focused on "care" in the RFC 7721 reference, rather than "care
and avoidance".</t>
<t>Renamed the "unreserved" ABNF terminal to avoid confusion with
the general URN ABNF terminal with the same name.</t>
<t>Removed the mistakenly included text about MEID subtype.</t>
<t>Clarified URN syntax differences and normalization rules wrt
the lack of percent-encoding in DEV URNs.</t>
<t>Required PEN numbers to start with non-zero digit in the ABNF
and changed the associated language later in the draft.</t>
<t>Text about case-insensitivity in RFC 5234 was clarified.</t>
<t>Text about uniqueness was clarified.</t>
<t>Text about global scope was clarified.</t>
<t>An example of DEV URN usage in SenML was added.</t>
<t>Editorial changes.</t>
</list>
</t>
<t>Version -08 of the WG draft took into account Barry Leiba's AD
review comments. To address these comments, changes were made in
<list style="symbols">
<t>Further updates of the upper/lower case rules for the DEV URNs.</t>
<t>Further updates to the ABNF.</t>
<t>The use of HEXDIG from RFC 5234.</t>
<t>IANA considerations for the creation of separate registry for the own par
ameters of DEV URNs.</t>
<t>Editorial improvements.</t>
</list></t>
<t>Version -07 of the WG draft took into account Carsten Bormann's
feedback, primarily on character case issues and editorials.</t>
<t>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.</t>
<t>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.</t>
<t>Version -04 of the WG draft cleaned up the ABNF:
<list style="symbols">
<t>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.</t>
<t>The syntax was also
extended to allow for extensibility by adding additional ":"
separated parts for the org, op, ops, and other subtypes.</t>
<t>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.)</t>
</list></t>
<t>In addition, in -04 the MAC example was corrected to use the
inserted value ffff instead of fffe, required by <xref
target="mac"/>, 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.</t>
<t>Version -03 of the WG draft removed some unnecessary references,
updated some other references, removed pct-encoding to ensure the
DEV URNs fit <xref target="RFC8428"/> Section 4.5.1 rules, and
clarified that the original source of the "os" and "ops"
subtypes.</t>
<t>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:
<list style="symbols">
<t>The syntax for the "org:" changes to use "-" rather than ":"
between the OUI and the rest of the URN.</t>
<t>The organizations for the "ops" and "os" branches have been
changed to use PEN numbers rather than OUI numbers <xref
target="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.</t>
<t>There were also changes to what general characters can be used <references>
in the otherbody branch of the ABNF.</t> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2578.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3986.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8141.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</list></t> <reference anchor="IEEE.EUI64"
target="https://standards.ieee.org/content/dam/ieee-standards/standards/web/docu
ments/tutorials/eui.pdf">
<front>
<title>Guidelines for Use of Extended Unique Identifier (EUI), Organizationally
Unique Identifier (OUI), and Company ID (CID)</title>
<author>
<organization>IEEE</organization>
</author>
<date month="August" year="2017"/>
</front>
</reference>
<t>The rationale for all these changes is that it would be helpful <reference anchor="OW" target="https://www.maximintegrated.com/en/design
for the community collect and unify syntax between the different /technical-documents/tutorials/1/1796.html">
uses of DEV URNs. If there is significant use of either the org:, <front>
os:, or ops: subtypes, then changes at this point may not be <title>Guide to 1-Wire Communication</title>
warranted, but otherwise unified syntax, as well as the use of PEN <author>
numbers would probably be beneficial. Comments on this topic are <organization>Maxim</organization>
appreciated.</t> </author>
<date month="June" year="2008"/>
</front>
</reference>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3261.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4122.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5612.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7230.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7540.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7721.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8259.xml"/>
<t>Version -01 of the WG draft converted the draft to use the new <reference anchor="W3C.REC-xml-19980210" target="http://www.w3.org/TR/19
URN registration template from <xref target="RFC8141"/>.</t> 98/REC-xml-19980210">
<front>
<title>Extensible Markup Language (XML) 1.0</title>
<author initials="C." surname="Sperberg-McQueen" fullname="C. M. Spe
rberg-McQueen">
<organization/>
</author>
<author initials="T." surname="Bray" fullname="Tim Bray">
<organization/>
</author>
<author initials="J." surname="Paoli" fullname="Jean Paoli">
<organization/>
</author>
<date month="February" year="1998"/>
</front>
<seriesInfo name="W3C" value="Recommendation"/>
</reference>
<t>Version -00 of the WG draft renamed the file name and fixed the <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
ABNF to correctly use "org:" rather than "dn:".</t> C.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8428.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6920.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7254.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7405.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8464.xml"/>
<t>Version -05 made a change to the delimiter for parameters within <!-- [draft-ietf-core-resource-directory] MISSREF state -->
a DEV URN. Given discussions on allowed character sets in SenML <reference anchor='I-D.ietf-core-resource-directory'>
<xref target="RFC8428"/>, we would like to suggest that <front>
the "_" character be used instead of ";", to avoid the need to <title>CoRE Resource Directory</title>
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.</t>
<t>Version -05 also introduced local or organization-specific device <author initials='C' surname='Amsüss' fullname='Christian Amsüss' role="editor">
identifiers. Organizations are identified by their PEN number <organization />
(although we considered FQDNs as a potential alternative. The </author>
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.</t>
<t>Version -05 also added some discussion of privacy concerns around <author initials='Z' surname='Shelby' fullname='Zach Shelby'>
long-term stable identifiers.</t> <organization />
</author>
<t>Finally, version -05 clarified the situations when new <author initials='M' surname='Koster' fullname='Michael Koster'>
allocations within the registry of possible device identifier <organization />
subtypes is appropriate.</t> </author>
<t>Version -04 is a refresh, as the need and interest for this <author initials='C' surname='Bormann' fullname='Carsten Bormann'>
specification has re-emerged. And the editing author has emerged <organization />
back to actual engineering from the depths of IETF </author>
administration.</t>
<t>Version -02 introduced several changes. The biggest change is <author initials='P' surname='van der Stok' fullname='Peter van der Stok'>
that with the NI URNs <xref target="RFC6920"/>, it was no longer <organization />
necessary to define cryptographic identifiers in this </author>
specification. Another change was that we incorporated a more <date month="March" day="7" year="2021"/>
generic syntax for future extensions; 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
<xref target="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 <xref target="RFC3986"/>.</t>
<t>Version -03 made several minor corrections to the ABNF as well as </front>
some editorial corrections.</t>
</section> <seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-28' />
<section title="Acknowledgments"> </reference>
<t>The authors would like to thank Ari Keranen, Stephen Farrell, <reference anchor="LwM2M" target="https://www.openmobilealliance.org/rel
Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime ease/LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-V1_2-20190124-C.pdf">
Jimenez, Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes <front>
Tschofenig, Jim Schaad, Thomas Fossati, Carsten Bormann, Marco <title>OMA Lightweight Machine to Machine Requirements</title>
Tiloca, Barry Leiba, Amanda Baber, Juha Hakala, Dale Worley, Warren <author fullname="Open Mobile Alliance"/>
Kumari, Benjamin Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ <date year="2019" month="January"/>
Housley, Dan Romascanu, Eric Vyncke, Roman Danyliw, and Ahmad </front>
Muhanna for feedback and interesting discussions in this problem <seriesInfo name="OMA Standard" value="Candidate Version 1.2"/>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to thank <contact fullname="Ari Keränen"/>, <con
tact fullname="Stephen Farrell"/>,
<contact fullname="Christer Holmberg"/>, <contact fullname="Peter Saint-Andre"
/>, <contact fullname="Wouter Cloetens"/>, <contact fullname="Jaime
Jimenez"/>, <contact fullname="Joseph Knapp"/>, <contact fullname="Padmakumar
Subramani"/>, <contact fullname="Mert Ocak"/>, <contact fullname="Hannes
Tschofenig"/>, <contact fullname="Jim Schaad"/>, <contact fullname="Thomas Fos
sati"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Marco
Tiloca"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Amanda Baber"
/>, <contact fullname="Juha Hakala"/>, <contact fullname="Dale Worley"/>, <conta
ct fullname="Warren
Kumari"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Brian Weis
"/>, <contact fullname="John Klensin"/>, <contact fullname="Dave Thaler"/>, <con
tact fullname="Russ
Housley"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="Éric Vynck
e"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Ahmad
Muhanna"/> for their feedback and interesting discussions in this problem
space. We would also like to note prior documents that focused on space. We would also like to note prior documents that focused on
specific device identifiers, such as <xref target="RFC7254"/> or specific device identifiers, such as <xref target="RFC7254" format="default"/>
<xref target="RFC8464"/>.</t> and
<xref target="RFC8464" format="default"/>.</t>
</section> </section>
</back>
</back>
</rfc> </rfc>
 End of changes. 125 change blocks. 
893 lines changed or deleted 632 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/