<?xml version="1.0"encoding="iso-8859-1" ?>encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!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"> ]>"rfc2629-xhtml.ent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" 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"?>number="9039" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.5.0 --> <front> <title abbrev="DEV URN">Uniform Resource Names for Device Identifiers</title> <seriesInfo name="RFC" value="9039"/> <authorinitials="J"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"> <organization>Cisco</organization> <address> <postal> <street>170 West Tasman Drive</street> <city>San Jose</city> <region>CA</region> <code>95134</code><country>USA</country><country>United States of America</country> </postal> <phone>+1 408 421-9990</phone><email>fluffy@cisco.com</email><email>fluffy@iii.ca</email> </address> </author> <authorinitials="Z"initials="Z." surname="Shelby" fullname="Zach Shelby"> <organization>ARMEdge Impulse </organization> <address> <postal><street>Kidekuja 2</street> <city>Vuokatti</city> <code>88600</code> <country>FINLAND</country><street>3031 Tisch Way</street> <city>San Jose</city> <region>CA</region> <code>95128</code> <country>United States of America</country> </postal><phone>+358407796297</phone> <email>Zach.Shelby@arm.com</email><email>zach@edgeimpulse.com</email> </address> </author> <datemonth="February" year="2021" />month="June" year="2021"/> <keyword>URN</keyword> <keyword>device identifier</keyword> <keyword>IMEI</keyword> <keyword>1-Wire</keyword> <keyword>MAC address</keyword> <keyword>EUI-48</keyword> <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 identity can be useful in many applications, such as in sensor data streams andstorage,storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information.</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>This document describes a new Uniform Resource Name (URN) <xreftarget="RFC8141"/>target="RFC8141" format="default"/> namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage<xref target="RFC8428"/>,or in equipment inventories <xreftarget="RFC7252"/>,target="RFC7252" format="default"/> <xreftarget="I-D.ietf-core-resource-directory"/>.</t>target="RFC8428" format="default"/> <xref target="I-D.ietf-core-resource-directory" format="default"/>.</t> <t>A URN-based representation can be passed along in applications that need the information. It fits particularly well for protocols mechanisms that are designed to carry URNs <xreftarget="RFC7230"/>,target="RFC7230" format="default"/> <xreftarget="RFC7540"/>,target="RFC7540" format="default"/> <xreftarget="RFC3261"/>,target="RFC3261" format="default"/> <xreftarget="RFC7252"/>.target="RFC7252" format="default"/>. Finally, URNs can also be easily carried and stored in formats such as XML <xreftarget="W3C.REC-xml-19980210"/>,target="W3C.REC-xml-19980210" format="default"/>, JSON <xreftarget="RFC8259"/>target="RFC8259" format="default"/>, or SenML <xreftarget="RFC8428"/>.target="RFC8428" format="default"/>. Using URNs in these formats is often preferable as they are universally recognized andself-describing,self-describing and therefore avoid the needfor agreeingto agree to interpret an octet string as a specific form of aMACMedia Access Control (MAC) address, for instance. Passing URNs may consume additional bytes compared to, for instance, passing 4-byte binary IPv4 addresses, but the former offers some flexibility in return.</t> <t>This document defines identifier URN types for situations where no such convenient type already exists. For instance, <xreftarget="RFC6920"/>target="RFC6920" format="default"/> defines cryptographic identifiers, <xreftarget="RFC7254"/>target="RFC7254" format="default"/> defines International Mobile station Equipment Identity (IMEI) identifiers for use with 3GPP cellular systems, and <xreftarget="RFC8464"/>target="RFC8464" format="default"/> defines Mobile Equipment Identity (MEID) identifiers for use with 3GPP2 cellular systems. Those URN types should be employed when such identifiers are transported; this document does not redefine these identifiers in any way.</t> <t>Universally UniqueIDentifierIdentifier (UUID) URNs <xreftarget="RFC4122"/>target="RFC4122" format="default"/> are another alternative wayfor representingto represent deviceidentifiers,identifiers and already support MAC addresses as one type ofanidentifier. However, UUIDs can be inconvenient in environments where it is important that the identifiersarebe as simple as possible and where additional requirements on stable storage, real-time clocks, and identifier length can be prohibitive. Often, UUID-based identifiers are preferred for general purpose uses instead of the MAC-based device URNs defined in this document. The device URNs are recommended for constrained environments.</t> <t>Future device identifier types can extend the device URN type definedherein this document (see <xreftarget="iana"/>),target="iana" format="default"/>), or they can define their own URNs.</t> <t>Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care as described in <xreftarget="RFC7721"/>.</t>target="RFC7721" format="default"/>.</t> <t>The rest of this document is organized as follows. <xreftarget="devurn"/>target="devurn" format="default"/> defines the "DEV" URN type, and <xreftarget="subtypes"/>target="subtypes" format="default"/> defines subtypes for IEEE MAC-48, EUI-48 and EUI-64addressesaddresses, and 1-Wire device identifiers. <xreftarget="ex"/>target="ex" format="default"/> gives examples. <xreftarget="sec"/>target="sec" format="default"/> discusses the security and privacy considerations of the new URN type. Finally, <xreftarget="iana"/>target="iana" format="default"/> specifies the IANA registration for the new URN type and sets requirements for subtype allocations within this type.</t> </section> <section anchor="kwd"title='Requirements language'> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <section anchor="devurn"title="DEV URN Definition"> <t>Namespace Identifier: "dev" requested</t> <t>Version: 1</t> <t>Date: 2020-06-24</t> <t>Registrant: IETFnumbered="true" toc="default"> <name>DEV URN Definition</name> <dl> <dt>Namespace Identifier:</dt><dd>"dev"</dd> <dt>Version:</dt><dd>1</dd> <dt>Date:</dt><dd>2020-06-24</dd> <dt>Registrant:</dt><dd>IETF and the COREworking group.Working Group. Should the working group cease to exist, discussion should be directed to theapplication areaApplications and Real-Time Area or general IETF discussion forums, or theIESG.</t>IESG.</dd></dl> <sectiontitle="Purpose"> <t>Purpose: Thenumbered="true" toc="default"> <name>Purpose</name> <t>The DEV URNs identify devices with device-specific identifiers such as network card hardware addresses. DEV URNs are scoped to be globally applicable (see <xreftarget="RFC8141"/> Section 6.4.1)target="RFC8141" sectionFormat="comma" section="6.4.1"/>) and, in general, enable systems to use these identifiers from multiple sources in an interoperable manner. Note that in some deployments, ensuring uniqueness requires care if manual or local assignment mechanisms are used, as discussed in <xreftarget="assignment"/>. <vspace blankLines="1"/>target="assignment" format="default"/>. </t> <t> Some typical DEV URN applications include equipment inventories and smart objectsystems.<vspace blankLines="1"/>systems. </t> <t> DEV URNs can be used in various ways in applications, software systems, and network components, in tasks ranging from discovery (forinstanceinstance, when discovering 1-Wire network devices or detecting MAC-addressable devices on a LAN) to intrusion detection systems and simple catalogues of systeminformation.<vspace blankLines="1"/>information. </t> <t> While it is possible to implement resolution systems for specific applications or network locations, DEV URNs are typically not used in a way that requires resolution beyond direct observation of the relevant identifier fields in local link communication. However, it is often useful to be able to pass device identifier information in generic URN fields in databases or protocol fields, which makes the use of URNs for this purposeconvenient.<vspace blankLines="1"/>convenient. </t> <t> The DEV URNname spacenamespace complements existingname spacesnamespaces such as those involving IMEI or UUID identifiers. DEV URNs are expected to be a part of the IETF-provided basic URN types, covering identifiers that have previously not been possible to use inURNs.</t>URNs. </t> </section> <section anchor="syntax"title="Syntax"> <t>Syntax: Thenumbered="true" toc="default"> <name>Syntax</name> <t>The identifier is expressed in ASCII characters and has a hierarchical structure as follows:</t><figure> <artwork><sourcecode name="" type="abnf"><![CDATA[ devurn = "urn:dev:" body componentpart body = macbody / owbody / orgbody / osbody / opsbody / otherbody macbody = %s"mac:" hexstring owbody = %s"ow:" hexstring orgbody = %s"org:" posnumber "-" identifier *( ":" identifier ) osbody = %s"os:" posnumber "-" serial *( ":" identifier ) opsbody = %s"ops:" posnumber "-" product "-" serial *( ":" identifier ) otherbody = subtype ":" identifier *( ":" identifier ) subtype = LALPHA *(DIGIT / LALPHA) identifier = 1*devunreserved identifiernodash = 1*devunreservednodash product = identifiernodash serial = identifier componentpart = *( "_" identifier ) devunreservednodash = ALPHA / DIGIT / "." devunreserved = devunreservednodash / "-" hexstring = 1*(hexdigit hexdigit) hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" posnumber = NZDIGIT *DIGIT ALPHA = %x41-5A / %x61-7A LALPHA = %x41-5A NZDIGIT = %x31-39 DIGIT = %x30-39</artwork> </figure>]]></sourcecode> <t>The above syntax is represented in Augmented Backus-Naur Form (ABNF)formas defined in <xreftarget="RFC5234"/>target="RFC5234" format="default"/> and <xreftarget="RFC7405"/>.target="RFC7405" format="default"/>. The syntax also copies the DIGIT and ALPHA rules originally defined in <xreftarget="RFC5234"/>,target="RFC5234" format="default"/>, exactly as defined there.</t> <t>The device identifier namespace includes five subtypes (see <xreftarget="subtypes"/>,target="subtypes" format="default"/>), and more may be defined in the future as specified in <xreftarget="iana"/>.</t>target="iana" format="default"/>.</t> <t>The optional underscore-separated components at the end of the DEV URN depict individual aspects of a device. The specific strings and their semantics are up to the designers of thedevice,device but could be used to refer to specific interfaces or functions within the device.</t> <t>With the exception of theMAC-addressMAC address and 1-Wire DEV URNs, each DEV URN may also contain optional colon-separated identifiers. These are provided for extensibility.</t> <t>There are no special character encoding rules or considerations for conforming with the URNsyntax,syntax beyond those applicable for URNs in general <xreftarget="RFC8141"/>,target="RFC8141" format="default"/> or the context where these URNs are carried (e.g., inside JSON <xreftarget="RFC8259"/>target="RFC8259" format="default"/> or SenML <xreftarget="RFC8428"/>).target="RFC8428" format="default"/>). Due to the SenMLRFC 8428 Section 4.5.1 rules,rules in <xref target="RFC8428" sectionFormat="comma" section="4.5.1"/>, it is not desirable to use percent-encoding in DEV URNs, and the subtypes defined in this specification do not really benefit from percent-encoding. However, this specification does not deviate from the general syntax of URNs or their processing and normalization rules as specified in <xreftarget="RFC3986"/>target="RFC3986" format="default"/> and <xreftarget="RFC8141"/>.</t>target="RFC8141" format="default"/>.</t> <t>DEV URNs do not use r-, q-, or f-components as defined in <xreftarget="RFC8141"/>.</t>target="RFC8141" format="default"/>.</t> <t>Specific subtypes of DEV URNs may be validated through mechanisms discussed in <xreftarget="subtypes"/>.</t>target="subtypes" format="default"/>.</t> <t>The string representation of the device identifier URN is fully compatible with the URN syntax.</t> <sectiontitle="Characternumbered="true" toc="default"> <name>Character Case andURN-Equivalence">URN-Equivalence</name> <t>The DEV URN syntax allows bothupperuppercase andlower caselowercase characters. The URN-equivalence of the DEV URNs is defined per <xreftarget="RFC8141"/> Section 3.1,target="RFC8141" sectionFormat="comma" section="3.1"/>, i.e., two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after applying case normalization to the URI scheme ("urn") and namespace identifier ("dev"). The rest of the DEV URN is compared in acase sensitivecase-sensitive manner. It should be noted that URN-equivalence matching merely quickly shows that two URNs are definitely the same for the purposes of caching and other similar uses. Two DEV URNs may still refer to the sameentity,entity and may not be found to be URN-equivalent according to theRFC 8141<xref target="RFC8141" format="default"/> definition. For instance, in ABNF, strings arecase-insensitivecase insensitive (see <xreftarget="RFC5234"/> Section 2.3),target="RFC5234" sectionFormat="comma" section="2.3"/>), and a MAC address could be represented either with uppercase or lowercase hexadecimal digits.</t> <t>Character case is not otherwise significant for the DEV URN subtypes defined in this document. However, future subtypes might include identifiers that use encodings such asBASE64,base64, whichencodeencodes strings in a larger variety ofcharacters,characters and might even encode binary data.</t> <t>To facilitate equivalence checks, it isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that implementations always uselower caselowercase letters where they have a choice in case, unless there is a reason otherwise. (Such a reason might be, for instance, the use of a subtype that requires the use of bothupper caseuppercase andlower caselowercase letters.)</t> </section> </section> <section anchor="assignment"title="Assignment"> <t>Assignment: Thenumbered="true" toc="default"> <name>Assignment</name> <t>The process for identifier assignment is dependent on the usedsubtype,subtype and is documented in the specific subsection under <xreftarget="subtypes"/>.</t>target="subtypes" format="default"/>.</t> <t>Device identifiers are generally expected to identify a unique device, barring the accidental issue of multiple devices with the same identifiers. In many cases, device identifiers can also be changed byusers,users or are sometimes assigned in an algorithmic or local fashion. Any potential conflicts arising from such assignments are not something that the DEV URNs as such manage; they simply are there to refer to a particular identifier.AndAnd, of course, a single device may (and often does) have multiple identifiers, e.g., identifiers associated with different link technologies it supports.</t> <t>The DEV URN typeSHOULD<bcp14>SHOULD</bcp14> only be used for hardware-based identifiers that are expected to be persistent (with some limits, as discussed above).</t> </section> <sectiontitle="Security and Privacy"> <t>Securitynumbered="true" toc="default"> <name>Security andPrivacy: AsPrivacy</name> <t>As discussed in <xreftarget="sec"/>,target="sec" format="default"/>, care must be taken in the use of device-identifier-based identifiers due to their nature as long-term identifiers that are not normally changeable. Leakage of these identifiers outside systems where their use is justified should be controlled.</t> </section> <sectiontitle="Interoperability"> <t>Interoperability: Therenumbered="true" toc="default"> <name>Interoperability</name> <t>There are no specific interoperability concerns.</t> </section> <sectiontitle="Resolution"> <t>Resolution: Thenumbered="true" toc="default"> <name>Resolution</name> <t>The device identifiers are not expected to be globally resolvable. No identifier resolution system is expected. Systems may perform local matching of identifiers to previously seen identifiers or configured information, however.</t> </section> <sectiontitle="Documentation">numbered="true" toc="default"> <name>Documentation</name> <t>See RFCNNNN (RFC Editor: Please replace NNNN by a reference to the RFC number of this document).</t>9039.</t> </section> <sectiontitle="Additional Information">numbered="true" toc="default"> <name>Additional Information</name> <t>See <xreftarget="intro"/>target="intro" format="default"/> for a discussion of relatedname spaces.</t>namespaces.</t> </section> <sectiontitle="Revision Information"> <t>Revision Information: Thisnumbered="true" toc="default"> <name>Revision Information</name> <t>This is the first version of this registration.</t> </section> </section> <section anchor="subtypes"title="DEVnumbered="true" toc="default"> <name>DEV URNSubtypes">Subtypes</name> <section anchor="mac"title="MAC Addresses">numbered="true" toc="default"> <name>MAC Addresses</name> <t>DEV URNs of the "mac" subtype are based on the EUI-64 identifier <xreftarget="IEEE.EUI64"/>target="IEEE.EUI64" format="default"/> 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 followed by 40 or 28 bits of device-specific extension identifier assigned by that organization.</t> <t>In the DEV URN "mac"subtypesubtype, the hexstring is simply the full EUI-64 identifier represented as a hexadecimal string. It is always exactly 16 characters long.</t> <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 OUIthe Organizationally Unique Identifier (OUI) of the MAC-48 address (the first three octets) becomes 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 (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 an EUI-48 identifier, but the fixed value 0xfffe is used instead.</t> <t>Identifier assignment for all of these identifiers rests within the 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 <xreftarget="assignment"/>.</t>target="assignment" format="default"/>.</t> </section> <section anchor="s1wire"title="1-Wirenumbered="true" toc="default"> <name>1-Wire DeviceIdentifiers">Identifiers</name> <t>The1-Wire*1-Wire system is a device communications bus system designed by Dallas Semiconductor Corporation. (1-Wire is a registered trademark.) 1-Wire devices are identified by a 64-bit identifier that consists of8 bitan 8-bit family code,48 bita 48-bit identifier unique within a family, and8 bit CRCan 8-bit Cyclic Redundancy Check (CRC) code <xreftarget="OW"/>. <list style="empty"> <t>*) 1-Wire is a registered trademark.</t> </list>target="OW" format="default"/>. </t> <t>In DEV URNs with the "ow"subtypesubtype, the hexstring is a representation of the full 64-bit identifier as a hexadecimal string. It is always exactly 16 characters long. Note that the last two characters represent the 8-bit CRC code. ImplementationsMAY<bcp14>MAY</bcp14> check the validity of this code.</t> <t>Family code and identifier assignment for all 1-Wire devices rests with the manufacturers.</t> </section> <section anchor="org"title="Organization-Defined Identifiers">numbered="true" toc="default"> <name>Organization-Defined Identifiers</name> <t>Device identifiers that have only a meaning within an organization can also be used to represent vendor-specific or experimental identifiers or identifiers designed for use within the context of an organization.</t> <t>Organizations are identified by their Private Enterprise Number (PEN) <xreftarget="RFC2578"/>.target="RFC2578" format="default"/>. These numbers can be obtained from IANA. Current PEN assignments can be viewed athttps://www.iana.org/assignments/enterprise-numbers/enterprise-numbers<eref brackets="angle" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers"/>, and new assignments are requested athttps://pen.iana.org/pen/PenApplication.page.</t><eref brackets="angle" target="https://pen.iana.org/pen/PenApplication.page"/>.</t> <t>Note that when included in an "org" DEV URN, the numbercan notcannot be zero or have leading zeroes, as the ABNF requires the number to start with a non-zero digit.</t> </section> <section anchor="os"title="Organizationnumbered="true" toc="default"> <name>Organization SerialNumbers">Numbers</name> <t>The "os" subtype specifies an organization andaserial number. Organizations are identified by their PEN. As with the organization-defined identifiers (<xreftarget="org"/>),target="org" format="default"/>), PEN number assignments are maintained by IANA, and assignments for new organizations can be made easily.<list style="empty"> <t>Historical</t> <aside><t> Historical note: The "os" subtype was originallybeendefined in the Open Mobile Alliance "Lightweight Machine to Machine" standard <xreftarget="LwM2M"/>,target="LwM2M" format="default"/> but has been incorporated here to collect allsyntaxsyntaxes associated with DEV URNs in one place. At the same time, the syntax of this subtype was changed to avoid the possibility of characters that are not allowed in the SenML Name field (see <xreftarget="RFC8428"/> Section 4.5.1).</t> </list></t>target="RFC8428" sectionFormat="comma" section="4.5.1"/>).</t> </aside> <t>Organization serial number DEV URNs consist of the PEN number and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. The serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated.</t> <t>Organizations are also encouraged to select serial number formats that avoid the possibilityfor ambiguity,of ambiguity in the form of leading zeroes or otherwise.</t> </section> <section anchor="ops"title="Organizationnumbered="true" toc="default"> <name>Organization Product and SerialNumbers">Numbers</name> <t>The DEV URN "ops" subtypehaswas originallybeendefined in the LwM2Mstandard,standard but has been incorporated here to collect allsyntaxsyntaxes associated with DEV URNs in one place. The "ops" subtype specifies an organization, product class, and a serial number. Organizations are identified by their PEN. Again, as with the organization-defined identifiers (<xreftarget="org"/>),target="org" format="default"/>), PEN number assignments are maintained by IANA.<list style="empty"> <t>Historical</t> <aside><t> Historical note: As with the "os" subtype, the "ops" subtypehaswas originallybeendefined inOMA.</t> </list></t>the Open Mobile Alliance "Lightweight Machine to Machine" standard <xref target="LwM2M" format="default"/>. </t></aside> <t>Organization product and serial number DEV URNs consist of the PEN number, product class, and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. Both the product class and serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated.</t> <t>Organizations are also encouraged to select product and serial number formats that avoid possibility for ambiguity.</t> </section> <section anchor="futuresubtypes"title="Future Subtypes">numbered="true" toc="default"> <name>Future Subtypes</name> <t>Additional subtypes may be defined inother,future specifications. See <xreftarget="iana"/>.</t>target="iana" format="default"/>.</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 <xreftarget="syntax"/>.</t>target="syntax" format="default"/>.</t> </section> </section> <section anchor="ex"title="Examples">numbered="true" toc="default"> <name>Examples</name> <t>The following provides some examples of DEV URNs:<figure> <artwork> urn:dev:mac:0024beffff804ff1 # The</t> <table> <thead> <tr> <th>URN</th> <th>Description</th> </tr> </thead> <tbody> <tr> <td>urn:dev:mac:0024beffff804ff1</td> <td>The MAC-48 address of#0024be804ff1, converted#to EUI-64format urn:dev:mac:0024befffe804ff1 #format</td> </tr> <tr> <td> urn:dev:mac:0024befffe804ff1</td> <td> The EUI-48 address of#0024be804ff1, converted#to EUI-64format urn:dev:mac:acde48234567019f # Theformat</td> </tr> <tr> <td>urn:dev:mac:acde48234567019f</td> <td>The EUI-64 address of#acde48234567019furn:dev:ow:10e2073a01080063 # A</td> </tr> <tr> <td> urn:dev:ow:10e2073a01080063</td> <td>A 1-Wire temperature# sensor urn:dev:ow:264437f5000000ed_humidity # Thesensor</td> </tr> <tr> <td>urn:dev:ow:264437f5000000ed_humidity</td> <td>The humidity#part of a multi-sensor#deviceurn:dev:ow:264437f5000000ed_temperature # The</td> </tr> <tr> <td>urn:dev:ow:264437f5000000ed_temperature</td> <td>The temperature#part of a multi-sensor# device urn:dev:org:32473-foo # An organization- # specificdevice</td> </tr> <tr> <td>urn:dev:org:32473-foo</td> <td>An organization-specific URN in#theRFC 5612example# organization, 32473. urn:dev:os:32473-123456 # Deviceorganization 32473 in <xref target="RFC5612"/> </td> </tr> <tr> <td>urn:dev:os:32473-123456</td> <td>Device 123456 in#theRFC 5612example#organizationurn:dev:os:32473-12-34-56 # Ain <xref target="RFC5612"/></td> </tr> <tr> <td>urn:dev:os:32473-12-34-56</td> <td>A serial number with#dashes init urn:dev:ops:32473-Refrigerator-5002 # Refrigeratorit</td> </tr> <tr> <td>urn:dev:ops:32473-Refrigerator-5002</td> <td>Refrigerator serial#number 5002 in the# RFC 5612example#organizationurn:dev:example:new-1-2-3_comp # Anin <xref target="RFC5612"/></td> </tr> <tr> <td>urn:dev:example:new-1-2-3_comp</td> <td>An example of something#that is not defined today,#and is not one of the#mac, ow, os, or ops# subtypes </artwork> </figure> </t>subtypes</td> </tr> </tbody> </table> <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.For example, thisThis example from <xreftarget="RFC8428"/>target="RFC8428" format="default"/> shows a measurement from a 1-Wire temperature gauge encoded in the JSONsyntax. <figure> <artwork>syntax: </t> <sourcecode name="" type="json"><![CDATA[ [ {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} ]</artwork> </figure> </t>]]></sourcecode> </section> <section anchor="sec"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered with by the user. An implementation of the DEV URNMUST<bcp14>MUST</bcp14> preserve such limitations and behaviors associated with the device identifiers. In particular, 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 this document should be construed to override what the relevant device specifications have already said about the identifiers.</t> <section anchor="priv"title="Privacy">numbered="true" toc="default"> <name>Privacy</name> <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 address of a device is visible to all other devices.</t> <t>DEV URNs often represent long-term stable unique identifiers for devices. Such identifiers may have privacy and security implications because they may enable correlating information about a specific device over a long period of time, location tracking, anddevice specificdevice-specific vulnerability exploitation <xreftarget="RFC7721"/>.target="RFC7721" format="default"/>. Also, in somesystemssystems, there is no easy way to change the identifier.ThereforeTherefore, these identifiers need to be used withcarecare, andespeciallyspecial care should be taken to avoid leakingthemidentifiers outside of the system that is intended to usethe identifiers.</t>them.</t> </section> <section anchor="valid"title="Validity">numbered="true" toc="default"> <name>Validity</name> <t>Information about identifiers may have significant effects in some applications. For instance, in many sensorsystemssystems, the identifier information is used for deciding how to use the data carried in a measurement report.OnIn some other systems, identifiers may be used in policy decisions.</t> <t>It is important that systemsarebe designed to take into account the possibility of devices reporting incorrect identifiers (either accidentally or maliciously) and the manipulation of identifiers in communications by illegitimate entities. Integrity protection of communications or data objects, the use of trusted devices, and various management practices can help address these issues. </t><t>The<t>Similar to the advicefromin <xreftarget="RFC4122"/> Section 6 also applies:target="RFC4122" sectionFormat="comma" section="6"/>: Do not assume that DEV URNs are hard to guess.</t> </section> </section> <section anchor="iana"title="IANA Considerations"> <t>This document requests the registration ofnumbered="true" toc="default"> <name>IANA Considerations</name> <t>Per this document, IANA has registered a new URN namespace for"DEV","dev", as described in <xreftarget="devurn"/>.</t>target="devurn" format="default"/>.</t> <t>IANAis asked to createhas created a "DEV URN Subtypes"registry.registry under "Device Identification". The initial values in this registry are as follows:<figure> <artwork> Subtype Description Reference ------------------------------------------------------------------------ mac MAC Addresses (THIS RFC) Section 4.1 ow 1-Wire</t> <table> <thead> <tr> <th>Subtype</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>mac</td> <td>MAC Addresses</td> <td>RFC 9039, <xref target="mac"/></td> </tr> <tr> <td>ow</td> <td>1-Wire DeviceIdentifiers (THIS RFC) Section 4.2 org Organization-Defined Identifiers (THIS RFC) Section 4.3 os OrganizationIdentifiers</td> <td>RFC 9039, <xref target="s1wire"/></td> </tr> <tr> <td>org</td> <td>Organization-Defined Identifiers</td> <td>RFC 9039, <xref target="org"/></td> </tr> <tr> <td>os</td> <td>Organization SerialNumbers (THIS RFC) Section 4.4 ops OrganizationNumbers</td> <td>RFC 9039, <xref target="os"/></td> </tr> <tr> <td>ops</td> <td>Organization Product and SerialNumbers (THIS RFC) Section 4.5 example Reserved for examples (THIS RFC) Section 4.6 </artwork> </figure></t>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 <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. These allocations are appropriate when there is a new namespace of some type of deviceidentifiers,identifier that is defined in a stable fashion andwithhas a publicly available specification.</t> <t>Note that the organization (<xreftarget="org"/>)target="org" format="default"/>) device identifiers can also be used in some cases, at least as a temporary measure. It is preferable, however, that long-term usage of a broadly employed device identifier be registered with IETF rather than used through the organization device identifier type.</t> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC2578; &RFC3986; &RFC5234; &RFC8126; &RFC8141; &RFC8174;<displayreference target="I-D.ietf-core-resource-directory" to="CoRE-RD"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2578.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8141.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <reference anchor="IEEE.EUI64" target="https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf"> <front> <title>GuidelinesFor 64-bit Globalfor Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier(EUI-64)</title>(OUI), and Company ID (CID)</title> <author> <organization>IEEE</organization> </author> <dateyear='unknown year' />month="August" year="2017"/> </front><seriesInfo name="IEEE" value=" " /></reference> <reference anchor="OW" target="https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html"> <front> <title>Guide to 1-Wire Communication</title> <author> <organization>Maxim</organization> </author> <datemonth='June' year='2008' />month="June" year="2008"/> </front><seriesInfo name="MAXIM" value=" https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html" /></reference> </references><references title="Informative References"> &RFC3261; &RFC4122; &RFC4648; &RFC7230; &RFC7540; &RFC7721; &RFC8259;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5612.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7230.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7540.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/> <referenceanchor='W3C.REC-xml-19980210' target='http://www.w3.org/TR/1998/REC-xml-19980210'>anchor="W3C.REC-xml-19980210" target="http://www.w3.org/TR/1998/REC-xml-19980210"> <front><title>XML 1.0 Recommendation</title><title>Extensible Markup Language (XML) 1.0</title> <authorinitials='C.' surname='Sperberg-McQueen' fullname='C.initials="C." surname="Sperberg-McQueen" fullname="C. M.Sperberg-McQueen'>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" year="1998"/> </front> <seriesInfo name="W3C" value="Recommendation"/> </reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8428.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6920.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7254.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8464.xml"/> <!-- [draft-ietf-core-resource-directory] MISSREF state --> <reference anchor='I-D.ietf-core-resource-directory'> <front> <title>CoRE Resource Directory</title> <author initials='C' surname='Amsüss' fullname='Christian Amsüss' role="editor"> <organization /> </author> <authorinitials='T.' surname='Bray' fullname='Tim Bray'>initials='Z' surname='Shelby' fullname='Zach Shelby'> <organization /> </author> <authorinitials='J.' surname='Paoli' fullname='Jean Paoli'>initials='M' surname='Koster' fullname='Michael Koster'> <organization /> </author><date month='February' day='10' year='1998' /> </front> <seriesInfo name='World Wide Web Consortium FirstEdition' value='REC-xml-19980210' /> <format type='HTML' target='http://www.w3.org/TR/1998/REC-xml-19980210'<author initials='C' surname='Bormann' fullname='Carsten Bormann'> <organization /></reference> <reference anchor='OUI' target='http://standards.ieee.org/develop/regauth/oui/'> <front> <title>Registration Authority</title></author> <authorinitials="SA" surname="IEEE" fullname='IEEE-SA'>initials='P' surname='van der Stok' fullname='Peter van der Stok'> <organization /> </author> <dateyear='2018' />month="March" day="7" year="2021"/> </front> <seriesInfoname='IEEE-SA' value='webpage'/> <format type='HTML' target='http://standards.ieee.org/develop/regauth/oui/'name='Internet-Draft' value='draft-ietf-core-resource-directory-28' /> </reference>&RFC7252; &RFC8428; &RFC6920; &RFC7254; &RFC7405; &RFC8464; &I-D.ietf-core-resource-directory;<referenceanchor="LwM2M">anchor="LwM2M" target="https://www.openmobilealliance.org/release/LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-V1_2-20190124-C.pdf"> <front> <title>OMA Lightweight Machine to Machine Requirements</title> <author fullname="Open MobileAlliance"></author>Alliance"/> <dateyear='2019' month='January'/>year="2019" month="January"/> </front> <seriesInfo name="OMA Standard" value="Candidate Version 1.2"/><format type='HTML' target='http://www.openmobilealliance.org/wp/Overviews/lightweightm2m_overview.html' /></reference> </references> </references> <sectiontitle="Changes from Previous Versions"> <t>Editor's note: Please remove this section before publication.</t> <t>Version -11 was creatednumbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like toaddress 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="valid"/>.</t> <t>Simplifiedthank <contact fullname="Ari Keränen"/>, <contact 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 Fossati"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Marco Tiloca"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Amanda Baber"/>, <contact fullname="Juha Hakala"/>, <contact fullname="Dale Worley"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Brian Weis"/>, <contact fullname="John Klensin"/>, <contact fullname="Dave Thaler"/>, <contact fullname="Russ Housley"/>, <contact fullname="Dan Romascanu"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman Danyliw"/>, and <contact fullname="Ahmad Muhanna"/> for their feedback andclarified the "illegitimate entities" statement in <xref 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 syntaxinteresting discussions inthe ABNF.</t> <t>Added a reserved "example" subtypethis problem space. We would also like tobe 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="s1wire"/>.</t> <t>Clarifiednote prior documents thatoptional 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 instead of a hard rule, basedfocused onthe 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 more compact but morespecificformats, indevice identifiers, such as <xreftarget="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 "caretarget="RFC7254" format="default"/> andavoidance".</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 parameters 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 in the otherbody branch of the ABNF.</t> </list></t> <t>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.</t> <t>Version -01 of the WG draft converted the draft to use the new URN registration template from <xref target="RFC8141"/>.</t> <t>Version -00 of the WG draft renamed the file name and fixed the ABNF to correctly use "org:" rather than "dn:".</t> <t>Version -05 made a change to the delimiter for parameters within a DEV URN. Given discussions on allowed character sets in SenML <xref target="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.</t> <t>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.</t> <t>Version -05 also added some discussion of privacy concerns around long-term stable identifiers.</t> <t>Finally, version -05 clarified the situations when new allocations within the registry of possible device identifier subtypes is appropriate.</t> <t>Version -04 is a refresh, as the need and interest for this specification has re-emerged. And the editing author has emerged back to actual engineering from the depths of IETF administration.</t> <t>Version -02 introduced several changes. The biggest change is that with the NI URNs <xref target="RFC6920"/>, it was no longer necessary to define cryptographic identifiers in this specification. Another change was that we incorporated a more 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 some editorial corrections.</t> </section> <section title="Acknowledgments"> <t>The authors would like to thank Ari Keranen, Stephen Farrell, Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba, Amanda Baber, Juha Hakala, Dale Worley, Warren Kumari, Benjamin Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ Housley, Dan Romascanu, Eric Vyncke, Roman Danyliw, and Ahmad Muhanna for feedback and interesting discussions in this problem space. We would also like to note prior documents that focused on specific device identifiers, such as <xref target="RFC7254"/> or<xreftarget="RFC8464"/>.</t>target="RFC8464" format="default"/>.</t> </section> </back> </rfc>