draft-ietf-core-dev-urn-07.txt   draft-ietf-core-dev-urn.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational C. Jennings Intended status: Informational C. Jennings
Expires: January 3, 2021 Cisco Expires: May 6, 2021 Cisco
Z. Shelby Z. Shelby
ARM ARM
July 2, 2020 November 2, 2020
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-07 draft-ietf-core-dev-urn-08
Abstract Abstract
This memo describes a new Uniform Resource Name (URN) namespace for This document describes a new Uniform Resource Name (URN) namespace
hardware device identifiers. A general representation of device for hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories. A URN-based streams and storage, or equipment inventories. A URN-based
representation can be easily passed along in any application that representation can be easily passed along in any application that
needs the information. needs the information.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2021. This Internet-Draft will expire on May 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3
3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2.1. Character Case and URN-Equivalence . . . . . . . . . 6
3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6 3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 7
3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6 3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 7
3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7 3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Additional Information . . . . . . . . . . . . . . . . . 7 3.8. Additional Information . . . . . . . . . . . . . . . . . 7
3.9. Revision Information . . . . . . . . . . . . . . . . . . 7 3.9. Revision Information . . . . . . . . . . . . . . . . . . 7
4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7
4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7
4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8
4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8
4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9
4.5. Organization Product and Serial Numbers . . . . . . . . . 9 4.5. Organization Product and Serial Numbers . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Changes from Previous Version . . . . . . . . . . . 14 Appendix A. Changes from Previous Version . . . . . . . . . . . 15
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
This memo describes a new Uniform Resource Name (URN) [RFC8141] This document describes a new Uniform Resource Name (URN) [RFC8141]
namespace for hardware device identifiers. A general representation namespace for hardware device identifiers. A general representation
of device identity can be useful in many applications, such as in of device identity can be useful in many applications, such as in
sensor data streams and storage [RFC8428], or equipment inventories sensor data streams and storage [RFC8428], or equipment inventories
[RFC7252], [I-D.ietf-core-resource-directory]. [RFC7252], [I-D.ietf-core-resource-directory].
A URN-based representation can be easily passed along in any A URN-based representation can be easily passed along in any
application that needs the information, as it fits in protocols application that needs the information, as it fits in protocols
mechanisms that are designed to carry URNs [RFC7230], [RFC7540], mechanisms that are designed to carry URNs [RFC7230], [RFC7540],
[RFC3261], [RFC7252]. Finally, URNs can also be easily carried and [RFC3261], [RFC7252]. Finally, URNs can also be easily carried and
stored in formats such as XML [W3C.REC-xml-19980210] or JSON stored in formats such as XML [W3C.REC-xml-19980210] or JSON
[RFC8259] [RFC8428]. Using URNs in these formats is often preferable [RFC8259] [RFC8428]. Using URNs in these formats is often preferable
as they are universally recognized, self-describing, and therefore as they are universally recognized and self-describing, and therefore
avoid the need for agreeing to interpret an octet string as a avoid the need for agreeing to interpret an octet string as a
specific form of a MAC address, for instance. specific form of a MAC address, for instance.
This memo defines identity URN types for situations where no such This document defines identity URN types for situations where no such
convenient type already exist. For instance, [RFC6920] defines convenient type already exists. For instance, [RFC6920] defines
cryptographic identifiers, [RFC7254] defines International Mobile cryptographic identifiers, [RFC7254] defines International Mobile
station Equipment Identity (IMEI) identifiers for use with 3GPP station Equipment Identity (IMEI) identifiers for use with 3GPP
cellular systems, and [RFC8464] defines Mobile Equipment Identity cellular systems, and [RFC8464] defines Mobile Equipment Identity
(MEID) identifiers for use with 3GPP2 cellular systems. Those URN (MEID) identifiers for use with 3GPP2 cellular systems. Those URN
types should be employed when such identities are transported; this types should be employed when such identities are transported; this
memo does not redefine these identifiers in any way. document does not redefine these identifiers in any way.
Universally Unique IDentifier (UUID) URNs [RFC4122] are another Universally Unique IDentifier (UUID) URNs [RFC4122] are another
alternative way for representing device identifiers, and already alternative way for representing device identifiers, and already
support MAC addresses as one of type of an identifier. However, support MAC addresses as one of type of an identifier. However,
UUIDs can be inconvenient in environments where it is important that UUIDs can be inconvenient in environments where it is important that
the identifiers are as simple as possible and where additional the identifiers are as simple as possible and where additional
requirements on stable storage, real-time clocks, and identifier requirements on stable storage, real-time clocks, and identifier
length can be prohibitive. UUID-based identifiers are recommended length can be prohibitive. UUID-based identifiers are recommended
for all general purpose uses when MAC addresses are available as for all general purpose uses when MAC addresses are available as
identifiers. The device URN defined in this memo is recommended for identifiers. The device URN defined in this document is recommended
constrained environments. for constrained environments.
Future device identifier types can extend the device URN type defined Future device identifier types can extend the device URN type defined
here, or define their own URNs. here, or define their own URNs.
Note that long-term stable unique identifiers are problematic for Note that long-term stable unique identifiers are problematic for
privacy reasons and should be used with care or avoided as described privacy reasons and should be used with care or avoided as described
in [RFC7721]. in [RFC7721].
The rest of this memo is organized as follows. Section 3 defines the The rest of this document is organized as follows. Section 3 defines
"DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48,
EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5
gives examples. Section 6 discusses the security and privacy gives examples. Section 6 discusses the security and privacy
considerations of the new URN type. Finally, Section 7 specifies the considerations of the new URN type. Finally, Section 7 specifies the
IANA registration for the new URN type and sets requirements for IANA registration for the new URN type and sets requirements for
subtype allocations within this type. subtype allocations within this type.
2. Requirements language 2. Requirements language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at page 5, line 25 skipping to change at page 5, line 25
identifiernodash = 1*unreservednodash identifiernodash = 1*unreservednodash
product = identifiernodash product = identifiernodash
serial = identifier serial = identifier
componentpart = *( "_" identifier ) componentpart = *( "_" identifier )
unreservednodash = ALPHA / DIGIT / "." unreservednodash = ALPHA / DIGIT / "."
unreserved = unreservednodash / "-" unreserved = unreservednodash / "-"
hexstring = 1*(hexdigit hexdigit) hexstring = 1*(hexdigit hexdigit)
hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
number = 1*DIGIT number = 1*DIGIT
ALPHA = %x41-5A / %x61-7A ALPHA = %x41-5A / %x61-7A
DIGIT = %x30-39 DIGIT = %x30-39
The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
ALPHA rules originally defined in [RFC5234], exactly as defined ALPHA rules originally defined in [RFC5234], exactly as defined
there. there.
The device identity namespace includes three subtypes (see Section 4, The device identity namespace includes three subtypes (see Section 4,
and more may be defined in the future as specified in Section 7. and more may be defined in the future as specified in Section 7.
The optional underscore-separated components following the hexstring The optional underscore-separated components following the hexstring
are strings depicting individual aspects of a device. The specific are strings depicting individual aspects of a device. The specific
strings and their semantics are up to the designers of the device, strings and their semantics are up to the designers of the device,
but could be used to refer to specific interfaces or functions within but could be used to refer to specific interfaces or functions within
the device. the device.
With the exception of the MAC-address and 1-Wire DEV URNs, each DEV With the exception of the MAC-address and 1-Wire DEV URNs, each DEV
URN may also contain optional colon-separated identifiers. These are URN may also contain optional colon-separated identifiers. These are
provided for extensibility. provided for extensibility.
There are no special character encoding rules or considerations for There are no special character encoding rules or considerations for
comforming with the URN syntax, beyond those applicable for URNs in conforming with the URN syntax, beyond those applicable for URNs in
general [RFC8141], or the context where these URNs are carried (e.g., general [RFC8141], or the context where these URNs are carried (e.g.,
inside JSON [RFC8259] or SenML [RFC8428]). inside JSON [RFC8259] or SenML [RFC8428]).
The DEV URN syntax allows both upper and lower case characters. The
lexical equivalence of the DEV URNs is defined as an exact and case
sensitive string match. Character case is not otherwise significant
for the DEV URN subtypes defined in this document. Future subtypes
might use identifiers that require other encodings that require a
more full-blown character set (such as BASE64). To facilitate
equivalence checks, it is RECOMMENDED that implementations always use
lower case 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 upper case and lower case
letters.)
DEV URNs do not use r-, q-, or f-components. DEV URNs do not use r-, q-, or f-components.
Specific subtypes of DEV URNs may be validated through mechanisms Specific subtypes of DEV URNs may be validated through mechanisms
discussed in Section 4. discussed in Section 4.
Finally, the string representation of the device identity URN and of The string representation of the device identity URN and of the MEID
the MEID sub namespace is fully compatible with the URN syntax. sub namespace is fully compatible with the URN syntax.
3.2.1. Character Case and URN-Equivalence
The DEV URN syntax allows both upper and lower case 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"), namespace identifier ("dev"), and any percent-encoded
characters. 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 not be found URN-equivalent according to the RFC
8141 definition. For instance, in the ABNF syntax strings are case-
insensitive, 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 encode strings
in a larger variety of characters, and might even encode binary data.
To facilitate equivalence checks, it is RECOMMENDED that
implementations always use lower case 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 upper case and lower case letters.)
3.3. Assignment 3.3. Assignment
Assignment: The process for identifier assignment is dependent on the Assignment: The process for identifier assignment is dependent on the
used subtype, and documented in the specific subsection under used subtype, and documented in the specific subsection under
Section 4. Section 4.
Device identifiers are generally expected to be unique, barring the Device identifiers are generally expected to be unique, barring the
accidental issue of multiple devices with the same identifiers. accidental issue of multiple devices with the same identifiers. In
many cases, device identifiers can also be changed by users, or
sometimes assigned in an algorithmic 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.
This URN type SHOULD only be used for persistent identifiers, such as The DEV URN type SHOULD only be used for persistent identifiers, such
hardware-based identifiers or cryptographic identifiers based on keys as hardware-based identifiers or cryptographic identifiers based on
intended for long-term usage. keys intended for long-term usage.
3.4. Security and Privacy 3.4. Security and Privacy
Security and Privacy: As discussed in Section 6, care must be taken Security and Privacy: As discussed in Section 6, care must be taken
to use device identifier-based identifiers due to their nature as a in the use of device-identifier-based identifiers due to their nature
long-term identifier that is often not changeable. Leakage of these as long-term identifiers that are not normally changeable. Leakage
identifiers outside systems where their use is justified should be of these identifiers outside systems where their use is justified
controlled. should be controlled.
3.5. Interoperability 3.5. Interoperability
Interoperability: There are no specific interoperability concerns. Interoperability: There are no specific interoperability concerns.
3.6. Resolution 3.6. Resolution
Resolution: The device identities are not expected to be globally Resolution: The device identities are not expected to be globally
resolvable. No identity resolution system is expected. Systems may resolvable. No identity resolution system is expected. Systems may
perform local matching of identities to previously seen identities or perform local matching of identities to previously seen identities or
skipping to change at page 8, line 48 skipping to change at page 9, line 23
Editor's Note (Please remove before publication): The DEV URN "os" Editor's Note (Please remove before publication): The DEV URN "os"
subtype has originally been defined in the LwM2M standard, but has subtype has originally been defined in the LwM2M standard, but has
been incorporated here to collect all syntax associated with DEV been incorporated here to collect all syntax associated with DEV
URNs in one place. At the same time, the syntax of this subtype URNs in one place. At the same time, the syntax of this subtype
was changed to avoid the possibility of characters that are not was changed to avoid the possibility of characters that are not
allowed in SenML Name field (see [RFC8428] Section 4.5.1). allowed in SenML Name field (see [RFC8428] Section 4.5.1).
When included in an "os" DEV URN, the PEN number MUST NOT be When included in an "os" DEV URN, the PEN number MUST NOT be
padded with extra leading zeroes. Organizations are also padded with extra leading zeroes. Organizations are also
encouraged to select serial number formats that avoid possibility encouraged to select serial number formats that avoid possibility
for ambiquity, in the form of leading zeroes or otherwise. for ambiguity, in the form of leading zeroes or otherwise.
Organization serial number DEV URNs consist of the PEN number and the Organization serial number DEV URNs consist of the PEN number and the
serial number. As with other DEV URNs, for carrying additional serial number. As with other DEV URNs, for carrying additional
information and extensibility, optional colon-separated identifiers information and extensibility, optional colon-separated identifiers
and underscore-separated components may also be included. The serial and underscore-separated components may also be included. The serial
numbers themselves are defined by the organization, and this numbers themselves are defined by the organization, and this
specification does not specify how they are allocated. specification does not specify how they are allocated.
4.5. Organization Product and Serial Numbers 4.5. Organization Product and Serial Numbers
skipping to change at page 9, line 33 skipping to change at page 10, line 8
number, product class, and the serial number. As with other DEV number, product class, and the serial number. As with other DEV
URNs, for carrying additional information and extensibility, optional URNs, for carrying additional information and extensibility, optional
colon-separated identifiers and underscore-separated components may colon-separated identifiers and underscore-separated components may
also be included. Both the product class and serial numbers also be included. Both the product class and serial numbers
themselves are defined by the organization, and this specification themselves are defined by the organization, and this specification
does not specify how thy are allocated. does not specify how thy are allocated.
When included in an "ops" DEV URN, the PEN number MUST NOT be padded When included in an "ops" DEV URN, the PEN number MUST NOT be padded
with extra leading zeroes. Organizations are also encouraged to with extra leading zeroes. Organizations are also encouraged to
select product and serial number formats that avoid possibility for select product and serial number formats that avoid possibility for
ambiquity. ambiguity.
5. Examples 5. Examples
The following three examples provide examples of MAC-based, 1-Wire, The following three examples provide examples of MAC-based, 1-Wire,
and Cryptographic identifiers: and Cryptographic identifiers:
urn:dev:mac:0024beffff804ff1 # The MAC-48 address of urn:dev:mac:0024beffff804ff1 # The MAC-48 address of
# 0024be804ff1, converted # 0024be804ff1, converted
# to EUI-64 format # to EUI-64 format
skipping to change at page 11, line 5 skipping to change at page 12, line 5
# subtype # subtype
6. Security Considerations 6. Security Considerations
On most devices, the user can display device identifiers. Depending On most devices, the user can display device identifiers. Depending
on circumstances, device identifiers may or may not be modified or on circumstances, device identifiers may or may not be modified or
tampered with by the user. An implementation of the DEV URN MUST NOT tampered with by the user. An implementation of the DEV URN MUST NOT
change these properties from what they were intended. In particular, change these properties from what they were intended. In particular,
a device identifier that is intended to be immutable should not a device identifier that is intended to be immutable should not
become mutable as a part of implementing the DEV URN type. More become mutable as a part of implementing the DEV URN type. More
generally, nothing in this memo should be construed to override what generally, nothing in this document should be construed to override
the relevant device specifications have already said about the what the relevant device specifications have already said about the
identifiers. identifiers.
6.1. Privacy 6.1. Privacy
Other devices in the same network may or may not be able to identify Other devices in the same network may or may not be able to identify
the device. For instance, on Ethernet network, the MAC address of a the device. For instance, on an Ethernet network, the MAC address of
device is visible to all other devices. a device is visible to all other devices.
The URNs generated according to the rules defined in this document The URNs generated according to the rules defined in this document
result in long-term stable unique identifiers for the devices. Such result in long-term stable unique identifiers for the devices. Such
identifiers may have privacy and security implications because they identifiers may have privacy and security implications because they
may enable correlating information about a specific device over a may enable correlating information about a specific device over a
long period of time, location tracking, and device specific long period of time, location tracking, and device specific
vulnerability exploitation [RFC7721]. Also, usually there is no easy vulnerability exploitation [RFC7721]. Also, usually there is no easy
way to change the identifier. Therefore these identifiers need to be way to change the identifier. Therefore these identifiers need to be
used with care and especially care should be taken to avoid leaking used with care and especially care should be taken to avoid leaking
them outside of the system that is intended to use the identifiers. them outside of the system that is intended to use the identifiers.
7. IANA Considerations 7. IANA Considerations
This document requests the registration of a new URN namespace for This document requests the registration of a new URN namespace for
"DEV", as described in Section 3. "DEV", as described in Section 3.
Additional subtypes for DEV URNs can be defined through Specification IANA is asked to create a "DEV URN Subtypes" registry. The initial
Required or IESG Approval [RFC8126]. values in this registry are as follows:
Such allocations are appropriate when there is a new namespace of Subtype Description Reference
some type of device identifiers, defined in stable fashion and with a ------------------------------------------------------------------------
publicly available specification that can be pointed to. mac MAC Addresses (THIS RFC) Section 4.1
ow 1-Wire Device Identifiers (THIS RFC) Section 4.2
org Organization-Defined Identifiers (THIS RFC) Section 4.3
os Organization Serial Numbers (THIS RFC) Section 4.4
ops Organization Product and Serial Numbers (THIS RFC) Section 4.5
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
identifiers, defined in stable fashion and with a publicly available
specification that can be pointed to.
Note that the organisation (Section 4.3) device identifiers can also Note that the organisation (Section 4.3) device identifiers can also
be used in some cases, at least as a temporary measure. It is be used in some cases, at least as a temporary measure. It is
preferable, however, that long-term usage of a broadly employed preferable, however, that long-term usage of a broadly employed
device identifier be registered with IETF rather than used through device identifier be registered with IETF rather than used through
the organisation device identifier type. the organisation device identifier type.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 14, line 20 skipping to change at page 15, line 35
<https://www.rfc-editor.org/info/rfc7254>. <https://www.rfc-editor.org/info/rfc7254>.
[RFC8464] Atarius, R., "A URN Namespace for Device Identity and [RFC8464] Atarius, R., "A URN Namespace for Device Identity and
Mobile Equipment Identity (MEID)", RFC 8464, Mobile Equipment Identity (MEID)", RFC 8464,
DOI 10.17487/RFC8464, September 2018, <https://www.rfc- DOI 10.17487/RFC8464, September 2018, <https://www.rfc-
editor.org/info/rfc8464>. editor.org/info/rfc8464>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-24 (work in progress), March 2020. resource-directory-25 (work in progress), July 2020.
Appendix A. Changes from Previous Version Appendix A. Changes from Previous Version
Version -08 of the WG draft took into account Barry Leiba's AD review
comments. To address these comments, changes were made in
o Further updates of the upper/lower case rules for the DEV URNs.
o Further updates to the ABNF.
o The use of HEXDIG from RFC 5234.
o IANA considerations for the creation of separate registry for the
own parameters of DEV URNs.
o Editorial improvements.
Version -07 of the WG draft took into account Carsten Bormann's Version -07 of the WG draft took into account Carsten Bormann's
feedback, primarily on character case issues and editorials. feedback, primarily on character case issues and editorials.
Version -06 of the WG draft took into account Marco Tiloca's feedback Version -06 of the WG draft took into account Marco Tiloca's feedback
before a second WGLC, primarily on further cleanup of references and before a second WGLC, primarily on further cleanup of references and
editorial issues. editorial issues.
Version -05 of the WG draft made some updates based on WGLC input: 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 examples for MAC-48 and EUI-48, clarification with regards to leading
zeroes, new recommendation with the use of lower-case letters to zeroes, new recommendation with the use of lower-case letters to
skipping to change at page 15, line 21 skipping to change at page 16, line 49
numbers and the use of product classes and serial numbers was better numbers and the use of product classes and serial numbers was better
explained. explained.
Version -03 of the WG draft removed some unnecessary references, Version -03 of the WG draft removed some unnecessary references,
updated some other references, removed pct-encoding to ensure the DEV updated some other references, removed pct-encoding to ensure the DEV
URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the
original source of the "os" and "ops" subtypes. original source of the "os" and "ops" subtypes.
Version -02 of the WG draft folded in the "ops" and "os" branches of 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 the dev:urn syntax from LwM2M, as they seemed to match well what
already existed in this memo under the "org" branch. However, as a already existed in this document under the "org" branch. However, as
part of this three changes were incorporated: a part of this three changes were incorporated:
o The syntax for the "org:" changes to use "-" rather than ":" o The syntax for the "org:" changes to use "-" rather than ":"
between the OUI and the rest of the URN. between the OUI and the rest of the URN.
o The organizations for the "ops" and "os" branches have been o The organizations for the "ops" and "os" branches have been
changed to use PEN numbers rather than OUI numbers [OUI]. The changed to use PEN numbers rather than OUI numbers [OUI]. The
reason for this is that PEN numbers are allocated through a reason for this is that PEN numbers are allocated through a
simpler and less costly process. However, this is a significant simpler and less costly process. However, this is a significant
change to how LwM2M identifiers were specified before. change to how LwM2M identifiers were specified before.
skipping to change at page 16, line 46 skipping to change at page 18, line 27
rest of the URN can employ the unreserved characters [RFC3986]. rest of the URN can employ the unreserved characters [RFC3986].
Version -03 made several minor corrections to the ABNF as well as Version -03 made several minor corrections to the ABNF as well as
some editorial corrections. some editorial corrections.
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Ari Keranen, Stephen Farrell, The authors would like to thank Ari Keranen, Stephen Farrell,
Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez,
Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim
Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, and Ahmad Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba,
Muhanna for interesting discussions in this problem space. We would and Ahmad Muhanna for feedback and interesting discussions in this
also like to note prior documents that focused on specific device problem space. We would also like to note prior documents that
identifiers, such as [RFC7254] or [RFC8464]. focused on specific device identifiers, such as [RFC7254] or
[RFC8464].
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
 End of changes. 34 change blocks. 
72 lines changed or deleted 119 lines changed or added

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