[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-arkko-core-dev-urn) 00 01 02 03 04

Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Intended status: Informational                               C. Jennings
Expires: June 15, 2020                                             Cisco
                                                               Z. Shelby
                                                                     ARM
                                                       December 13, 2019


             Uniform Resource Names for Device Identifiers
                       draft-ietf-core-dev-urn-04

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 June 15, 2020.

Copyright Notice

   Copyright (c) 2019 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



Arkko, et al.             Expires June 15, 2020                 [Page 1]


Internet-Draft                   DEV URN                   December 2019


   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
   2.  Requirements language . . . . . . . . . . . . . . . . . . . .   3
   3.  DEV URN Definition  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Assignment  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Security and Privacy  . . . . . . . . . . . . . . . . . .   6
     3.5.  Interoperability  . . . . . . . . . . . . . . . . . . . .   6
     3.6.  Resolution  . . . . . . . . . . . . . . . . . . . . . . .   6
     3.7.  Documentation . . . . . . . . . . . . . . . . . . . . . .   6
     3.8.  Additional Information  . . . . . . . . . . . . . . . . .   7
     3.9.  Revision Information  . . . . . . . . . . . . . . . . . .   7
   4.  DEV URN Subtypes  . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  MAC Addresses . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  1-Wire Device Identifiers . . . . . . . . . . . . . . . .   7
     4.3.  Organization-Defined Identifiers  . . . . . . . . . . . .   8
     4.4.  Organization Serial Numbers . . . . . . . . . . . . . . .   8
     4.5.  Organization Product and Serial Numbers . . . . . . . . .   8
   5.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Changes from Previous Version  . . . . . . . . . . .  14
   Appendix B.  Acknowledgments  . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   This memo describes a new Uniform Resource Name (URN) [RFC8141]
   [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
   [RFC7252], [RFC8428].  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], [RFC7252].  Finally, URNs can also be easily
   carried and stored in formats such as XML [W3C.REC-xml-19980210] or
   JSON [RFC8428] [RFC4627].  Using URNs in these formats is often
   preferable as they are universally recognized, self-describing, and



Arkko, et al.             Expires June 15, 2020                 [Page 2]


Internet-Draft                   DEV URN                   December 2019


   therefore avoid the need for agreeing to interpret an octet string as
   a specific form of a MAC address, for instance.

   This memo defines identity URN types for situations where no such
   convenient type already exist.  For instance, [RFC6920] defines
   cryptographic identifiers, [RFC7254] defines International Mobile
   station Equipment Identity (IMEI) identifiers for use with 3GPP
   cellular systems, and [I-D.atarius-dispatch-meid-urn] defines Mobile
   Equipment Identity (MEID) identifiers for use with 3GPP2 cellular
   systems.  Those URN types should be employed when such identities are
   transported; this memo does not redefine these identifiers in any
   way.

   Universally Unique IDentifier (UUID) URNs [RFC4122] are another
   alternative way for representing device identifiers, and already
   support MAC addresses as one of type of an identifier.  However,
   UUIDs can be inconvenient in environments where it is important that
   the identifiers are as simple as possible and where additional
   requirements on stable storage, real-time clocks, and identifier
   length can be prohibitive.  UUID-based identifiers are recommended
   for all general purpose uses when MAC addresses are available as
   identifiers.  The device URN defined in this memo is recommended for
   constrained environments.

   Future device identifier types can extend the device device URN type
   defined here, or define their own URNs.

   Note that long-term stable unique identifiers are problematic for
   privacy reasons and should be used with care or avoided as described
   in [RFC7721].

   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,
   EUI-48 and EUI-64 addresses and 1-wire device identifiers.  Section 5
   gives examples.  Section 6 discusses the security considerations of
   the new URN type.  Finally, Section 7 specifies the IANA registration
   for the new URN type and sets requirements for subtype allocations
   within this type.

2.  Requirements language

   In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL",
   "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in [RFC2119].







Arkko, et al.             Expires June 15, 2020                 [Page 3]


Internet-Draft                   DEV URN                   December 2019


3.  DEV URN Definition

   Namespace Identifier: "dev" requested

   Version: 1

   Date: 2018-03-19

   Registration Information: This is the first registration of this
   namespace, 2018-03-19.

   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.

