idnits 2.17.1 draft-ietf-core-dev-urn-01.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 (March 19, 2018) is 2229 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 463, but no explicit reference was found in the text == Unused Reference: 'RFC3972' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC5612' is defined on line 482, 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: September 20, 2018 Cisco 6 Z. Shelby 7 ARM 8 March 19, 2018 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-core-dev-urn-01 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 September 20, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . 5 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 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 8.2. Informative References . . . . . . . . . . . . . . . . . 10 78 Appendix A. Changes from Previous Version . . . . . . . . . . . 12 79 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 This memo describes a new Uniform Resource Name (URN) [RFC8141] 85 [RFC3406] namespace for hardware device identifiers. A general 86 representation of device identity can be useful in many applications, 87 such as in sensor data streams and storage, or equipment inventories 88 [RFC7252], [I-D.ietf-core-senml]. A URN-based representation can be 89 easily passed along in any application that needs the information, as 90 it fits in protocols mechanisms that are designed to carry URNs 91 [RFC2616], [RFC3261], [RFC7252]. Finally, URNs can also be easily 92 carried and stored in formats such as XML [W3C.REC-xml-19980210] or 93 JSON [I-D.ietf-core-senml] [RFC4627]. Using URNs in these formats is 94 often preferable as they are universally recognized, self-describing, 95 and therefore avoid the need for agreeing to interpret an octet 96 string as a specific form of a MAC address, for instance. 98 This memo defines identity URN types for situations where no such 99 convenient type already exist. For instance, [RFC6920] defines 100 cryptographic identifiers, [RFC7254] defines International Mobile 101 station Equipment Identity (IMEI) identifiers for use with 3GPP 102 cellular systems, and [I-D.atarius-dispatch-meid-urn] defines Mobile 103 Equipment Identity (MEID) identifiers for use with 3GPP2 cellular 104 systems. Those URN types should be employed when such identities are 105 transported; this memo does not redefine these identifiers in any 106 way. 108 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 109 alternative way for representing device identifiers, and already 110 support MAC addresses as one of type of an identifier. However, 111 UUIDs can be inconvenient in environments where it is important that 112 the identifiers are as simple as possible and where additional 113 requirements on stable storage, real-time clocks, and identifier 114 length can be prohibitive. UUID-based identifiers are recommended 115 for all general purpose uses when MAC addresses are available as 116 identifiers. The device URN defined in this memo is recommended for 117 constrained environments. 119 Future device identifier types can extend the device device URN type 120 defined here, or define their own URNs. 122 Note that long-term stable unique identifiers are problematic for 123 privacy reasons and should be used with care or avoided as described 124 in [RFC7721]. 126 The rest of this memo is organized as follows. Section 3 defines the 127 "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 128 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 129 gives examples. Section 6 discusses the security considerations of 130 the new URN type. Finally, Section 7 specifies the IANA registration 131 for the new URN type and sets requirements for subtype allocations 132 within this type. 134 2. Requirements language 136 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 137 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 138 described in [RFC2119]. 140 3. DEV URN Definition 142 Namespace Identifier: "dev" requested 144 Version: 1 145 Date: 2018-03-19 147 Registration Information: This is the first registration of this 148 namespace, 2018-03-19. 150 Registrant: IETF and the CORE working group. Should the working 151 group cease to exist, discussion should be directed to the general 152 IETF discussion forums or the IESG. 154 3.1. Purpose 156 Purpose: The DEV URNs identify devices with device-specific 157 identifiers such as network card hardware addresses. These URNs may 158 be used in any relevant networks that benefit from the ability to 159 refer to these identifiers in the form of URNs; DEV URN is global in 160 scope. 162 Some typical applications include equipment inventories and smart 163 object systems. 165 DEV URNs can be used in various ways in applications, software 166 systems, and network components, in tasks ranging from discovery (for 167 instance when discovering 1-wire network devices or detecting MAC- 168 addressable devices on a LAN) to intrusion detection systems and 169 simple catalogues of system information. 171 While it is possible to implement resolution systems for specific 172 applications or network locations, DEV URNs are typically not used in 173 a way that requires resolution beyond direct observation of the 174 relevant identity fields in local link communication. However, it is 175 often useful to be able to pass device identity information in 176 generic URN fields in databases or protocol fields, which makes the 177 use of URNs for this purpose convenient. 179 The DEV URN name space complements existing name spaces such as those 180 involving IMEI or UUID identifiers. DEV URNs are expeced to be a 181 part of the IETF-provided basic URN types, covering identifiers that 182 have previously not been possible to use in URNs. 184 3.2. Syntax 186 Syntax: The identifier is expressed in ASCII characters and has a 187 hierarchical structure as follows: 189 devurn = "urn:dev:" body componentpart 190 body = macbody / owbody / orgbody / otherbody 191 macbody = "mac:" hexstring 192 owbody = "ow:" hexstring 193 orgbody = "org:" number ":" identifier 194 otherbody = subtype ":" identifier 195 subtype = ALPHA *(DIGIT / ALPHA) 196 identifier = 1*unreservednout 197 unreservednout = ALPHA / DIGIT / "-" / "." 198 componentpart = [ "_" component [ componentpart ]] 199 component = *1(DIGIT / ALPHA) 200 hexstring = hexbyte / 201 hexbyte hexstring 202 hexbyte = hexdigit hexdigit 203 hexdigit = DIGIT / hexletter 204 hexletter = "a" / "b" / "c" / "d" / "e" / "f" 205 number = *1DIGIT 207 The above Augmented Backus-Naur Form (ABNF) uses the DIGIT and ALPHA 208 rules defined in [RFC5234], which are not repeated here. The rule 209 for unreserved is defined in Section 2.3 of [RFC3986]. 211 The device identity namespace includes three subtypes (see Section 4, 212 and more may be defined in the future as specified in Section 7. 214 The optional components following the hexstring are strings depicting 215 individual aspects of a device. The specific strings and their 216 semantics are up to the designers of the device, but could be used to 217 refer to specific interfaces or functions within the device. 219 There are no special character encoding rules or considerations for 220 comforming with the URN syntax, beyond those applicable for URNs in 221 general [RFC8141], or the context where these URNs are carried (e.g., 222 inside JSON [RFC8259] or SenML [I-D.ietf-core-senml]). 224 The lexical equivalence of the DEV URNs is defined as an exact and 225 case sensitive string match. Note that the two subtypes defined in 226 this document use only lower case letters, however. Future types 227 might use identifiers that require other encodings that require a 228 more full-blown character set (such as BASE64), however. 230 DEV URNs do not use r-, q-, or f-components. 232 Specific subtypes of DEV URNs may be validated through mechanisms 233 discussed in Section 4. 235 Finally, the string representation of the device identity URN and of 236 the MEID sub namespace is fully compatible with the URN syntax. 238 3.3. Assignment 239 Assignment: The process for identifier assignment is dependent on the 240 used subtype, and documented in the specific subsection under 241 Section 4. 243 Device identifiers are generally expected to be unique, barring the 244 accidental issue of multiple devices with the same identifiers. 246 This URN type SHOULD only be used for persistent identifiers, such as 247 hardware-based identifiers or cryptographic identifiers based on keys 248 intended for long-term usage. 250 3.4. Security and Privacy 252 Security and Privacy: As discussed in Section 6, care must be taken 253 to use device identifier-based identifiers due to their nature as a 254 long-term identifier that is often not changeable. Leakage of these 255 identifiers outside systems where their use is justfied should be 256 controlled. 258 3.5. Interoperability 260 Interoperability: There are no specific interoperability concerns. 262 3.6. Resolution 264 Resolution: The device identities are not expected to be globally 265 resolvable. No identity resolution system is expected. Systems may 266 perform local matching of identities to previously seen identities or 267 configured information, however. 269 3.7. Documentation 271 See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the 272 RFC number of this document). 274 3.8. Additional Information 276 See Section 1 for a discussion of related name spaces. 278 3.9. Revision Information 280 Revision Information: This is the first version of this registration. 282 4. DEV URN Subtypes 284 4.1. MAC Addresses 286 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 287 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 288 The EUI-64 is formed from 24 or 36 bits of organization identifier 289 followed by 40 or 28 bits of device-specific extension identifier 290 assigned by that organization. 292 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 293 identifier represented as a hexadecimal string. It is always exactly 294 16 characters long. 296 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 297 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 298 OUI of the Ethernet address (the first three octets) becomes the 299 organization identifier of the EUI-64 (the first three octets). The 300 fourth and fifth octets of the EUI are set to the fixed value FFFF 301 hexadecimal. The last three octets of the Ethernet address become 302 the last three octets of the EUI-64. The same process is used to 303 convert an EUI-48 identifier, but the fixed value FFFE is used 304 instead. 306 Identifier assignment for all of these identifiers rests within the 307 IEEE. 309 4.2. 1-Wire Device Identifiers 311 The 1-Wire* system is a device communications bus system designed by 312 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 313 64-bit identifier that consists of 8 byte family code, 48 bit 314 identifier unique within a family, and 8 bit CRC code [OW]. 316 *) 1-Wire is a registered trademark. 318 In DEV URNs with the "ow" subtype the hexstring is a representation 319 of the full 64 bit identifier as a hexadecimal string. It is always 320 exactly 16 characters long. Note that the last two characters 321 represent the 8-bit CRC code. Implementations MAY check the validity 322 of this code. 324 Family code and identifier assignment for all 1-wire devices rests 325 with the manufacturers. 327 4.3. Organization-Defined Identifiers 328 Device identifiers that have only a meaning within an organisation 329 can also be used to represent vendor-specific or experimental 330 identifiers or identifiers designed for use within the context of an 331 organisation. Organisations are identified by the Private Enterprise 332 Number [RFC2578]. 334 5. Examples 336 The following three examples provide examples of MAC-based, 1-Wire, 337 and Cryptographic identifiers: 339 urn:dev:mac:0024befffe804ff1 # The MAC address of 340 # Jari's laptop 342 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 343 # sensor in Jari's 344 # kitchen 346 urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's 347 # humidity part 349 urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's 350 # temperature part 352 urn:dev:org:32473:123456 # Device 123456 in 353 # the RFC 5612 example 354 # organisation 356 6. Security Considerations 358 On most devices, the user can display device identifiers. Depending 359 on circumstances, device identifiers may or may not be modified or 360 tampered by the user. An implementation of the DEV URN MUST NOT 361 change these properties from what they were intended. In particular, 362 a device identifier that is intended to be immutable should not 363 become mutable as a part of implementing the DEV URN type. More 364 generally, nothing in this memo should be construed to override what 365 the relevant device specifications have already said about the 366 identifiers. 368 Other devices in the same network may or may not be able to identify 369 the device. For instance, on Ethernet network, the MAC address of a 370 device is visible to all other devices. 372 The URNs generated according to the rules defined in this document 373 result in long-term stable unique identifiers for the devices. Such 374 identifiers may have privacy and security implications because they 375 may enable correlating information about a specific device over a 376 long period of time, location tracking, and device specific 377 vulnerability exploitation [RFC7721]. Also, usually there is no easy 378 way to change the identifier. Therefore these identifiers need to be 379 used with care and especially care should be taken avoid leaking them 380 outside of the system that is intended to use the identifiers. 382 7. IANA Considerations 384 This document requests the registration of a new URN namespace for 385 "DEV", as described in Section 3. 387 Additional subtypes for DEV URNs can be defined through IETF Review 388 or IESG Approval [RFC5226]. 390 Such allocations are appropriate when there is a new namespace of 391 some type of device identifiers, defined in stable fashion and with a 392 publicly available specification that can be pointed to. 394 Note that the organisation (Section 4.3) device identifiers can also 395 be used in some cases, at least as a temporary measure. It is 396 preferrable, however, that long-term usage of a broadly employed 397 device identifier be registered with IETF rather than used through 398 the organisation device identifier type. 400 8. References 402 8.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 406 RFC2119, March 1997, . 409 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 410 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 411 . 413 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 414 Schoenwaelder, Ed., "Structure of Management Information 415 Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/ 416 RFC2578, April 1999, . 419 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 420 "Uniform Resource Names (URN) Namespace Definition 421 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 422 . 424 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 425 Resource Identifier (URI): Generic Syntax", STD 66, RFC 426 3986, DOI 10.17487/RFC3986, January 2005, . 429 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 430 IANA Considerations Section in RFCs", RFC 5226, DOI 431 10.17487/RFC5226, May 2008, . 434 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 435 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 436 RFC5234, January 2008, . 439 [IEEE.EUI64] 440 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 441 IEEE , unknown year, 442 . 444 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 445 MAXIM http://www.maxim-ic.com/app-notes/index.mvp/id/1796, 446 June 2008, 447 . 449 8.2. Informative References 451 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 452 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 453 Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/ 454 RFC2616, June 1999, . 457 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 458 A., Peterson, J., Sparks, R., Handley, M., and E. 459 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 460 DOI 10.17487/RFC3261, June 2002, . 463 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, 464 "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487 465 /RFC3971, March 2005, . 468 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 469 RFC 3972, DOI 10.17487/RFC3972, March 2005, . 472 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 473 Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 474 10.17487/RFC4122, July 2005, . 477 [RFC4627] Crockford, D., "The application/json Media Type for 478 JavaScript Object Notation (JSON)", RFC 4627, DOI 10.17487 479 /RFC4627, July 2006, . 482 [RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for 483 Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 484 2009, . 486 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 487 Considerations for IPv6 Address Generation Mechanisms", 488 RFC 7721, DOI 10.17487/RFC7721, March 2016, . 491 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 492 Interchange Format", STD 90, RFC 8259, DOI 10.17487/ 493 RFC8259, December 2017, . 496 [W3C.REC-xml-19980210] 497 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 498 Recommendation", World Wide Web Consortium FirstEdition 499 REC-xml-19980210, February 1998, 500 . 502 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 503 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 504 RFC7252, June 2014, . 507 [I-D.ietf-core-senml] 508 Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 509 Bormann, "Media Types for Sensor Measurement Lists 510 (SenML)", draft-ietf-core-senml-13 (work in progress), 511 March 2018. 513 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 514 Keranen, A., and P. Hallam-Baker, "Naming Things with 515 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 516 . 518 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 519 Gosden, "A Uniform Resource Name Namespace for the Global 520 System for Mobile Communications Association (GSMA) and 521 the International Mobile station Equipment Identity 522 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, . 525 [I-D.atarius-dispatch-meid-urn] 526 Atarius, R., "A Uniform Resource Name Namespace for the 527 Device Identity and the Mobile Equipment Identity (MEID)", 528 draft-atarius-dispatch-meid-urn-15 (work in progress), 529 January 2018. 531 Appendix A. Changes from Previous Version 533 Version -01 of the WG draft converted the draft to use the new URN 534 registration template from [RFC8141]. 536 Version -00 of the WG draft renamed the file name and fixed the ABNF 537 to correctly use "org:" rather than "dn:". 539 Version -05 made a change to the delimiter for parameters within a 540 DEV URN. Given discussions on allowed character sets in SenML 541 [I-D.ietf-core-senml], we would like to suggest that the "_" 542 character be used instead of ";", to avoid the need to translate DEV 543 URNs in SenML-formatted communications or files. However, this 544 reverses the earlier decision to not use unreserved characters. This 545 also means that device IDs cannot use "_" characters, and have to 546 employ other characters instead. Feedback on this decision is 547 sought. 549 Version -05 also introduced local or organisation-specific device 550 identifiers. Organisations are identified by their PEN number 551 (although we considered FQDNs as a potential alternative. The 552 authors belive an organisation-specific device identifier type will 553 make experiments and local use easier, but feedback on this point and 554 the choice of PEN numbers vs. other possible organisation identifiers 555 would be very welcome. 557 Version -05 also added some discussion of privacy concerns around 558 long-term stable identifiers. 560 Finally, version -05 clarified the situations when new allocations 561 within the registry of possible device identifier subtypes is 562 appropriate. 564 Version -04 is a refresh, as the need and interest for this 565 specification has re-emerged. And the editing author has emerged 566 back to actual engineering from the depths of IETF administration. 568 Version -02 introduced several changes. The biggest change is that 569 with the NI URNs [RFC6920], it was no longer necessary to define 570 cryptographic identifiers in this specification. Another change was 571 that we incorporated a more generic syntax for future extensions; 572 non-hexstring identifiers can now also be supported, if some future 573 device identifiers for some reason would, for instance, use BASE64. 574 As a part of this change, we also changed the component part 575 separator character from '-' to ';' so that the general format of the 576 rest of the URN can employ the unreserved characters [RFC3986]. 578 Appendix B. Acknowledgments 580 The authors would like to thank Ari Keranen, Stephen Farrell, 581 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 582 and Ahmad Muhanna for interesting discussions in this problem space. 583 We would also like to note prior documents that focused on specific 584 device identifiers, such as [RFC7254] or 585 [I-D.atarius-dispatch-meid-urn]. 587 Authors' Addresses 589 Jari Arkko 590 Ericsson 591 Jorvas 02420 592 Finland 594 Email: jari.arkko@piuha.net 596 Cullen Jennings 597 Cisco 598 170 West Tasman Drive 599 San Jose, CA 95134 600 USA 602 Phone: +1 408 421-9990 603 Email: fluffy@cisco.com 605 Zach Shelby 606 ARM 607 Kidekuja 2 608 Vuokatti 88600 609 FINLAND 611 Phone: +358407796297 612 Email: Zach.Shelby@arm.com