Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                               C. Jennings
Expires: February 28, 2, 2012                                          Cisco
                                                             August 27, 2011

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

1.  Introduction

   This memo describes a new Uniform Resource Name (URN) [RFC2141]
   [RFC3406] 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], [I-D.jennings-senml],
   [I-D.arkko-core-sleepy-sensors] [I-D.arkko-core-security-arch].  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], [RFC3261],
   [I-D.ietf-core-coap].  Finally, URNs can also be easily carried and
   stored in formats such as XML [W3C.REC-xml-19980210] or JSON
   [I-D.jennings-senml] [RFC4627].  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 defines the
   "DEV" URN type, and Section 3 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 gives
   examples.  Section 5 discusses the security considerations of the new
   URN type.  Finally, Section 6 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"
    hexstring / ext-subtype
 ext-subtype = hexbyte 1*8<alphanum> ; future extentions need to match this gramar
 alphanum  =  ALPHA /
                  hexbyte 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], 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.

   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.

   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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

7.2.  Informative References

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [W3C.REC-xml-19980210]
              Sperberg-McQueen, C., Paoli, J., and T. Bray, "XML 1.0
              Recommendation", World Wide Web Consortium
              FirstEdition REC-xml-19980210, February 1998,
              <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [I-D.ietf-core-coap]
              Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
              "Constrained Application Protocol (CoAP)",
              draft-ietf-core-coap-06 (work in progress), May 2011.

   [I-D.jennings-senml]
              Jennings, C., "Media Type for Sensor Markup Language
              (SENML)", draft-jennings-senml-06 (work in progress),
              July 2011.

   [I-D.arkko-core-sleepy-sensors]
              Arkko, J., Rissanen, H., Loreto, S., Turanyi, Z., and O.
              Novo, "Implementing Tiny COAP Sensors",
              draft-arkko-core-sleepy-sensors-01 (work in progress),
              July 2011.

   [I-D.arkko-core-security-arch]
              Arkko, J. and A. Keranen, "CoAP Security Architecture",
              draft-arkko-core-security-arch-00 (work in progress),
              July 2011.

   [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)", draft-montemurro-gsma-imei-urn-08 (work
              in progress), July 2011.

   [I-D.atarius-dispatch-meid-urn]
              Atarius, R., "A Uniform Resource Name Namespace for the
              Device Identity and the Mobile Equipment Identity (MEID)",
              draft-atarius-dispatch-meid-urn-01 (work in progress),
              August 2011.

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] or [I-D.atarius-dispatch-meid-urn].

Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net

   Cullen Jennings
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 408 421-9990
   Email: fluffy@cisco.com