3.1.  Purpose

   Purpose: The DEV URNs identify devices with device-specific
   identifiers such as network card hardware addresses.  DEV URN is
   global in scope.

   Some typical applications include equipment inventories and smart
   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:




Arkko, et al.             Expires June 15, 2020                 [Page 4]


Internet-Draft                   DEV URN                   December 2019


     devurn = "urn:dev:" body componentpart
     body = macbody / owbody / orgbody / osbody / opsbody / otherbody
     macbody = "mac:" hexstring
     owbody = "ow:" hexstring
     orgbody = "org:" number "-" identifier *( ":"  identifier )
     osbody = "os:" number "-" serial *( ":"  identifier )
     opsbody = "ops:" number "-" product "-" serial *( ":"  identifier )
     otherbody = subtype ":" identifier *( ":"  identifier )
     subtype = ALPHA *(DIGIT / ALPHA)
     identifier = 1*unreserved
     identifiernodash = 1*unreservednodash
     product = identifiernodash
     serial = identifier
     componentpart = *( "_" identifier )
     unreservednodash = ALPHA / DIGIT / "."
     unreserved = unreservednodash / "-"
     hexstring = 1*(hexdigit hexdigit)
     hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
     number = 1*DIGIT
     ALPHA =  %x41-5A / %x61-7A
     DIGIT   =  %x30-39

   The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
   ALPHA rules original defined in [RFC5234], exactly as defined there.

   The device identity namespace includes three subtypes (see Section 4,
   and more may be defined in the future as specified in Section 7.

   The optional underscore-separated components following the hexstring
   are strings depicting individual aspects of a device.  The specific
   strings and their semantics are up to the designers of the device,
   but could be used to refer to specific interfaces or functions within
   the device.

   With the exception of the MAC-address and 1-Wire DEV URNs, each DEV
   URN may also contain optional colon-separated identifiers.  These are
   provided for extensibility.

   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 [RFC8428]).

   The lexical equivalence of the DEV URNs is defined as an exact and
   case sensitive string match.  Note that the two subtypes defined in
   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.



Arkko, et al.             Expires June 15, 2020                 [Page 5]


Internet-Draft                   DEV URN                   December 2019


   DEV URNs do not use r-, q-, or f-components.

   Specific subtypes of DEV URNs may be validated through mechanisms
   discussed in Section 4.

   Finally, the string representation of the device identity URN and of
   the MEID sub namespace is fully compatible with the URN syntax.

3.3.  Assignment

   Assignment: The process for identifier assignment is dependent on the
   used subtype, and documented in the specific subsection under
   Section 4.

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

   This URN type SHOULD only be used for persistent identifiers, such as
   hardware-based identifiers or cryptographic identifiers based on keys
   intended for long-term usage.

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).







Arkko, et al.             Expires June 15, 2020                 [Page 6]


Internet-Draft                   DEV URN                   December 2019


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.1.  MAC Addresses

   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.
   The EUI-64 is formed from 24 or 36 bits of organization identifier
   followed by 40 or 28 bits of device-specific extension identifier
   assigned by that organization.

   In the DEV URN "mac" subtype the hexstring is simply the full EUI-64
   identifier represented as a hexadecimal string.  It is always exactly
   16 characters long.

   MAC-48 and EUI-48 identifiers are also supported by the same DEV URN
   subtype.  To convert a MAC-48 address to an EUI-64 identifier, The
   OUI of the Ethernet address (the first three octets) becomes the
   organization identifier of the EUI-64 (the first three octets).  The
   fourth and fifth octets of the EUI are set to the fixed value FFFF
   hexadecimal.  The last three octets of the Ethernet address become
   the last three octets of the EUI-64.  The same process is used to
   convert an EUI-48 identifier, but the fixed value FFFE is used
   instead.

   Identifier assignment for all of these identifiers rests within the
   IEEE.

4.2.  1-Wire Device Identifiers

   The 1-Wire* system is a device communications bus system designed by
   Dallas Semiconductor Corporation. 1-Wire devices are identified by a
   64-bit identifier that consists of 8 byte family code, 48 bit
   identifier unique within a family, and 8 bit CRC code [OW].

      *) 1-Wire is a registered trademark.

   In DEV URNs with the "ow" subtype the hexstring is a representation
   of the full 64 bit identifier as a hexadecimal string.  It is always
   exactly 16 characters long.  Note that the last two characters




