draft-ietf-core-dev-urn-03.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: April 25, 2019 Cisco Expires: June 15, 2020 Cisco
Z. Shelby Z. Shelby
ARM ARM
October 22, 2018 December 13, 2019
Uniform Resource Names for Device Identifiers Uniform Resource Names for Device Identifiers
draft-ietf-core-dev-urn-03 draft-ietf-core-dev-urn-04
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 April 25, 2019. This Internet-Draft will expire on June 15, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . 4 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . 8 4.5. Organization Product and Serial Numbers . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Changes from Previous Version . . . . . . . . . . . 13 Appendix A. Changes from Previous Version . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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]
[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], [RFC8428]. A URN-based representation can be easily [RFC7252], [RFC8428]. A URN-based representation can be easily
passed along in any application that needs the information, as it passed along in any application that needs the information, as it
fits in protocols mechanisms that are designed to carry URNs fits in protocols mechanisms that are designed to carry URNs
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Registration Information: This is the first registration of this Registration Information: This is the first registration of this
namespace, 2018-03-19. namespace, 2018-03-19.
Registrant: IETF and the CORE working group. Should the working Registrant: IETF and the CORE working group. Should the working
group cease to exist, discussion should be directed to the general group cease to exist, discussion should be directed to the general
IETF discussion forums or the IESG. IETF discussion forums or the IESG.
3.1. Purpose 3.1. Purpose
Purpose: The DEV URNs identify devices with device-specific Purpose: The DEV URNs identify devices with device-specific
identifiers such as network card hardware addresses. These URNs may identifiers such as network card hardware addresses. DEV URN is
be used in any relevant networks that benefit from the ability to global in scope.
refer to these identifiers in the form of URNs; DEV URN is global in
scope.
Some typical applications include equipment inventories and smart Some typical applications include equipment inventories and smart
object systems. object systems.
DEV URNs can be used in various ways in applications, software DEV URNs can be used in various ways in applications, software
systems, and network components, in tasks ranging from discovery (for systems, and network components, in tasks ranging from discovery (for
instance when discovering 1-wire network devices or detecting MAC- instance when discovering 1-wire network devices or detecting MAC-
addressable devices on a LAN) to intrusion detection systems and addressable devices on a LAN) to intrusion detection systems and
simple catalogues of system information. simple catalogues of system information.
skipping to change at page 5, line 14 skipping to change at page 5, line 9
3.2. Syntax 3.2. Syntax
Syntax: The identifier is expressed in ASCII characters and has a Syntax: The identifier is expressed in ASCII characters and has a
hierarchical structure as follows: hierarchical structure as follows:
devurn = "urn:dev:" body componentpart devurn = "urn:dev:" body componentpart
body = macbody / owbody / orgbody / osbody / opsbody / otherbody body = macbody / owbody / orgbody / osbody / opsbody / otherbody
macbody = "mac:" hexstring macbody = "mac:" hexstring
owbody = "ow:" hexstring owbody = "ow:" hexstring
orgbody = "org:" number "-" identifier orgbody = "org:" number "-" identifier *( ":" identifier )
osbody = "os:" number "-" serial osbody = "os:" number "-" serial *( ":" identifier )
opsbody = "ops:" number "-" product "-" serial opsbody = "ops:" number "-" product "-" serial *( ":" identifier )
otherbody = subtype ":" identifier otherbody = subtype ":" identifier *( ":" identifier )
subtype = ALPHA *(DIGIT / ALPHA) subtype = ALPHA *(DIGIT / ALPHA)
identifier = 1*unreservednout identifier = 1*unreserved
product = identifier identifiernodash = 1*unreservednodash
product = identifiernodash
serial = identifier serial = identifier
unreservednout = ALPHA / DIGIT / "_" componentpart = *( "_" identifier )
componentpart = [ "_" component [ componentpart ]] unreservednodash = ALPHA / DIGIT / "."
component = *1(DIGIT / ALPHA) unreserved = unreservednodash / "-"
hexstring = hexbyte / hexstring = 1*(hexdigit hexdigit)
hexbyte hexstring hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
hexbyte = hexdigit hexdigit number = 1*DIGIT
hexdigit = DIGIT / hexletter ALPHA = %x41-5A / %x61-7A
hexletter = "a" / "b" / "c" / "d" / "e" / "f" DIGIT = %x30-39
number = *1DIGIT
The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and
rules defined in [RFC5234], which are not repeated here. The rule ALPHA rules original defined in [RFC5234], exactly as defined there.
for pct-encoding is defined in Section 2.1 of [RFC3986].
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 components following the hexstring are strings depicting The optional underscore-separated components following the hexstring
individual aspects of a device. The specific strings and their are strings depicting individual aspects of a device. The specific
semantics are up to the designers of the device, but could be used to strings and their semantics are up to the designers of the device,
refer to specific interfaces or functions within 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 There are no special character encoding rules or considerations for
comforming with the URN syntax, beyond those applicable for URNs in comforming with the URN syntax, beyond those applicable for URNs in
general [RFC8141], or the context where these URNs are carried (e.g., general [RFC8141], or the context where these URNs are carried (e.g.,
inside JSON [RFC8259] or SenML [RFC8428]). inside JSON [RFC8259] or SenML [RFC8428]).
The lexical equivalence of the DEV URNs is defined as an exact and The lexical equivalence of the DEV URNs is defined as an exact and
case sensitive string match. Note that the two subtypes defined in case sensitive string match. Note that the two subtypes defined in
this document use only lower case letters, however. Future types this document use only lower case letters, however. Future types
might use identifiers that require other encodings that require a might use identifiers that require other encodings that require a
skipping to change at page 8, line 15 skipping to change at page 8, line 15
of this code. of this code.
Family code and identifier assignment for all 1-wire devices rests Family code and identifier assignment for all 1-wire devices rests
with the manufacturers. with the manufacturers.
4.3. Organization-Defined Identifiers 4.3. Organization-Defined Identifiers
Device identifiers that have only a meaning within an organisation Device identifiers that have only a meaning within an organisation
can also be used to represent vendor-specific or experimental can also be used to represent vendor-specific or experimental
identifiers or identifiers designed for use within the context of an identifiers or identifiers designed for use within the context of an
organisation. Organisations are identified by their Private organisation.
Enterprise Number (PEN) [RFC2578].
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 4.4. Organization Serial Numbers
The "os" subtype specifies an organization and a serial number. The "os" subtype specifies an organization and a serial number.
Organizations are identified by their PEN. 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.
Note: The DEV URN "os" subtype has originally been defined in the Editor's Note (Please remove before publication): The DEV URN "os"
LwM2M standard, but has been incorporated here to collect all subtype has originally been defined in the LwM2M standard, but has
syntax associated with DEV URNs in one place. At the same time, been incorporated here to collect all syntax associated with DEV
the syntax of this subtype was changed to avoid the possibility of URNs in one place. At the same time, the syntax of this subtype
characters that are not allowed in SenML Name field (see [RFC8428] was changed to avoid the possibility of characters that are not
Section 4.5.1). 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 4.5. Organization Product and Serial Numbers
The DEV URN "ops" subtype has originally been defined in the LwM2M The DEV URN "ops" subtype has originally been defined in the LwM2M
standard, but has been incorporated here to collect all syntax standard, but has been incorporated here to collect all syntax
associated with DEV URNs in one place. The "ops" subtype specifies associated with DEV URNs in one place. The "ops" subtype specifies
an organization, product class, and a serial number. Organizations an organization, product class, and a serial number. Organizations
are identified by their PEN. are identified by their PEN. Again, as with the organization-defined
identifiers (Section 4.3), PEN number assignments are maintained by
IANA.
Note: As with the "os" subtype, the "ops" subtype has originally Editor's Note (Please remove before publication): As with the "os"
been defined in the LwM2M standard, and its format has been subtype, the "ops" subtype has originally been defined in the
slightly changed. 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 5. Examples
The following three examples provide examples of MAC-based, 1-Wire, The following three examples provide examples of MAC-based, 1-Wire,
and Cryptographic identifiers: and Cryptographic identifiers:
urn:dev:mac:0024befffe804ff1 # The MAC address of urn:dev:mac:0024beffff804ff1 # The MAC address of
# Jari's laptop # Jari's laptop, for
# the MAC address
# 0024be804ff1
urn:dev:ow:10e2073a01080063 # The 1-Wire temperature urn:dev:ow:10e2073a01080063 # The 1-Wire temperature
# sensor in Jari's # sensor in Jari's
# kitchen # kitchen
urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's
# humidity part # humidity part
urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's
# temperature part # temperature part
urn:dev:org:32473-123456 # Device 123456 in 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 # the RFC 5612 example
# organisation # organisation
urn:dev:os:32473-12-34-56 # A serial number with
# 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
# subtype
6. Security 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 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
skipping to change at page 10, line 10 skipping to change at page 11, line 24
vulnerability exploitation [RFC7721]. Also, usually there is no easy vulnerability exploitation [RFC7721]. Also, usually there is no easy
way to change the identifier. Therefore these identifiers need to be way to change the identifier. Therefore these identifiers need to be
used with care and especially care should be taken avoid leaking them used with care and especially care should be taken avoid leaking them
outside of the system that is intended to use the identifiers. outside of the system that is intended to use the identifiers.
7. IANA Considerations 7. IANA Considerations
This document requests the registration of a new URN namespace for This document requests the registration of a new URN namespace for
"DEV", as described in Section 3. "DEV", as described in Section 3.
Additional subtypes for DEV URNs can be defined through IETF Review Additional subtypes for DEV URNs can be defined through Specification
or IESG Approval [RFC5226]. Required or IESG Approval [RFC5226].
Such allocations are appropriate when there is a new namespace of Such allocations are appropriate when there is a new namespace of
some type of device identifiers, defined in stable fashion and with a some type of device identifiers, defined in stable fashion and with a
publicly available specification that can be pointed to. publicly available specification that can be pointed to.
Note that the organisation (Section 4.3) device identifiers can also Note that the organisation (Section 4.3) device identifiers can also
be used in some cases, at least as a temporary measure. It is be used in some cases, at least as a temporary measure. It is
preferrable, however, that long-term usage of a broadly employed preferrable, however, that long-term usage of a broadly employed
device identifier be registered with IETF rather than used through device identifier be registered with IETF rather than used through
the organisation device identifier type. the organisation device identifier type.
skipping to change at page 11, line 18 skipping to change at page 12, line 34
editor.org/info/rfc5226>. editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, <https://www.rfc- DOI 10.17487/RFC5234, January 2008, <https://www.rfc-
editor.org/info/rfc5234>. editor.org/info/rfc5234>.
[IEEE.EUI64] [IEEE.EUI64]
IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)",
IEEE , unknown year, IEEE , unknown year,
<http://standards.ieee.org/db/oui/tutorials/EUI64.html>. <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", [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use",
MAXIM MAXIM
http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June
2008, 2008,
<http://www.maxim-ic.com/app-notes/index.mvp/id/1796>. <http://www.maxim-ic.com/app-notes/index.mvp/id/1796>.
8.2. Informative References 8.2. Informative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
skipping to change at page 13, line 7 skipping to change at page 14, line 25
<https://www.rfc-editor.org/info/rfc7254>. <https://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-18 (work in progress), draft-atarius-dispatch-meid-urn-18 (work in progress),
June 2018. June 2018.
Appendix A. Changes from Previous Version 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, Version -03 of the WG draft removed some unnecessary references,
updated some other references, removed pct-encoding to ensure the DEV updated some other references, removed pct-encoding to ensure the DEV
URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the
original source of the "os" and "ops" subtypes. original source of the "os" and "ops" subtypes.
Version -02 of the WG draft folded in the "ops" and "os" branches of 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 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 already existed in this memo under the "org" branch. However, as a
part of this three changes were incorporated: part of this three changes were incorporated:
skipping to change at page 14, line 31 skipping to change at page 16, line 26
Version -02 introduced several changes. The biggest change is that Version -02 introduced several changes. The biggest change is that
with the NI URNs [RFC6920], it was no longer necessary to define with the NI URNs [RFC6920], it was no longer necessary to define
cryptographic identifiers in this specification. Another change was cryptographic identifiers in this specification. Another change was
that we incorporated a more generic syntax for future extensions; that we incorporated a more generic syntax for future extensions;
non-hexstring identifiers can now also be supported, if some future non-hexstring identifiers can now also be supported, if some future
device identifiers for some reason would, for instance, use BASE64. device identifiers for some reason would, for instance, use BASE64.
As a part of this change, we also changed the component part As a part of this change, we also changed the component part
separator character from '-' to ';' so that the general format of the separator character from '-' to ';' so that the general format of the
rest of the URN can employ the unreserved characters [RFC3986]. 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 Appendix B. Acknowledgments
The authors would like to thank Ari Keranen, Stephen Farrell, The authors would like to thank Ari Keranen, Stephen Farrell,
Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez,
Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, and Ahmad Muhanna Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, and
for interesting discussions in this problem space. We would also Ahmad Muhanna for interesting discussions in this problem space. We
like to note prior documents that focused on specific device would also like to note prior documents that focused on specific
identifiers, such as [RFC7254] or [I-D.atarius-dispatch-meid-urn]. device identifiers, such as [RFC7254] or
[I-D.atarius-dispatch-meid-urn].
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Cullen Jennings Cullen Jennings
 End of changes. 27 change blocks. 
64 lines changed or deleted 133 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/