Uniform Resource Names for Device Identifiers
draft-arkko-core-dev-urn-00

Abstract

This memo 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 equipment inventories. A URN-based representation can be easily passed along in any application that needs the information.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on February 2, 2012.

Copyright Notice

Copyright (c) 2011 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 (http://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.  DEV URN Definition
3.  DEV URN Subtypes
    3.1.  EUI-48 and EUI-64 MAC Addresses
    3.2.  1-Wire Device Identifiers
    3.3.  3GPP IMEIs
    3.4.  3GPP MEIDs
4.  Examples
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Acknowledgments
§  Authors' Addresses

1.  Introduction

This memo describes a new Uniform Resource Name (URN) [RFC2141] (Moats, R., “URN Syntax,” May 1997.) [RFC3406] (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) 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 equipment inventories [I‑D.ietf‑core‑coap] (Shelby, Z., Hartke, K., Bormann, C., and B. Frank, “Constrained Application Protocol (CoAP),” May 2011.), [I‑D.jennings‑senml] (Jennings, C., “Media Type for Sensor Markup Language (SENML),” July 2011.), [I‑D.arkko‑core‑sleepy‑sensors] (Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O. Novo, “Implementing Tiny COAP Sensors,” July 2011.) [I‑D.arkko‑core‑security‑arch] (Arkko, J. and A. Keranen, “CoAP Security Architecture,” July 2011.). 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 [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.), [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), [I‑D.ietf‑core‑coap] (Shelby, Z., Hartke, K., Bormann, C., and B. Frank, “Constrained Application Protocol (CoAP),” May 2011.). Finally, URNs can also be easily carried and stored in formats such as XML [W3C.REC‑xml‑19980210] (Sperberg-McQueen, C., Paoli, J., and T. Bray, “XML 1.0 Recommendation,” February 1998.) or JSON [I‑D.jennings‑senml] (Jennings, C., “Media Type for Sensor Markup Language (SENML),” July 2011.) [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.). Using URNs in these formats is often preferrable as they are universally recognized, self-describing, and therefore avoid the need for agreeing to interprete an octet string as a specific form of a MAC address, for instance.

The rest of this memo is organized as follows. Section 2 (DEV URN Definition) defines the "DEV" URN type, and Section 3 (DEV URN Subtypes) defines subtypes for IEEE EUI-48 and EUI-64 MAC addresses, 3GPP IMEI (International Mobile station Equipment Identity) identifiers, 3GPP MEIDs (Mobile Equipment IDentifier), and 1-wire device identifiers. Section 4 (Examples) gives examples. Section 5 (Security Considerations) discusses the security considerations of the new URN type. Finally, Section 6 (IANA Considerations) specifies the IANA registration for the new URN type and sets requirements for subtype allocations within this type.

2.  DEV URN Definition

Namespace ID: "dev" requested

Registration Information:

Registration version number: 1

Registration date: 2011-08-26

Declared registrant of the namespace: IETF

Declaration of syntactic structure: The identifier is expressed in ASCII (UTF-8) characters and has a hierarchical structure as follows:

 devurn = "urn:dev:" subtype ":" hexstring
 subtype = "mac" / "ow" / "imei" / "meid" / ext-subtype
 ext-subtype = 1*8<alphanum> ; future extentions need to match this gramar
 alphanum  =  ALPHA / DIGIT

 hexstring = 1*<hexbyte> ; TODO - should we limit the length of this
 hexbyte = hexdigit hexdigit
 hexdigit = DIGIT / hexletter
 hexletter = "a" / "b" / "c" / "d" / "e" / "f" /
             "A" / "B" / "C" / "D" / "E" / "F"

The above Augmented Backus-Naur Form (ABNF) uses the DIGIT rule defined in [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.), which is not repeated here.

TODO: Should we only allow lower case?

TODO: Should we add an optional one byte checksum at end that can check for entry error when humans are invovled?

The device identity namespace includes four subtypes, and more may be defined in the future as specified in Section 6 (IANA Considerations).

Identifier uniqueness considerations: Device identifiers are generally expected to be unique, barring the accidental issue of multiple devices with the same identifiers.

Identifier persistence considerations: ...

Process of identifier assignment: ...

Process for identifier 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.

Rules for Lexical Equivalence: The lexical equivalence of the DEV URN is defined as an exact, but not case-sensitive, string match.

Conformance with URN Syntax: The string representation of the device identity URN and of the MEID sub namespace is fully compatible with the URN syntax.

Validation Mechanism: Specific subtypes may be validated through mechanisms discussed in Section 3 (DEV URN Subtypes).

Scope: DEV URN is global in scope.

3.  DEV URN Subtypes

3.1.  EUI-48 and EUI-64 MAC Addresses

3.2.  1-Wire Device Identifiers

3.3.  3GPP IMEIs

3.4.  3GPP MEIDs

4.  Examples

5.  Security Considerations

On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered by the user. An implementation of the DEV URN MUST NOT change these properties from what they were intended. 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 memo should be construed to override what the relevant device specifications have already said about the identifiers.

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 device is visible to all other devices. But on cellular networks identity privacy mechanisms hide device identities from devices other than the network infrastructure itself.

6.  IANA Considerations

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Acknowledgments

The authors would like to thank Zach Selby for interesting discussions in this problem space. We would also like to note prior documents that focused on specific device identifiers, such as [I‑D.montemurro‑gsma‑imei‑urn] (Montemurro, M., Allen, A., McDonald, D., and P. Gosden, “A Uniform Resource Name Namespace for the GSM Association (GSMA) and the International Mobile station Equipment Identity (IMEI),” July 2011.) or [I‑D.atarius‑dispatch‑meid‑urn] (Atarius, R., “A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID),” August 2011.).

Authors' Addresses