Arkko, et al.             Expires June 15, 2020                 [Page 7]


Internet-Draft                   DEV URN                   December 2019


   represent the 8-bit CRC code.  Implementations MAY check the validity
   of this code.

   Family code and identifier assignment for all 1-wire devices rests
   with the manufacturers.

4.3.  Organization-Defined Identifiers

   Device identifiers that have only a meaning within an organisation
   can also be used to represent vendor-specific or experimental
   identifiers or identifiers designed for use within the context of an
   organisation.

   Organisations are identified by their Private Enterprise Number (PEN)
   [RFC2578].  These numbers can be obtained from IANA.  Current PEN
   assignments can be viewed at https://www.iana.org/assignments/
   enterprise-numbers/enterprise-numbers and new assignemnts requested
   at https://pen.iana.org/pen/PenApplication.page.

4.4.  Organization Serial Numbers

   The "os" subtype specifies an organization and a serial number.
   Organizations are identified by their PEN.  As with the organization-
   defined identifiers (Section 4.3), PEN number assignments are
   maintained by IANA, and assignments for new organizations can be made
   easily.

      Editor's Note (Please remove before publication): The DEV URN "os"
      subtype has originally been defined in the LwM2M standard, but has
      been incorporated here to collect all syntax associated with DEV
      URNs in one place.  At the same time, the syntax of this subtype
      was changed to avoid the possibility of characters that are not
      allowed in SenML Name field (see [RFC8428] Section 4.5.1).

   Organization serial number DEV URNs consist of the PEN number and the
   serial number.  As with other DEV URNs, for carrying additional
   information and extensibility, optional colon-separated identifiers
   and underscore-separated components may also be included.  The serial
   numbers themselves are defined by the organization, and this
   specification does not specify how thy are allocated.

4.5.  Organization Product and Serial Numbers

   The DEV URN "ops" subtype has originally been defined in the LwM2M
   standard, but has been incorporated here to collect all syntax
   associated with DEV URNs in one place.  The "ops" subtype specifies
   an organization, product class, and a serial number.  Organizations
   are identified by their PEN.  Again, as with the organization-defined



Arkko, et al.             Expires June 15, 2020                 [Page 8]


Internet-Draft                   DEV URN                   December 2019


   identifiers (Section 4.3), PEN number assignments are maintained by
   IANA.

      Editor's Note (Please remove before publication): As with the "os"
      subtype, the "ops" subtype has originally been defined in the
      LwM2M standard, and its format has been slightly changed.

   Organization product and serial number DEV URNs consist of the PEN
   number, product class, and the serial number.  As with other DEV
   URNs, for carrying additional information and extensibility, optional
   colon-separated identifiers and underscore-separated components may
   also be included.  Both the product class and serial numbers
   themselves are defined by the organization, and this specification
   does not specify how thy are allocated.

5.  Examples

   The following three examples provide examples of MAC-based, 1-Wire,
   and Cryptographic identifiers:
































Arkko, et al.             Expires June 15, 2020                 [Page 9]


Internet-Draft                   DEV URN                   December 2019


       urn:dev:mac:0024beffff804ff1            # The MAC address of
                                               # Jari's laptop, for
                                               # the MAC address
                                               # 0024be804ff1

       urn:dev:ow:10e2073a01080063             # The 1-Wire temperature
                                               # sensor in Jari's
                                               # kitchen

       urn:dev:ow:264437f5000000ed_humidity    # The laundry sensor's
                                               # humidity part

       urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
                                               # temperature part

       urn:dev:org:32473-foo                   # An organization-
                                               # specific URN in
                                               # the RFC 5612 example
                                               # organisation, 32473.

       urn:dev:os:32473-123456                 # Device 123456 in
                                               # the RFC 5612 example
                                               # organisation

       urn:dev:os:32473-12-34-56               # A serial number with
                                               # dashes in it

       urn:dev:ops:32473-Refrigerator-5002     # Refrigerator serial
                                               # number 5002 in the
                                               # RFC 5612 example
                                               # organisation

       urn:dev:newsubtype:example-1-2-3_comp   # A yet-to-be-defined
                                               # subtype

