draft-ietf-core-dev-urn-00.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: September 6, 2018 Cisco Expires: September 2, 2018 Cisco
Z. Shelby Z. Shelby
Sensinode ARM
March 5, 2018 March 2018
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-00 draft-ietf-core-dev-urn-01
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 September 6, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 14 skipping to change at page 2, line 14
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . 3 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 3
4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 6 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Organization-Defined Identifiers . . . . . . . . . . . . 6 3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.8. Additional Information . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 3.9. Revision Information . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 9 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. Changes from Previous Version . . . . . . . . . . . 10 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 11 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 7
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Changes from Previous Version . . . . . . . . . . . 12
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This memo describes a new Uniform Resource Name (URN) [RFC8141] This memo describes a new Uniform Resource Name (URN) [RFC8141]
[RFC3406] namespace for hardware device identifiers. A general [RFC3406] namespace for hardware device identifiers. A general
representation of device identity can be useful in many applications, representation of device identity can be useful in many applications,
such as in sensor data streams and storage, or equipment inventories such as in sensor data streams and storage, or equipment inventories
[RFC7252], [I-D.ietf-core-senml]. A URN-based representation can be [RFC7252], [I-D.ietf-core-senml]. A URN-based representation can be
easily passed along in any application that needs the information, as easily passed along in any application that needs the information, as
it fits in protocols mechanisms that are designed to carry URNs it fits in protocols mechanisms that are designed to carry URNs
skipping to change at page 3, line 49 skipping to change at page 3, line 49
within this type. within this type.
2. Requirements language 2. Requirements language
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
"RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [RFC2119]. described in [RFC2119].
3. DEV URN Definition 3. DEV URN Definition
Namespace ID: "dev" requested Namespace Identifier: "dev" requested
Version: 1
Date: 2018-03-19
Registration Information: This is the first registration of this Registration Information: This is the first registration of this
namespace, 2011-08-27. namespace, 2018-03-19.
Registration version number: 1 Registrant: IETF and the CORE working group. Should the working
group cease to exist, discussion should be directed to the general
IETF discussion forums or the IESG.
Registration date: 2011-08-27 3.1. Purpose
Declared registrant of the namespace: IETF and the CORE working Purpose: The DEV URNs identify devices with device-specific
group. Should the working group cease to exist, discussion should be identifiers such as network card hardware addresses. These URNs may
directed to the general IETF discussion forums or the IESG. be used in any relevant networks that benefit from the ability to
refer to these identifiers in the form of URNs; DEV URN is global in
scope.
Declaration of syntactic structure: The identifier is expressed in Some typical applications include equipment inventories and smart
ASCII characters and has a hierarchical structure as follows: 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 identity fields in local link communication. However, it is
often useful to be able to pass device identity information in
generic URN fields in databases or protocol fields, which makes the
use of URNs for this purpose convenient.
The DEV URN name space complements existing name spaces such as those
involving IMEI or UUID identifiers. DEV URNs are expeced 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
Syntax: The identifier is expressed in ASCII characters and has a
hierarchical structure as follows:
devurn = "urn:dev:" body componentpart devurn = "urn:dev:" body componentpart
body = macbody / owbody / orgbody / otherbody body = macbody / owbody / orgbody / otherbody
macbody = "mac:" hexstring macbody = "mac:" hexstring
owbody = "ow:" hexstring owbody = "ow:" hexstring
orgbody = "org:" number ":" identifier orgbody = "org:" number ":" identifier
otherbody = subtype ":" identifier otherbody = subtype ":" identifier
subtype = ALPHA *(DIGIT / ALPHA) subtype = ALPHA *(DIGIT / ALPHA)
identifier = 1*unreservednout identifier = 1*unreservednout
unreservednout = ALPHA / DIGIT / "-" / "." unreservednout = ALPHA / DIGIT / "-" / "."
skipping to change at page 4, line 38 skipping to change at page 5, line 22
hexbyte hexstring hexbyte hexstring
hexbyte = hexdigit hexdigit hexbyte = hexdigit hexdigit
hexdigit = DIGIT / hexletter hexdigit = DIGIT / hexletter
hexletter = "a" / "b" / "c" / "d" / "e" / "f" hexletter = "a" / "b" / "c" / "d" / "e" / "f"
number = *1DIGIT number = *1DIGIT
The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA
rules defined in [RFC5234], which are not repeated here. The rule rules defined in [RFC5234], which are not repeated here. The rule
for unreserved is defined in Section 2.3 of [RFC3986]. for unreserved is defined in Section 2.3 of [RFC3986].
The device identity namespace includes three subtypes, and more may The device identity namespace includes three subtypes (see Section 4,
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 components following the hexstring are strings depicting The optional components following the hexstring are strings depicting
individual aspects of a device. The specific strings and their individual aspects of a device. The specific strings and their
semantics are up to the designers of the device, but could be used to semantics are up to the designers of the device, but could be used to
refer to specific interfaces or functions within the device. refer to specific interfaces or functions within the device.
Relevant ancillary documentation: See Section 4. There are no special character encoding rules or considerations for
comforming 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 [I-D.ietf-core-senml]).
Identifier uniqueness considerations: Device identifiers are The lexical equivalence of the DEV URNs is defined as an exact and
generally expected to be unique, barring the accidental issue of case sensitive string match. Note that the two subtypes defined in
multiple devices with the same identifiers. this document use only lower case letters, however. Future types
might use identifiers that require other encodings that require a
more full-blown character set (such as BASE64), however.
Identifier persistence considerations: This URN type SHOULD only be DEV URNs do not use r-, q-, or f-components.
used for persistent identifiers, such as hardware-based identifiers
or cryptographic identifiers based on keys intended for long-term
usage.
Process of identifier assignment: The process for identifier Specific subtypes of DEV URNs may be validated through mechanisms
assignment is dependent on the used subtype, and documented in the discussed in Section 4.
specific subsection under Section 4.
Process for identifier resolution: The device identities are not Finally, the string representation of the device identity URN and of
expected to be globally resolvable. No identity resolution system is the MEID sub namespace is fully compatible with the URN syntax.
expected. Systems may perform local matching of identities to
previously seen identities or configured information, however.
Rules for Lexical Equivalence: The lexical equivalence of the DEV URN 3.3. Assignment
is defined as an exact and case sensitive string match. Note that Assignment: The process for identifier assignment is dependent on the
the two subtypes defined in this document use only lower case used subtype, and documented in the specific subsection under
letters, however. Future types might use identifiers that require Section 4.
other encodings that require a more full-blown character set (such as
BASE64), however.
Conformance with URN Syntax: The string representation of the device Device identifiers are generally expected to be unique, barring the
identity URN and of the MEID sub namespace is fully compatible with accidental issue of multiple devices with the same identifiers.
the URN syntax.
Validation Mechanism: Specific subtypes may be validated through This URN type SHOULD only be used for persistent identifiers, such as
mechanisms discussed in Section 4. hardware-based identifiers or cryptographic identifiers based on keys
intended for long-term usage.
Scope: DEV URN is global in scope. 3.4. Security and Privacy
Security and Privacy: As discussed in Section 6, care must be taken
to use device identifier-based identifiers due to their nature as a
long-term identifier that is often not changeable. Leakage of these
identifiers outside systems where their use is justfied should be
controlled.
3.5. Interoperability
Interoperability: There are no specific interoperability concerns.
3.6. Resolution
Resolution: The device identities are not expected to be globally
resolvable. No identity resolution system is expected. Systems may
perform local matching of identities to previously seen identities or
configured information, however.
3.7. Documentation
See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the
RFC number of this document).
3.8. Additional Information
See Section 1 for a discussion of related name spaces.
3.9. Revision Information
Revision Information: This is the first version of this registration.
4. DEV URN Subtypes 4. DEV URN Subtypes
4.1. MAC Addresses 4.1. MAC Addresses
DEV URNs of the "mac" subtype are based on the EUI-64 identifier 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. [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 The EUI-64 is formed from 24 or 36 bits of organization identifier
followed by 40 or 28 bits of device-specific extension identifier followed by 40 or 28 bits of device-specific extension identifier
assigned by that organization. assigned by that organization.
skipping to change at page 10, line 7 skipping to change at page 11, line 24
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for
Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August
2009, <https://www.rfc-editor.org/info/rfc5612>. 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www
.rfc-editor.org/info/rfc7721>. .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>.
[W3C.REC-xml-19980210] [W3C.REC-xml-19980210]
Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0
Recommendation", World Wide Web Consortium FirstEdition Recommendation", World Wide Web Consortium FirstEdition
REC-xml-19980210, February 1998, REC-xml-19980210, February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210>. <http://www.w3.org/TR/1998/REC-xml-19980210>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
RFC7252, June 2014, <https://www.rfc-editor.org/info/ RFC7252, June 2014, <https://www.rfc-editor.org/info/
rfc7252>. rfc7252>.
skipping to change at page 10, line 44 skipping to change at page 12, line 17
//www.rfc-editor.org/info/rfc7254>. //www.rfc-editor.org/info/rfc7254>.
[I-D.atarius-dispatch-meid-urn] [I-D.atarius-dispatch-meid-urn]
Atarius, R., "A Uniform Resource Name Namespace for the Atarius, R., "A Uniform Resource Name Namespace for the
Device Identity and the Mobile Equipment Identity (MEID)", Device Identity and the Mobile Equipment Identity (MEID)",
draft-atarius-dispatch-meid-urn-15 (work in progress), draft-atarius-dispatch-meid-urn-15 (work in progress),
January 2018. January 2018.
Appendix A. Changes from Previous Version Appendix A. Changes from Previous Version
Version -01 of the WG draft converted the draft to use the new URN
registration template from [RFC8141].
Version -00 of the WG draft renamed the file name and fixed the ABNF Version -00 of the WG draft renamed the file name and fixed the ABNF
to correctly use "org:" rather than "dn:". to correctly use "org:" rather than "dn:".
Version -05 made a change to the delimiter for parameters within a Version -05 made a change to the delimiter for parameters within a
DEV URN. Given discussions on allowed character sets in SenML DEV URN. Given discussions on allowed character sets in SenML
[I-D.ietf-core-senml], we would like to suggest that the "_" [I-D.ietf-core-senml], we would like to suggest that the "_"
character be used instead of ";", to avoid the need to translate DEV character be used instead of ";", to avoid the need to translate DEV
URNs in SenML-formatted communications or files. However, this URNs in SenML-formatted communications or files. However, this
reverses the earlier decision to not use unreserved characters. This reverses the earlier decision to not use unreserved characters. This
also means that device IDs cannot use "_" characters, and have to also means that device IDs cannot use "_" characters, and have to
skipping to change at page 12, line 24 skipping to change at page 13, line 43
Cullen Jennings Cullen Jennings
Cisco Cisco
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421-9990 Phone: +1 408 421-9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Zach Shelby Zach Shelby
Sensinode ARM
Kidekuja 2 Kidekuja 2
Vuokatti 88600 Vuokatti 88600
FINLAND FINLAND
Phone: +358407796297 Phone: +358407796297
Email: zach@sensinode.com Email: Zach.Shelby@arm.com
 End of changes. 25 change blocks. 
57 lines changed or deleted 132 lines changed or added

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