doc: Add RFC documents

1 files changed, 792 insertions, 0 deletions

diff --git a/doc/rfc/rfc9039.txt b/doc/rfc/rfc9039.txt
new file mode 100644
index 0000000..e2d2cd6
--- /dev/null
+++ b/doc/rfc/rfc9039.txt
@@ -0,0 +1,792 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Arkko
+Request for Comments: 9039                                      Ericsson
+Category: Standards Track                                    C. Jennings
+ISSN: 2070-1721                                                    Cisco
+                                                               Z. Shelby
+                                                            Edge Impulse
+                                                               June 2021
+
+
+             Uniform Resource Names for Device Identifiers
+
+Abstract
+
+   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 and storage or in equipment inventories.  A URN-based
+   representation can be passed along in applications that need the
+   information.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9039.
+
+Copyright Notice
+
+   Copyright (c) 2021 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Requirements Language
+   3.  DEV URN Definition
+     3.1.  Purpose
+     3.2.  Syntax
+       3.2.1.  Character Case and URN-Equivalence
+     3.3.  Assignment
+     3.4.  Security and Privacy
+     3.5.  Interoperability
+     3.6.  Resolution
+     3.7.  Documentation
+     3.8.  Additional Information
+     3.9.  Revision Information
+   4.  DEV URN Subtypes
+     4.1.  MAC Addresses
+     4.2.  1-Wire Device Identifiers
+     4.3.  Organization-Defined Identifiers
+     4.4.  Organization Serial Numbers
+     4.5.  Organization Product and Serial Numbers
+     4.6.  Future Subtypes
+   5.  Examples
+   6.  Security Considerations
+     6.1.  Privacy
+     6.2.  Validity
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   This document describes a new Uniform Resource Name (URN) [RFC8141]
+   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 or in equipment inventories [RFC7252]
+   [RFC8428] [CoRE-RD].
+
+   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 [RFC7230] [RFC7540]
+   [RFC3261] [RFC7252].  Finally, URNs can also be easily carried and
+   stored in formats such as XML [W3C.REC-xml-19980210], JSON [RFC8259],
+   or SenML [RFC8428].  Using URNs in these formats is often preferable
+   as they are universally recognized and self-describing and therefore
+   avoid the need to agree to 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, for instance, passing
+   4-byte binary IPv4 addresses, but the former offers some flexibility
+   in return.
+
+   This document defines identifier URN types for situations where no
+   such convenient type already exists.  For instance, [RFC6920] defines
+   cryptographic identifiers, [RFC7254] defines International Mobile
+   station Equipment Identity (IMEI) identifiers for use with 3GPP
+   cellular systems, and [RFC8464] 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.
+
+   Universally Unique Identifier (UUID) URNs [RFC4122] are another
+   alternative way to represent device identifiers and already support
+   MAC addresses as one type of identifier.  However, UUIDs can be
+   inconvenient in environments where it is important that the
+   identifiers be 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.
+
+   Future device identifier types can extend the device URN type defined
+   in this document (see Section 7), or they can define their own URNs.
+
+   Note that long-term stable unique identifiers are problematic for
+   privacy reasons and should be used with care as described in
+   [RFC7721].
+
+   The rest of this document is organized as follows.  Section 3 defines
+   the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48,
+   EUI-48 and EUI-64 addresses, and 1-Wire device identifiers.
+   Section 5 gives examples.  Section 6 discusses the security and
+   privacy considerations of the new URN type.  Finally, Section 7
+   specifies the IANA registration for the new URN type and sets
+   requirements for subtype allocations within this type.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+3.  DEV URN Definition
+
+   Namespace Identifier:  "dev"
+
+   Version:  1
+
+   Date:  2020-06-24
+
+   Registrant:  IETF and the CORE Working Group.  Should the working
+      group cease to exist, discussion should be directed to the
+      Applications and Real-Time Area or general IETF discussion forums,
+      or the IESG.
+
+3.1.  Purpose
+
+   The DEV URNs identify devices with device-specific identifiers such
+   as network card hardware addresses.  DEV URNs are scoped to be
+   globally applicable (see [RFC8141], 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 Section 3.3.
+
+   Some typical DEV URN applications include equipment inventories and
+   smart object systems.
+
+   DEV URNs can be used in various ways in applications, software
+   systems, and network components, in tasks ranging from discovery (for
+   instance, when discovering 1-Wire network devices or detecting MAC-
+   addressable devices on a LAN) to intrusion detection systems and
+   simple catalogues of system information.
+
+   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 purpose convenient.
+
+   The DEV URN namespace complements existing namespaces 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 in URNs.
+
+3.2.  Syntax
+
+   The identifier is expressed in ASCII characters and has a
+   hierarchical structure as follows:
+
+   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
+
+   The above syntax is represented in Augmented Backus-Naur Form (ABNF)
+   as defined in [RFC5234] and [RFC7405].  The syntax also copies the
+   DIGIT and ALPHA rules originally defined in [RFC5234], exactly as
+   defined there.
+
+   The device identifier namespace includes five subtypes (see
+   Section 4), and more may be defined in the future as specified in
+   Section 7.
+
+   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 the device but could be
+   used to refer to specific interfaces or functions within the device.
+
+   With the exception of the MAC address and 1-Wire DEV URNs, each DEV
+   URN may also contain optional colon-separated identifiers.  These are
+   provided for extensibility.
+
+   There are no special character encoding rules or considerations for
+   conforming with the URN syntax beyond those applicable for URNs in
+   general [RFC8141] or the context where these URNs are carried (e.g.,
+   inside JSON [RFC8259] or SenML [RFC8428]).  Due to the SenML rules in
+   [RFC8428], 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 [RFC3986] and [RFC8141].
+
+   DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].
+
+   Specific subtypes of DEV URNs may be validated through mechanisms
+   discussed in Section 4.
+
+   The string representation of the device identifier URN is fully
+   compatible with the URN syntax.
+
+3.2.1.  Character Case and URN-Equivalence
+
+   The DEV URN syntax allows both uppercase and lowercase characters.
+   The URN-equivalence of the DEV URNs is defined per [RFC8141],
+   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 a case-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 same entity and
+   may not be found to be URN-equivalent according to the [RFC8141]
+   definition.  For instance, in ABNF, strings are case insensitive (see
+   [RFC5234], Section 2.3), and a MAC address could be represented
+   either with uppercase or lowercase hexadecimal digits.
+
+   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 as base64, which encodes strings
+   in a larger variety of characters and might even encode binary data.
+
+   To facilitate equivalence checks, it is RECOMMENDED that
+   implementations always use lowercase 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 both
+   uppercase and lowercase letters.)
+
+3.3.  Assignment
+
+   The process for identifier assignment is dependent on the used
+   subtype and is documented in the specific subsection under Section 4.
+
+   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 by 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.  And, of course, a single device
+   may (and often does) have multiple identifiers, e.g., identifiers
+   associated with different link technologies it supports.
+
+   The DEV URN type SHOULD only be used for hardware-based identifiers
+   that are expected to be persistent (with some limits, as discussed
+   above).
+
+3.4.  Security and Privacy
+
+   As discussed in Section 6, 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.
+
+3.5.  Interoperability
+
+   There are no specific interoperability concerns.
+
+3.6.  Resolution
+
+   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.
+
+3.7.  Documentation
+
+   See RFC 9039.
+
+3.8.  Additional Information
+
+   See Section 1 for a discussion of related namespaces.
+
+3.9.  Revision Information
+
+   This is the first version of this registration.
+
+4.  DEV URN Subtypes
+
+4.1.  MAC Addresses
+
+   DEV URNs of the "mac" subtype are based on the EUI-64 identifier
+   [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64.
+   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.
+
+   In the DEV URN "mac" subtype, the hexstring is simply the full EUI-64
+   identifier represented as a hexadecimal string.  It is always exactly
+   16 characters long.
+
+   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
+   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.
+
+   Identifier assignment for all of these identifiers rests within the
+   IEEE Registration Authority.
+
+   Note that where randomized MAC addresses are used, the resulting DEV
+   URNs cannot be expected to have uniqueness, as discussed in
+   Section 3.3.
+
+4.2.  1-Wire Device Identifiers
+
+   The 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 of
+   an 8-bit family code, a 48-bit identifier unique within a family, and
+   an 8-bit Cyclic Redundancy Check (CRC) code [OW].
+
+   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
+   exactly 16 characters long.  Note that the last two characters
+   represent the 8-bit CRC code.  Implementations MAY check the validity
+   of this code.
+
+   Family code and identifier assignment for all 1-Wire devices rests
+   with the manufacturers.
+
+4.3.  Organization-Defined Identifiers
+
+   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.
+
+   Organizations are identified by their Private Enterprise Number (PEN)
+   [RFC2578].  These numbers can be obtained from IANA.  Current PEN
+   assignments can be viewed at <https://www.iana.org/assignments/
+   enterprise-numbers/>, and new assignments are requested at
+   <https://pen.iana.org/pen/PenApplication.page>.
+
+   Note that when included in an "org" DEV URN, the number cannot be
+   zero or have leading zeroes, as the ABNF requires the number to start
+   with a non-zero digit.
+
+4.4.  Organization Serial Numbers
+
+   The "os" subtype specifies an organization and serial number.
+   Organizations are identified by their PEN.  As with the organization-
+   defined identifiers (Section 4.3), PEN number assignments are
+   maintained by IANA, and assignments for new organizations can be made
+   easily.
+
+      |  Historical note: The "os" subtype was originally defined in the
+      |  Open Mobile Alliance "Lightweight Machine to Machine" standard
+      |  [LwM2M] but has been incorporated 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 possibility of
+      |  characters that are not allowed in the SenML Name field (see
+      |  [RFC8428], Section 4.5.1).
+
+   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.
+
+   Organizations are also encouraged to select serial number formats
+   that avoid the possibility of ambiguity in the form of leading zeroes
+   or otherwise.
+
+4.5.  Organization Product and Serial Numbers
+
+   The DEV URN "ops" subtype was originally defined in the LwM2M
+   standard but has been incorporated here to collect all syntaxes
+   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 (Section 4.3), PEN number assignments are maintained by
+   IANA.
+
+      |  Historical note: As with the "os" subtype, the "ops" subtype
+      |  was originally defined in the Open Mobile Alliance "Lightweight
+      |  Machine to Machine" standard [LwM2M].
+
+   Organization product and serial number DEV URNs consist of the PEN
+   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.
+
+   Organizations are also encouraged to select product and serial number
+   formats that avoid possibility for ambiguity.
+
+4.6.  Future Subtypes
+
+   Additional subtypes may be defined in future specifications.  See
+   Section 7.
+
+   The DEV URN "example" subtype is reserved for use in examples.  It
+   has no specific requirements beyond those expressed by the ABNF in
+   Section 3.2.
+
+5.  Examples
+
+   The following provides some examples of DEV URNs:
+
+   +=========================================+=========================+
+   | URN                                     | Description             |
+   +=========================================+=========================+
+   | urn:dev:mac:0024beffff804ff1            | The MAC-48 address of   |
+   |                                         | 0024be804ff1,           |
+   |                                         | converted to EUI-64     |
+   |                                         | format                  |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:mac:0024befffe804ff1            | The EUI-48 address of   |
+   |                                         | 0024be804ff1,           |
+   |                                         | converted to EUI-64     |
+   |                                         | format                  |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:mac:acde48234567019f            | The EUI-64 address of   |
+   |                                         | acde48234567019f        |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:ow:10e2073a01080063             | A 1-Wire temperature    |
+   |                                         | sensor                  |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:ow:264437f5000000ed_humidity    | The humidity part of    |
+   |                                         | a multi-sensor device   |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:ow:264437f5000000ed_temperature | The temperature part    |
+   |                                         | of a multi-sensor       |
+   |                                         | device                  |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:org:32473-foo                   | An organization-        |
+   |                                         | specific URN in the     |
+   |                                         | example organization    |
+   |                                         | 32473 in [RFC5612]      |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:os:32473-123456                 | Device 123456 in the    |
+   |                                         | example organization    |
+   |                                         | in [RFC5612]            |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:os:32473-12-34-56               | A serial number with    |
+   |                                         | dashes in it            |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:ops:32473-Refrigerator-5002     | Refrigerator serial     |
+   |                                         | number 5002 in the      |
+   |                                         | example organization    |
+   |                                         | in [RFC5612]            |
+   +-----------------------------------------+-------------------------+
+   | urn:dev:example:new-1-2-3_comp          | An example of           |
+   |                                         | something that is not   |
+   |                                         | defined today, and is   |
+   |                                         | not one of the mac,     |
+   |                                         | ow, os, or ops          |
+   |                                         | subtypes                |
+   +-----------------------------------------+-------------------------+
+
+                                  Table 1
+
+   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 [RFC8428] shows a measurement from a 1-Wire temperature
+   gauge encoded in the JSON syntax:
+
+      [
+        {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
+      ]
+
+6.  Security Considerations
+
+   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 URN MUST
+   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.
+
+6.1.  Privacy
+
+   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.
+
+   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, and device-
+   specific vulnerability exploitation [RFC7721].  Also, in some
+   systems, there is no easy way to change the identifier.  Therefore,
+   these identifiers need to be used with care, and special care should
+   be taken to avoid leaking identifiers outside of the system that is
+   intended to use them.
+
+6.2.  Validity
+
+   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
+   measurement report.  In some other systems, identifiers may be used
+   in policy decisions.
+
+   It is important that systems be 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.
+
+   Similar to the advice in [RFC4122], Section 6: Do not assume that DEV
+   URNs are hard to guess.
+
+7.  IANA Considerations
+
+   Per this document, IANA has registered a new URN namespace for "dev",
+   as described in Section 3.
+
+   IANA has created a "DEV URN Subtypes" registry under "Device
+   Identification".  The initial values in this registry are as follows:
+
+      +=========+===========================+=======================+
+      | Subtype | Description               | Reference             |
+      +=========+===========================+=======================+
+      | mac     | MAC Addresses             | RFC 9039, Section 4.1 |
+      +---------+---------------------------+-----------------------+
+      | ow      | 1-Wire Device Identifiers | RFC 9039, Section 4.2 |
+      +---------+---------------------------+-----------------------+
+      | org     | Organization-Defined      | RFC 9039, Section 4.3 |
+      |         | Identifiers               |                       |
+      +---------+---------------------------+-----------------------+
+      | os      | Organization Serial       | RFC 9039, Section 4.4 |
+      |         | Numbers                   |                       |
+      +---------+---------------------------+-----------------------+
+      | ops     | Organization Product and  | RFC 9039, Section 4.5 |
+      |         | Serial Numbers            |                       |
+      +---------+---------------------------+-----------------------+
+      | example | Reserved for examples     | RFC 9039, Section 4.6 |
+      +---------+---------------------------+-----------------------+
+
+                                  Table 2
+
+   Additional subtypes for DEV URNs can be defined through Specification
+   Required or IESG Approval [RFC8126].  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.
+
+   Note that the organization (Section 4.3) 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.
+
+8.  References
+
+8.1.  Normative References
+
+   [IEEE.EUI64]
+              IEEE, "Guidelines for Use of Extended Unique Identifier
+              (EUI), Organizationally Unique Identifier (OUI), and
+              Company ID (CID)", August 2017,
+              <https://standards.ieee.org/content/dam/ieee-
+              standards/standards/web/documents/tutorials/eui.pdf>.
+
+   [OW]       Maxim, "Guide to 1-Wire Communication", June 2008,
+              <https://www.maximintegrated.com/en/design/technical-
+              documents/tutorials/1/1796.html>.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
+              Schoenwaelder, Ed., "Structure of Management Information
+              Version 2 (SMIv2)", STD 58, RFC 2578,
+              DOI 10.17487/RFC2578, April 1999,
+              <https://www.rfc-editor.org/info/rfc2578>.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66,
+              RFC 3986, DOI 10.17487/RFC3986, January 2005,
+              <https://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
+              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
+              <https://www.rfc-editor.org/info/rfc8141>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2.  Informative References
+
+   [CoRE-RD]  Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
+              P. van der Stok, "CoRE Resource Directory", Work in
+              Progress, Internet-Draft, draft-ietf-core-resource-
+              directory-28, 7 March 2021,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-core-
+              resource-directory-28>.
+
+   [LwM2M]    Alliance, O. M., "OMA Lightweight Machine to Machine
+              Requirements", OMA Standard Candidate Version 1.2, January
+              2019, <https://www.openmobilealliance.org/release/
+              LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-
+              V1_2-20190124-C.pdf>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <https://www.rfc-editor.org/info/rfc4122>.
+
+   [RFC5612]  Eronen, P. and D. Harrington, "Enterprise Number for
+              Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
+              2009, <https://www.rfc-editor.org/info/rfc5612>.
+
+   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
+              Keranen, A., and P. Hallam-Baker, "Naming Things with
+              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
+              <https://www.rfc-editor.org/info/rfc6920>.
+
+   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
+              Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <https://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
+              Application Protocol (CoAP)", RFC 7252,
+              DOI 10.17487/RFC7252, June 2014,
+              <https://www.rfc-editor.org/info/rfc7252>.
+
+   [RFC7254]  Montemurro, M., Ed., Allen, A., McDonald, D., and P.
+              Gosden, "A Uniform Resource Name Namespace for the Global
+              System for Mobile Communications Association (GSMA) and
+              the International Mobile station Equipment Identity
+              (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
+              <https://www.rfc-editor.org/info/rfc7254>.
+
+   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
+              RFC 7405, DOI 10.17487/RFC7405, December 2014,
+              <https://www.rfc-editor.org/info/rfc7405>.
+
+   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
+              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
+              DOI 10.17487/RFC7540, May 2015,
+              <https://www.rfc-editor.org/info/rfc7540>.
+
+   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
+              Considerations for IPv6 Address Generation Mechanisms",
+              RFC 7721, DOI 10.17487/RFC7721, March 2016,
+              <https://www.rfc-editor.org/info/rfc7721>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [RFC8428]  Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
+              Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
+              DOI 10.17487/RFC8428, August 2018,
+              <https://www.rfc-editor.org/info/rfc8428>.
+
+   [RFC8464]  Atarius, R., "A URN Namespace for Device Identity and
+              Mobile Equipment Identity (MEID)", RFC 8464,
+              DOI 10.17487/RFC8464, September 2018,
+              <https://www.rfc-editor.org/info/rfc8464>.
+
+   [W3C.REC-xml-19980210]
+              Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible
+              Markup Language (XML) 1.0", W3C Recommendation, February
+              1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
+
+Acknowledgments
+
+   The authors would like to thank Ari Keränen, 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, Éric Vyncke, Roman Danyliw, and Ahmad Muhanna for their
+   feedback and interesting discussions in this problem space.  We would
+   also like to note prior documents that focused on specific device
+   identifiers, such as [RFC7254] and [RFC8464].
+
+Authors' Addresses
+
+   Jari Arkko
+   Ericsson
+   FI-02420 Jorvas
+   Finland
+
+   Email: jari.arkko@piuha.net
+
+
+   Cullen Jennings
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA 95134
+   United States of America
+
+   Phone: +1 408 421-9990
+   Email: fluffy@iii.ca
+
+
+   Zach Shelby
+   Edge Impulse
+   3031 Tisch Way
+   San Jose, CA 95128
+   United States of America
+
+   Email: zach@edgeimpulse.com