idnits 2.17.1 draft-ietf-core-dev-urn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 2, 2018) is 2123 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3971' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 496, but no explicit reference was found in the text == Unused Reference: 'RFC5612' is defined on line 510, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-16) exists of draft-ietf-core-senml-13 == Outdated reference: A later version (-18) exists of draft-atarius-dispatch-meid-urn-15 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Arkko 3 Internet-Draft Ericsson 4 Intended status: Informational C. Jennings 5 Expires: January 3, 2019 Cisco 6 Z. Shelby 7 ARM 8 July 2, 2018 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-core-dev-urn-02 13 Abstract 15 This memo describes a new Uniform Resource Name (URN) namespace for 16 hardware device identifiers. A general representation of device 17 identity can be useful in many applications, such as in sensor data 18 streams and storage, or equipment inventories. A URN-based 19 representation can be easily passed along in any application that 20 needs the information. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 3, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 58 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 3 59 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 6 63 3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 6 64 3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 6 66 3.8. Additional Information . . . . . . . . . . . . . . . . . 6 67 3.9. Revision Information . . . . . . . . . . . . . . . . . . 6 68 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7 70 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 7 71 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 7 72 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8 73 4.5. Organization Product and Serial Numbers . . . . . . . . . 8 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 8.2. Informative References . . . . . . . . . . . . . . . . . 10 80 Appendix A. Changes from Previous Version . . . . . . . . . . . 12 81 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 14 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 This memo describes a new Uniform Resource Name (URN) [RFC8141] 87 [RFC3406] namespace for hardware device identifiers. A general 88 representation of device identity can be useful in many applications, 89 such as in sensor data streams and storage, or equipment inventories 90 [RFC7252], [I-D.ietf-core-senml]. A URN-based representation can be 91 easily passed along in any application that needs the information, as 92 it fits in protocols mechanisms that are designed to carry URNs 93 [RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily 94 carried and stored in formats such as XML [W3C.REC-xml-19980210] or 95 JSON [I-D.ietf-core-senml] [RFC4627]. Using URNs in these formats is 96 often preferable as they are universally recognized, self-describing, 97 and therefore avoid the need for agreeing to interpret an octet 98 string as a specific form of a MAC address, for instance. 100 This memo defines identity URN types for situations where no such 101 convenient type already exist. For instance, [RFC6920] defines 102 cryptographic identifiers, [RFC7254] defines International Mobile 103 station Equipment Identity (IMEI) identifiers for use with 3GPP 104 cellular systems, and [I-D.atarius-dispatch-meid-urn] defines Mobile 105 Equipment Identity (MEID) identifiers for use with 3GPP2 cellular 106 systems. Those URN types should be employed when such identities are 107 transported; this memo does not redefine these identifiers in any 108 way. 110 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 111 alternative way for representing device identifiers, and already 112 support MAC addresses as one of type of an identifier. However, 113 UUIDs can be inconvenient in environments where it is important that 114 the identifiers are as simple as possible and where additional 115 requirements on stable storage, real-time clocks, and identifier 116 length can be prohibitive. UUID-based identifiers are recommended 117 for all general purpose uses when MAC addresses are available as 118 identifiers. The device URN defined in this memo is recommended for 119 constrained environments. 121 Future device identifier types can extend the device device URN type 122 defined here, or define their own URNs. 124 Note that long-term stable unique identifiers are problematic for 125 privacy reasons and should be used with care or avoided as described 126 in [RFC7721]. 128 The rest of this memo is organized as follows. Section 3 defines the 129 "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 130 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 131 gives examples. Section 6 discusses the security considerations of 132 the new URN type. Finally, Section 7 specifies the IANA registration 133 for the new URN type and sets requirements for subtype allocations 134 within this type. 136 2. Requirements language 138 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 139 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 140 described in [RFC2119]. 142 3. DEV URN Definition 144 Namespace Identifier: "dev" requested 145 Version: 1 147 Date: 2018-03-19 149 Registration Information: This is the first registration of this 150 namespace, 2018-03-19. 152 Registrant: IETF and the CORE working group. Should the working 153 group cease to exist, discussion should be directed to the general 154 IETF discussion forums or the IESG. 156 3.1. Purpose 158 Purpose: The DEV URNs identify devices with device-specific 159 identifiers such as network card hardware addresses. These URNs may 160 be used in any relevant networks that benefit from the ability to 161 refer to these identifiers in the form of URNs; DEV URN is global in 162 scope. 164 Some typical applications include equipment inventories and smart 165 object systems. 167 DEV URNs can be used in various ways in applications, software 168 systems, and network components, in tasks ranging from discovery (for 169 instance when discovering 1-wire network devices or detecting MAC- 170 addressable devices on a LAN) to intrusion detection systems and 171 simple catalogues of system information. 173 While it is possible to implement resolution systems for specific 174 applications or network locations, DEV URNs are typically not used in 175 a way that requires resolution beyond direct observation of the 176 relevant identity fields in local link communication. However, it is 177 often useful to be able to pass device identity information in 178 generic URN fields in databases or protocol fields, which makes the 179 use of URNs for this purpose convenient. 181 The DEV URN name space complements existing name spaces such as those 182 involving IMEI or UUID identifiers. DEV URNs are expeced to be a 183 part of the IETF-provided basic URN types, covering identifiers that 184 have previously not been possible to use in URNs. 186 3.2. Syntax 188 Syntax: The identifier is expressed in ASCII characters and has a 189 hierarchical structure as follows: 191 devurn = "urn:dev:" body componentpart 192 body = macbody / owbody / orgbody / osbody / opsbody / otherbody 193 macbody = "mac:" hexstring 194 owbody = "ow:" hexstring 195 orgbody = "org:" number "-" identifier 196 osbody = "os:" number "-" serial 197 opsbody = "ops:" number "-" product "-" serial 198 otherbody = subtype ":" identifier 199 subtype = ALPHA *(DIGIT / ALPHA) 200 identifier = 1*unreservednout 201 product = identifier 202 serial = identifier 203 unreservednout = ALPHA / DIGIT / "_" / pct-encoding 204 componentpart = [ "_" component [ componentpart ]] 205 component = *1(DIGIT / ALPHA) 206 hexstring = hexbyte / 207 hexbyte hexstring 208 hexbyte = hexdigit hexdigit 209 hexdigit = DIGIT / hexletter 210 hexletter = "a" / "b" / "c" / "d" / "e" / "f" 211 number = *1DIGIT 213 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA 214 rules defined in [RFC5234], which are not repeated here. The rule 215 for pct-encoding is defined in Section 2.1 of [RFC3986]. 217 The device identity namespace includes three subtypes (see Section 4, 218 and more may be defined in the future as specified in Section 7. 220 The optional components following the hexstring are strings depicting 221 individual aspects of a device. The specific strings and their 222 semantics are up to the designers of the device, but could be used to 223 refer to specific interfaces or functions within the device. 225 There are no special character encoding rules or considerations for 226 comforming with the URN syntax, beyond those applicable for URNs in 227 general [RFC8141], or the context where these URNs are carried (e.g., 228 inside JSON [RFC8259] or SenML [I-D.ietf-core-senml]). 230 The lexical equivalence of the DEV URNs is defined as an exact and 231 case sensitive string match. Note that the two subtypes defined in 232 this document use only lower case letters, however. Future types 233 might use identifiers that require other encodings that require a 234 more full-blown character set (such as BASE64), however. 236 DEV URNs do not use r-, q-, or f-components. 238 Specific subtypes of DEV URNs may be validated through mechanisms 239 discussed in Section 4. 241 Finally, the string representation of the device identity URN and of 242 the MEID sub namespace is fully compatible with the URN syntax. 244 3.3. Assignment 246 Assignment: The process for identifier assignment is dependent on the 247 used subtype, and documented in the specific subsection under 248 Section 4. 250 Device identifiers are generally expected to be unique, barring the 251 accidental issue of multiple devices with the same identifiers. 253 This URN type SHOULD only be used for persistent identifiers, such as 254 hardware-based identifiers or cryptographic identifiers based on keys 255 intended for long-term usage. 257 3.4. Security and Privacy 259 Security and Privacy: As discussed in Section 6, care must be taken 260 to use device identifier-based identifiers due to their nature as a 261 long-term identifier that is often not changeable. Leakage of these 262 identifiers outside systems where their use is justfied should be 263 controlled. 265 3.5. Interoperability 267 Interoperability: There are no specific interoperability concerns. 269 3.6. Resolution 271 Resolution: The device identities are not expected to be globally 272 resolvable. No identity resolution system is expected. Systems may 273 perform local matching of identities to previously seen identities or 274 configured information, however. 276 3.7. Documentation 278 See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the 279 RFC number of this document). 281 3.8. Additional Information 283 See Section 1 for a discussion of related name spaces. 285 3.9. Revision Information 287 Revision Information: This is the first version of this registration. 289 4. DEV URN Subtypes 291 4.1. MAC Addresses 293 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 294 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 295 The EUI-64 is formed from 24 or 36 bits of organization identifier 296 followed by 40 or 28 bits of device-specific extension identifier 297 assigned by that organization. 299 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 300 identifier represented as a hexadecimal string. It is always exactly 301 16 characters long. 303 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 304 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 305 OUI of the Ethernet address (the first three octets) becomes the 306 organization identifier of the EUI-64 (the first three octets). The 307 fourth and fifth octets of the EUI are set to the fixed value FFFF 308 hexadecimal. The last three octets of the Ethernet address become 309 the last three octets of the EUI-64. The same process is used to 310 convert an EUI-48 identifier, but the fixed value FFFE is used 311 instead. 313 Identifier assignment for all of these identifiers rests within the 314 IEEE. 316 4.2. 1-Wire Device Identifiers 318 The 1-Wire* system is a device communications bus system designed by 319 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 320 64-bit identifier that consists of 8 byte family code, 48 bit 321 identifier unique within a family, and 8 bit CRC code [OW]. 323 *) 1-Wire is a registered trademark. 325 In DEV URNs with the "ow" subtype the hexstring is a representation 326 of the full 64 bit identifier as a hexadecimal string. It is always 327 exactly 16 characters long. Note that the last two characters 328 represent the 8-bit CRC code. Implementations MAY check the validity 329 of this code. 331 Family code and identifier assignment for all 1-wire devices rests 332 with the manufacturers. 334 4.3. Organization-Defined Identifiers 335 Device identifiers that have only a meaning within an organisation 336 can also be used to represent vendor-specific or experimental 337 identifiers or identifiers designed for use within the context of an 338 organisation. Organisations are identified by their Private 339 Enterprise Number (PEN) [RFC2578]. 341 4.4. Organization Serial Numbers 343 The DEV URN "os" subtype has originally been defined in the LwM2M 344 standard, but has been incorporated here to collect all syntax 345 associated with DEV URNs in one place. The "os" subtype specifies an 346 organization and a serial number. Organizations are identified by 347 their PEN. 349 4.5. Organization Product and Serial Numbers 351 The DEV URN "ops" subtype has originally been defined in the LwM2M 352 standard, but has been incorporated here to collect all syntax 353 associated with DEV URNs in one place. The "ops" subtype specifies 354 an organization, product class, and a serial number. Organizations 355 are identified by their PEN. 357 5. Examples 359 The following three examples provide examples of MAC-based, 1-Wire, 360 and Cryptographic identifiers: 362 urn:dev:mac:0024befffe804ff1 # The MAC address of 363 # Jari's laptop 365 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 366 # sensor in Jari's 367 # kitchen 369 urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's 370 # humidity part 372 urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's 373 # temperature part 375 urn:dev:org:32473-123456 # Device 123456 in 376 # the RFC 5612 example 377 # organisation 379 urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial 380 # number 5002 in the 381 # RFC 5612 example 382 # organisation 384 6. Security Considerations 386 On most devices, the user can display device identifiers. Depending 387 on circumstances, device identifiers may or may not be modified or 388 tampered by the user. An implementation of the DEV URN MUST NOT 389 change these properties from what they were intended. In particular, 390 a device identifier that is intended to be immutable should not 391 become mutable as a part of implementing the DEV URN type. More 392 generally, nothing in this memo should be construed to override what 393 the relevant device specifications have already said about the 394 identifiers. 396 Other devices in the same network may or may not be able to identify 397 the device. For instance, on Ethernet network, the MAC address of a 398 device is visible to all other devices. 400 The URNs generated according to the rules defined in this document 401 result in long-term stable unique identifiers for the devices. Such 402 identifiers may have privacy and security implications because they 403 may enable correlating information about a specific device over a 404 long period of time, location tracking, and device specific 405 vulnerability exploitation [RFC7721]. Also, usually there is no easy 406 way to change the identifier. Therefore these identifiers need to be 407 used with care and especially care should be taken avoid leaking them 408 outside of the system that is intended to use the identifiers. 410 7. IANA Considerations 412 This document requests the registration of a new URN namespace for 413 "DEV", as described in Section 3. 415 Additional subtypes for DEV URNs can be defined through IETF Review 416 or IESG Approval [RFC5226]. 418 Such allocations are appropriate when there is a new namespace of 419 some type of device identifiers, defined in stable fashion and with a 420 publicly available specification that can be pointed to. 422 Note that the organisation (Section 4.3) device identifiers can also 423 be used in some cases, at least as a temporary measure. It is 424 preferrable, however, that long-term usage of a broadly employed 425 device identifier be registered with IETF rather than used through 426 the organisation device identifier type. 428 8. References 430 8.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 434 RFC2119, March 1997, . 437 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 438 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 439 . 441 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 442 Schoenwaelder, Ed., "Structure of Management Information 443 Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ 444 RFC2578, April 1999, . 447 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 448 "Uniform Resource Names (URN) Namespace Definition 449 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 450 . 452 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 453 Resource Identifier (URI): Generic Syntax", STD 66, RFC 454 3986, DOI 10.17487/RFC3986, January 2005, . 457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 458 IANA Considerations Section in RFCs", RFC 5226, DOI 459 10.17487/RFC5226, May 2008, . 462 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 463 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 464 RFC5234, January 2008, . 467 [IEEE.EUI64] 468 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 469 IEEE , unknown year, 470 . 472 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 473 MAXIM http://www.maxim-ic.com/app-notes/index.mvp/id/1796, 474 June 2008, 475 . 477 8.2. Informative References 479 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 480 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 481 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 482 RFC2616, June 1999, . 485 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 486 A., Peterson, J., Sparks, R., Handley, M., and E. 487 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 488 DOI 10.17487/RFC3261, June 2002, . 491 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 492 "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487 493 /RFC3971, March 2005, . 496 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 497 RFC 3972, DOI 10.17487/RFC3972, March 2005, . 500 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 501 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 502 10.17487/RFC4122, July 2005, . 505 [RFC4627] Crockford, D., "The application/json Media Type for 506 JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487 507 /RFC4627, July 2006, . 510 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 511 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 512 2009, . 514 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 515 Considerations for IPv6 Address Generation Mechanisms", 516 RFC 7721, DOI 10.17487/RFC7721, March 2016, . 519 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 520 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 521 RFC8259, December 2017, . 524 [W3C.REC-xml-19980210] 525 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 526 Recommendation", World Wide Web Consortium FirstEdition 527 REC-xml-19980210, February 1998, 528 . 530 [OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage, 531 2018, . 533 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 534 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 535 RFC7252, June 2014, . 538 [I-D.ietf-core-senml] 539 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 540 Bormann, "Media Types for Sensor Measurement Lists 541 (SenML)", draft-ietf-core-senml-13 (work in progress), 542 March 2018. 544 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 545 Keranen, A., and P. Hallam-Baker, "Naming Things with 546 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 547 . 549 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 550 Gosden, "A Uniform Resource Name Namespace for the Global 551 System for Mobile Communications Association (GSMA) and 552 the International Mobile station Equipment Identity 553 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, . 556 [I-D.atarius-dispatch-meid-urn] 557 Atarius, R., "A Uniform Resource Name Namespace for the 558 Device Identity and the Mobile Equipment Identity (MEID)", 559 draft-atarius-dispatch-meid-urn-15 (work in progress), 560 January 2018. 562 Appendix A. Changes from Previous Version 564 Version -02 of the WG draft folded in the "ops" and "os" branches of 565 the dev:urn syntax from LwM2M, as they seemed to match well what 566 already existed in this memo under the "org" branch. However, as a 567 part of this three changes were incorporated: 569 o The syntax for the "org:" changes to use "-" rather than ":" 570 between the OUI and the rest of the URN. 572 o The organizations for the "ops" and "os" branches have been 573 changed to use PEN numbers rather than OUI numbers [OUI]. The 574 reason for this is that PEN numbers are allocated through a 575 simpler and less costly process. However, this is a significant 576 change to how LwM2M identifiers were specified before. 578 o There were also changes to what general characters can be used in 579 the otherbody branch of the ABNF. 581 The rationale for all these changes is that it would be helpful for 582 the community collect and unify syntax between the different uses of 583 DEV URNs. If there is significant use of either the org:, os:, or 584 ops: subtypes, then changes at this point may not be warranted, but 585 otherwise unified syntax, as well as the use of PEN numbers would 586 probably be beneficial. Comments on this topic are appreciated. 588 Version -01 of the WG draft converted the draft to use the new URN 589 registration template from [RFC8141]. 591 Version -00 of the WG draft renamed the file name and fixed the ABNF 592 to correctly use "org:" rather than "dn:". 594 Version -05 made a change to the delimiter for parameters within a 595 DEV URN. Given discussions on allowed character sets in SenML 596 [I-D.ietf-core-senml], we would like to suggest that the "_" 597 character be used instead of ";", to avoid the need to translate DEV 598 URNs in SenML-formatted communications or files. However, this 599 reverses the earlier decision to not use unreserved characters. This 600 also means that device IDs cannot use "_" characters, and have to 601 employ other characters instead. Feedback on this decision is 602 sought. 604 Version -05 also introduced local or organisation-specific device 605 identifiers. Organisations are identified by their PEN number 606 (although we considered FQDNs as a potential alternative. The 607 authors belive an organisation-specific device identifier type will 608 make experiments and local use easier, but feedback on this point and 609 the choice of PEN numbers vs. other possible organisation identifiers 610 would be very welcome. 612 Version -05 also added some discussion of privacy concerns around 613 long-term stable identifiers. 615 Finally, version -05 clarified the situations when new allocations 616 within the registry of possible device identifier subtypes is 617 appropriate. 619 Version -04 is a refresh, as the need and interest for this 620 specification has re-emerged. And the editing author has emerged 621 back to actual engineering from the depths of IETF administration. 623 Version -02 introduced several changes. The biggest change is that 624 with the NI URNs [RFC6920], it was no longer necessary to define 625 cryptographic identifiers in this specification. Another change was 626 that we incorporated a more generic syntax for future extensions; 627 non-hexstring identifiers can now also be supported, if some future 628 device identifiers for some reason would, for instance, use BASE64. 629 As a part of this change, we also changed the component part 630 separator character from '-' to ';' so that the general format of the 631 rest of the URN can employ the unreserved characters [RFC3986]. 633 Appendix B. Acknowledgments 635 The authors would like to thank Ari Keranen, Stephen Farrell, 636 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 637 and Ahmad Muhanna for interesting discussions in this problem space. 638 We would also like to note prior documents that focused on specific 639 device identifiers, such as [RFC7254] or 640 [I-D.atarius-dispatch-meid-urn]. 642 Authors' Addresses 644 Jari Arkko 645 Ericsson 646 Jorvas 02420 647 Finland 649 Email: jari.arkko@piuha.net 651 Cullen Jennings 652 Cisco 653 170 West Tasman Drive 654 San Jose, CA 95134 655 USA 657 Phone: +1 408 421-9990 658 Email: fluffy@cisco.com 660 Zach Shelby 661 ARM 662 Kidekuja 2 663 Vuokatti 88600 664 FINLAND 666 Phone: +358407796297 667 Email: Zach.Shelby@arm.com