6.  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.





Arkko, et al.             Expires June 15, 2020                [Page 10]


Internet-Draft                   DEV URN                   December 2019


   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.

   The URNs generated according to the rules defined in this document
   result in long-term stable unique identifiers for the devices.  Such
   identifiers may have privacy and security implications because they
   may enable correlating information about a specific device over a
   long period of time, location tracking, and device specific
   vulnerability exploitation [RFC7721].  Also, usually there is no easy
   way to change the identifier.  Therefore these identifiers need to be
   used with care and especially care should be taken avoid leaking them
   outside of the system that is intended to use the identifiers.

7.  IANA Considerations

   This document requests the registration of a new URN namespace for
   "DEV", as described in Section 3.

   Additional subtypes for DEV URNs can be defined through Specification
   Required or IESG Approval [RFC5226].

   Such 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
   be used in some cases, at least as a temporary measure.  It is
   preferrable, however, that long-term usage of a broadly employed
   device identifier be registered with IETF rather than used through
   the organisation device identifier type.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.

   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.







Arkko, et al.             Expires June 15, 2020                [Page 11]


Internet-Draft                   DEV URN                   December 2019


   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578,
              DOI 10.17487/RFC2578, April 1999, <https://www.rfc-
              editor.org/info/rfc2578>.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
              <https://www.rfc-editor.org/info/rfc3406>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
              editor.org/info/rfc5226>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
              editor.org/info/rfc5234>.

   [IEEE.EUI64]
              IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
              IEEE  , unknown year,
              <https://standards.ieee.org/content/dam/ieee-
              standards/standards/web/documents/tutorials/eui.pdf>.

   [OW]       IEEE, "Overview of 1-Wire(R) Technology and Its Use",
              MAXIM
              http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June
              2008,
              <http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.

8.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,
              DOI 10.17487/RFC2616, June 1999, <https://www.rfc-
              editor.org/info/rfc2616>.






Arkko, et al.             Expires June 15, 2020                [Page 12]


Internet-Draft                   DEV URN                   December 2019


   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002, <https://www.rfc-
              editor.org/info/rfc3261>.

   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
              Unique IDentifier (UUID) URN Namespace", RFC 4122,
              DOI 10.17487/RFC4122, July 2005, <https://www.rfc-
              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>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <https://www.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]
              Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0
              Recommendation", World Wide Web Consortium FirstEdition
              REC-xml-19980210, February 1998,
              <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [OUI]      IEEE, SA., "Registration Authority", IEEE-SA webpage,
              2018, <http://standards.ieee.org/develop/regauth/oui/>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
              editor.org/info/rfc7252>.

   [RFC8428]  Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C.
              Bormann, "Sensor Measurement Lists (SenML)", RFC 8428,
              DOI 10.17487/RFC8428, August 2018, <https://www.rfc-
              editor.org/info/rfc8428>.







Arkko, et al.             Expires June 15, 2020                [Page 13]


