draft-ietf-core-dev-urn-05.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: December 26, 2020 Cisco Expires: January 2, 2021 Cisco
Z. Shelby Z. Shelby
ARM ARM
June 24, 2020 July 1, 2020
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-05 draft-ietf-core-dev-urn-06
Abstract Abstract
This memo describes a new Uniform Resource Name (URN) namespace for This memo describes a new Uniform Resource Name (URN) namespace for
hardware device identifiers. A general representation of device hardware device identifiers. A general representation of device
identity can be useful in many applications, such as in sensor data identity can be useful in many applications, such as in sensor data
streams and storage, or equipment inventories. A URN-based streams and storage, or 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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 December 26, 2020. This Internet-Draft will expire on January 2, 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 20 skipping to change at page 2, line 20
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.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6 3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6
3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6 3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6
3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 7
4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8
4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8
4.5. Organization Product and Serial Numbers . . . . . . . . . 9 4.5. Organization Product and Serial Numbers . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security and Privacy Considerations . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from Previous Version . . . . . . . . . . . 14 Appendix A. Changes from Previous Version . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This memo describes a new Uniform Resource Name (URN) [RFC8141] This memo 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, or equipment inventories [RFC7252], sensor data streams and storage [RFC8428], or equipment inventories
[RFC8428]. A URN-based representation can be easily passed along in [RFC7252], [I-D.ietf-core-resource-directory].
any application that needs the information, as it fits in protocols
A URN-based representation can be easily passed along in any
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
[RFC8428] [RFC4627]. 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, 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 memo defines identity URN types for situations where no such
convenient type already exist. For instance, [RFC6920] defines convenient type already exist. 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
skipping to change at page 3, line 27 skipping to change at page 3, line 30
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 memo is recommended for
constrained environments. constrained environments.
Future device identifier types can extend the device device URN type Future device identifier types can extend the device URN type defined
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 memo is organized as follows. Section 3 defines the
"DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, "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 considerations of gives examples. Section 6 discusses the security and privacy
the new URN type. Finally, Section 7 specifies the IANA registration considerations of the new URN type. Finally, Section 7 specifies the
for the new URN type and sets requirements for subtype allocations IANA registration for the new URN type and sets requirements for
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
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. DEV URN Definition 3. DEV URN Definition
skipping to change at page 5, line 28 skipping to change at page 5, line 28
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 original defined in [RFC5234], exactly as defined there. ALPHA rules originally defined in [RFC5234], exactly as defined
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.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
# dashes in it # dashes in it
urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial
# number 5002 in the # number 5002 in the
# RFC 5612 example # RFC 5612 example
# organisation # organisation
urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined
# subtype # subtype
6. Security and Privacy 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 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 memo should be construed to override what
the relevant device specifications have already said about the the relevant device specifications have already said about the
identifiers. identifiers.
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 Ethernet network, the MAC address of a
device is visible to all other devices. 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
skipping to change at page 13, line 10 skipping to change at page 13, line 10
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, <https://www.rfc- DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
editor.org/info/rfc3261>. editor.org/info/rfc3261>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005, <https://www.rfc- DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
editor.org/info/rfc4122>. editor.org/info/rfc4122>.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627,
DOI 10.17487/RFC4627, July 2006, <https://www.rfc-
editor.org/info/rfc4627>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, <https://www.rfc- DOI 10.17487/RFC7540, May 2015, <https://www.rfc-
editor.org/info/rfc7540>. editor.org/info/rfc7540>.
skipping to change at page 14, line 22 skipping to change at page 14, line 17
System for Mobile Communications Association (GSMA) and System for Mobile Communications Association (GSMA) and
the International Mobile station Equipment Identity the International Mobile station Equipment Identity
(IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
<https://www.rfc-editor.org/info/rfc7254>. <https://www.rfc-editor.org/info/rfc7254>.
[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]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-24 (work in progress), March 2020.
Appendix A. Changes from Previous Version Appendix A. Changes from Previous Version
Version -06 of the WG draft took into account Marco Tiloca's feedback
before a second WGLC, primarily on further cleanup of references and
editorial issues.
Version -05 of the WG draft made some updates based on WGLC input: 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
avoid comparison problems, small update of the RFC 8141 template avoid comparison problems, small update of the RFC 8141 template
usage, reference updates, and editorial corrections. usage, reference updates, and editorial corrections.
Version -04 of the WG draft cleaned up the ABNF: Version -04 of the WG draft cleaned up the ABNF:
o Parts of the ANBF now allow for use cases for the component part o Parts of the ANBF now allow for use cases for the component part
that were not previously covered: the syntax now allows the that were not previously covered: the syntax now allows the
 End of changes. 17 change blocks. 
24 lines changed or deleted 34 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/