Internet-Draft                   DEV URN                   December 2019


   [RFC6920]  Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
              Keranen, A., and P. Hallam-Baker, "Naming Things with
              Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
              <https://www.rfc-editor.org/info/rfc6920>.

   [RFC7254]  Montemurro, M., Ed., Allen, A., McDonald, D., and P.
              Gosden, "A Uniform Resource Name Namespace for the Global
              System for Mobile Communications Association (GSMA) and
              the International Mobile station Equipment Identity
              (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014,
              <https://www.rfc-editor.org/info/rfc7254>.

   [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-18 (work in progress),
              June 2018.

Appendix A.  Changes from Previous Version

   Version -04 of the WG draft cleaned up the ABNF:

   o  Parts of the ANBF now allow for use cases for the component part
      that were not previously covered: the syntax now allows the
      character "." to appear, and serial numbers can have dashes in
      them.

   o  The syntax was also extended to allow for extensibility by adding
      additional ":" separated parts for the org, op, ops, and other
      subtypes.

   o  The ABNF was changed to include directly the ALPHA and DIGIT parts
      imported from RFC 5234, instead of just having a verbal comment
      about it.  (Note that the style in existing RFCs differs on this.)

   In addition, in -04 the MAC example was corrected to use the inserted
   value ffff instead of fffe, required by Section 4.1, the org example
   was corrected, the os: examples and otherbody examples were added.
   The IANA rules for allocating new subtypes was slightly relaxed in
   order to cover for new subtype cases that are brought up regularly,
   and often not from inside the IETF.  Finally, the allocation of PEN
   numbers and the use of product classes and serial numbers was better
   explained.

   Version -03 of the WG draft removed some unnecessary references,
   updated some other references, removed pct-encoding to ensure the DEV
   URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the
   original source of the "os" and "ops" subtypes.



Arkko, et al.             Expires June 15, 2020                [Page 14]


Internet-Draft                   DEV URN                   December 2019


   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
   already existed in this memo under the "org" branch.  However, as a
   part of this three changes were incorporated:

   o  The syntax for the "org:" changes to use "-" rather than ":"
      between the OUI and the rest of the URN.

   o  The organizations for the "ops" and "os" branches have been
      changed to use PEN numbers rather than OUI numbers [OUI].  The
      reason for this is that PEN numbers are allocated through a
      simpler and less costly process.  However, this is a significant
      change to how LwM2M identifiers were specified before.

   o  There were also changes to what general characters can be used in
      the otherbody branch of the ABNF.

   The rationale for all these changes is that it would be helpful for
   the community collect and unify syntax between the different uses of
   DEV URNs.  If there is significant use of either the org:, os:, or
   ops: subtypes, then changes at this point may not be warranted, but
   otherwise unified syntax, as well as the use of PEN numbers would
   probably be beneficial.  Comments on this topic are appreciated.

   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
   to correctly use "org:" rather than "dn:".

   Version -05 made a change to the delimiter for parameters within a
   DEV URN.  Given discussions on allowed character sets in SenML
   [RFC8428], we would like to suggest that the "_" character be used
   instead of ";", to avoid the need to translate DEV URNs in SenML-
   formatted communications or files.  However, this reverses the
   earlier decision to not use unreserved characters.  This also means
   that device IDs cannot use "_" characters, and have to employ other
   characters instead.  Feedback on this decision is sought.

   Version -05 also introduced local or organisation-specific device
   identifiers.  Organisations are identified by their PEN number
   (although we considered FQDNs as a potential alternative.  The
   authors belive an organisation-specific device identifier type will
   make experiments and local use easier, but feedback on this point and
   the choice of PEN numbers vs. other possible organisation identifiers
   would be very welcome.





Arkko, et al.             Expires June 15, 2020                [Page 15]


Internet-Draft                   DEV URN                   December 2019


   Version -05 also added some discussion of privacy concerns around
   long-term stable identifiers.

   Finally, version -05 clarified the situations when new allocations
   within the registry of possible device identifier subtypes is
   appropriate.

   Version -04 is a refresh, as the need and interest for this
   specification has re-emerged.  And the editing author has emerged
   back to actual engineering from the depths of IETF administration.

   Version -02 introduced several changes.  The biggest change is that
   with the NI URNs [RFC6920], it was no longer necessary to define
   cryptographic identifiers in this specification.  Another change was
   that we incorporated a more generic syntax for future extensions;
   non-hexstring identifiers can now also be supported, if some future
   device identifiers for some reason would, for instance, use BASE64.
   As a part of this change, we also changed the component part
   separator character from '-' to ';' so that the general format of the
   rest of the URN can employ the unreserved characters [RFC3986].

   Version -03 made several minor corrections to the ABNF as well as
   some editorial corrections.

Appendix B.  Acknowledgments

   The authors would like to thank Ari Keranen, Stephen Farrell,
   Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez,
   Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, and
   Ahmad Muhanna for interesting discussions in this problem space.  We
   would also like to note prior documents that focused on specific
   device identifiers, such as [RFC7254] or
   [I-D.atarius-dispatch-meid-urn].

Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net









Arkko, et al.             Expires June 15, 2020                [Page 16]


Internet-Draft                   DEV URN                   December 2019


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

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


   Zach Shelby
   ARM
   Kidekuja 2
   Vuokatti  88600
   FINLAND

   Phone: +358407796297
   Email: Zach.Shelby@arm.com

































Arkko, et al.             Expires June 15, 2020                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/