idnits 2.17.1 draft-ietf-core-dev-urn-04.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 (December 13, 2019) is 1589 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 ---------------------------------------------------------------------------- ** 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) Summary: 2 errors (**), 0 flaws (~~), 2 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: June 15, 2020 Cisco 6 Z. Shelby 7 ARM 8 December 13, 2019 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-core-dev-urn-04 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 June 15, 2020. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . 7 67 3.9. Revision Information . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . 8 72 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 8 73 4.5. Organization Product and Serial Numbers . . . . . . . . . 8 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 8.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Appendix A. Changes from Previous Version . . . . . . . . . . . 14 81 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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], [RFC8428]. A URN-based representation can be easily 91 passed along in any application that needs the information, as it 92 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 [RFC8428] [RFC4627]. Using URNs in these formats is often 96 preferable as they are universally recognized, self-describing, and 97 therefore avoid the need for agreeing to interpret an octet string as 98 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 146 Version: 1 148 Date: 2018-03-19 150 Registration Information: This is the first registration of this 151 namespace, 2018-03-19. 153 Registrant: IETF and the CORE working group. Should the working 154 group cease to exist, discussion should be directed to the general 155 IETF discussion forums or the IESG. 157 3.1. Purpose 159 Purpose: The DEV URNs identify devices with device-specific 160 identifiers such as network card hardware addresses. DEV URN is 161 global in scope. 163 Some typical applications include equipment inventories and smart 164 object systems. 166 DEV URNs can be used in various ways in applications, software 167 systems, and network components, in tasks ranging from discovery (for 168 instance when discovering 1-wire network devices or detecting MAC- 169 addressable devices on a LAN) to intrusion detection systems and 170 simple catalogues of system information. 172 While it is possible to implement resolution systems for specific 173 applications or network locations, DEV URNs are typically not used in 174 a way that requires resolution beyond direct observation of the 175 relevant identity fields in local link communication. However, it is 176 often useful to be able to pass device identity information in 177 generic URN fields in databases or protocol fields, which makes the 178 use of URNs for this purpose convenient. 180 The DEV URN name space complements existing name spaces such as those 181 involving IMEI or UUID identifiers. DEV URNs are expeced to be a 182 part of the IETF-provided basic URN types, covering identifiers that 183 have previously not been possible to use in URNs. 185 3.2. Syntax 187 Syntax: The identifier is expressed in ASCII characters and has a 188 hierarchical structure as follows: 190 devurn = "urn:dev:" body componentpart 191 body = macbody / owbody / orgbody / osbody / opsbody / otherbody 192 macbody = "mac:" hexstring 193 owbody = "ow:" hexstring 194 orgbody = "org:" number "-" identifier *( ":" identifier ) 195 osbody = "os:" number "-" serial *( ":" identifier ) 196 opsbody = "ops:" number "-" product "-" serial *( ":" identifier ) 197 otherbody = subtype ":" identifier *( ":" identifier ) 198 subtype = ALPHA *(DIGIT / ALPHA) 199 identifier = 1*unreserved 200 identifiernodash = 1*unreservednodash 201 product = identifiernodash 202 serial = identifier 203 componentpart = *( "_" identifier ) 204 unreservednodash = ALPHA / DIGIT / "." 205 unreserved = unreservednodash / "-" 206 hexstring = 1*(hexdigit hexdigit) 207 hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 208 number = 1*DIGIT 209 ALPHA = %x41-5A / %x61-7A 210 DIGIT = %x30-39 212 The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and 213 ALPHA rules original defined in [RFC5234], exactly as defined there. 215 The device identity namespace includes three subtypes (see Section 4, 216 and more may be defined in the future as specified in Section 7. 218 The optional underscore-separated components following the hexstring 219 are strings depicting individual aspects of a device. The specific 220 strings and their semantics are up to the designers of the device, 221 but could be used to refer to specific interfaces or functions within 222 the device. 224 With the exception of the MAC-address and 1-Wire DEV URNs, each DEV 225 URN may also contain optional colon-separated identifiers. These are 226 provided for extensibility. 228 There are no special character encoding rules or considerations for 229 comforming with the URN syntax, beyond those applicable for URNs in 230 general [RFC8141], or the context where these URNs are carried (e.g., 231 inside JSON [RFC8259] or SenML [RFC8428]). 233 The lexical equivalence of the DEV URNs is defined as an exact and 234 case sensitive string match. Note that the two subtypes defined in 235 this document use only lower case letters, however. Future types 236 might use identifiers that require other encodings that require a 237 more full-blown character set (such as BASE64), however. 239 DEV URNs do not use r-, q-, or f-components. 241 Specific subtypes of DEV URNs may be validated through mechanisms 242 discussed in Section 4. 244 Finally, the string representation of the device identity URN and of 245 the MEID sub namespace is fully compatible with the URN syntax. 247 3.3. Assignment 249 Assignment: The process for identifier assignment is dependent on the 250 used subtype, and documented in the specific subsection under 251 Section 4. 253 Device identifiers are generally expected to be unique, barring the 254 accidental issue of multiple devices with the same identifiers. 256 This URN type SHOULD only be used for persistent identifiers, such as 257 hardware-based identifiers or cryptographic identifiers based on keys 258 intended for long-term usage. 260 3.4. Security and Privacy 262 Security and Privacy: As discussed in Section 6, care must be taken 263 to use device identifier-based identifiers due to their nature as a 264 long-term identifier that is often not changeable. Leakage of these 265 identifiers outside systems where their use is justfied should be 266 controlled. 268 3.5. Interoperability 270 Interoperability: There are no specific interoperability concerns. 272 3.6. Resolution 274 Resolution: The device identities are not expected to be globally 275 resolvable. No identity resolution system is expected. Systems may 276 perform local matching of identities to previously seen identities or 277 configured information, however. 279 3.7. Documentation 281 See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the 282 RFC number of this document). 284 3.8. Additional Information 286 See Section 1 for a discussion of related name spaces. 288 3.9. Revision Information 290 Revision Information: This is the first version of this registration. 292 4. DEV URN Subtypes 294 4.1. MAC Addresses 296 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 297 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 298 The EUI-64 is formed from 24 or 36 bits of organization identifier 299 followed by 40 or 28 bits of device-specific extension identifier 300 assigned by that organization. 302 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 303 identifier represented as a hexadecimal string. It is always exactly 304 16 characters long. 306 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 307 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 308 OUI of the Ethernet address (the first three octets) becomes the 309 organization identifier of the EUI-64 (the first three octets). The 310 fourth and fifth octets of the EUI are set to the fixed value FFFF 311 hexadecimal. The last three octets of the Ethernet address become 312 the last three octets of the EUI-64. The same process is used to 313 convert an EUI-48 identifier, but the fixed value FFFE is used 314 instead. 316 Identifier assignment for all of these identifiers rests within the 317 IEEE. 319 4.2. 1-Wire Device Identifiers 321 The 1-Wire* system is a device communications bus system designed by 322 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 323 64-bit identifier that consists of 8 byte family code, 48 bit 324 identifier unique within a family, and 8 bit CRC code [OW]. 326 *) 1-Wire is a registered trademark. 328 In DEV URNs with the "ow" subtype the hexstring is a representation 329 of the full 64 bit identifier as a hexadecimal string. It is always 330 exactly 16 characters long. Note that the last two characters 331 represent the 8-bit CRC code. Implementations MAY check the validity 332 of this code. 334 Family code and identifier assignment for all 1-wire devices rests 335 with the manufacturers. 337 4.3. Organization-Defined Identifiers 339 Device identifiers that have only a meaning within an organisation 340 can also be used to represent vendor-specific or experimental 341 identifiers or identifiers designed for use within the context of an 342 organisation. 344 Organisations are identified by their Private Enterprise Number (PEN) 345 [RFC2578]. These numbers can be obtained from IANA. Current PEN 346 assignments can be viewed at https://www.iana.org/assignments/ 347 enterprise-numbers/enterprise-numbers and new assignemnts requested 348 at https://pen.iana.org/pen/PenApplication.page. 350 4.4. Organization Serial Numbers 352 The "os" subtype specifies an organization and a serial number. 353 Organizations are identified by their PEN. As with the organization- 354 defined identifiers (Section 4.3), PEN number assignments are 355 maintained by IANA, and assignments for new organizations can be made 356 easily. 358 Editor's Note (Please remove before publication): The DEV URN "os" 359 subtype has originally been defined in the LwM2M standard, but has 360 been incorporated here to collect all syntax associated with DEV 361 URNs in one place. At the same time, the syntax of this subtype 362 was changed to avoid the possibility of characters that are not 363 allowed in SenML Name field (see [RFC8428] Section 4.5.1). 365 Organization serial number DEV URNs consist of the PEN number and the 366 serial number. As with other DEV URNs, for carrying additional 367 information and extensibility, optional colon-separated identifiers 368 and underscore-separated components may also be included. The serial 369 numbers themselves are defined by the organization, and this 370 specification does not specify how thy are allocated. 372 4.5. Organization Product and Serial Numbers 374 The DEV URN "ops" subtype has originally been defined in the LwM2M 375 standard, but has been incorporated here to collect all syntax 376 associated with DEV URNs in one place. The "ops" subtype specifies 377 an organization, product class, and a serial number. Organizations 378 are identified by their PEN. Again, as with the organization-defined 379 identifiers (Section 4.3), PEN number assignments are maintained by 380 IANA. 382 Editor's Note (Please remove before publication): As with the "os" 383 subtype, the "ops" subtype has originally been defined in the 384 LwM2M standard, and its format has been slightly changed. 386 Organization product and serial number DEV URNs consist of the PEN 387 number, product class, and the serial number. As with other DEV 388 URNs, for carrying additional information and extensibility, optional 389 colon-separated identifiers and underscore-separated components may 390 also be included. Both the product class and serial numbers 391 themselves are defined by the organization, and this specification 392 does not specify how thy are allocated. 394 5. Examples 396 The following three examples provide examples of MAC-based, 1-Wire, 397 and Cryptographic identifiers: 399 urn:dev:mac:0024beffff804ff1 # The MAC address of 400 # Jari's laptop, for 401 # the MAC address 402 # 0024be804ff1 404 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 405 # sensor in Jari's 406 # kitchen 408 urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's 409 # humidity part 411 urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's 412 # temperature part 414 urn:dev:org:32473-foo # An organization- 415 # specific URN in 416 # the RFC 5612 example 417 # organisation, 32473. 419 urn:dev:os:32473-123456 # Device 123456 in 420 # the RFC 5612 example 421 # organisation 423 urn:dev:os:32473-12-34-56 # A serial number with 424 # dashes in it 426 urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial 427 # number 5002 in the 428 # RFC 5612 example 429 # organisation 431 urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined 432 # subtype 434 6. Security Considerations 436 On most devices, the user can display device identifiers. Depending 437 on circumstances, device identifiers may or may not be modified or 438 tampered by the user. An implementation of the DEV URN MUST NOT 439 change these properties from what they were intended. In particular, 440 a device identifier that is intended to be immutable should not 441 become mutable as a part of implementing the DEV URN type. More 442 generally, nothing in this memo should be construed to override what 443 the relevant device specifications have already said about the 444 identifiers. 446 Other devices in the same network may or may not be able to identify 447 the device. For instance, on Ethernet network, the MAC address of a 448 device is visible to all other devices. 450 The URNs generated according to the rules defined in this document 451 result in long-term stable unique identifiers for the devices. Such 452 identifiers may have privacy and security implications because they 453 may enable correlating information about a specific device over a 454 long period of time, location tracking, and device specific 455 vulnerability exploitation [RFC7721]. Also, usually there is no easy 456 way to change the identifier. Therefore these identifiers need to be 457 used with care and especially care should be taken avoid leaking them 458 outside of the system that is intended to use the identifiers. 460 7. IANA Considerations 462 This document requests the registration of a new URN namespace for 463 "DEV", as described in Section 3. 465 Additional subtypes for DEV URNs can be defined through Specification 466 Required or IESG Approval [RFC5226]. 468 Such allocations are appropriate when there is a new namespace of 469 some type of device identifiers, defined in stable fashion and with a 470 publicly available specification that can be pointed to. 472 Note that the organisation (Section 4.3) device identifiers can also 473 be used in some cases, at least as a temporary measure. It is 474 preferrable, however, that long-term usage of a broadly employed 475 device identifier be registered with IETF rather than used through 476 the organisation device identifier type. 478 8. References 480 8.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, 484 DOI 10.17487/RFC2119, March 1997, . 487 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 488 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 489 . 491 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 492 Schoenwaelder, Ed., "Structure of Management Information 493 Version 2 (SMIv2)", STD 58, RFC 2578, 494 DOI 10.17487/RFC2578, April 1999, . 497 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 498 "Uniform Resource Names (URN) Namespace Definition 499 Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002, 500 . 502 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 503 Resource Identifier (URI): Generic Syntax", STD 66, 504 RFC 3986, DOI 10.17487/RFC3986, January 2005, 505 . 507 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 508 IANA Considerations Section in RFCs", RFC 5226, 509 DOI 10.17487/RFC5226, May 2008, . 512 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 513 Specifications: ABNF", STD 68, RFC 5234, 514 DOI 10.17487/RFC5234, January 2008, . 517 [IEEE.EUI64] 518 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 519 IEEE , unknown year, 520 . 523 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 524 MAXIM 525 http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June 526 2008, 527 . 529 8.2. Informative References 531 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 532 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 533 Transfer Protocol -- HTTP/1.1", RFC 2616, 534 DOI 10.17487/RFC2616, June 1999, . 537 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 538 A., Peterson, J., Sparks, R., Handley, M., and E. 539 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 540 DOI 10.17487/RFC3261, June 2002, . 543 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 544 Unique IDentifier (UUID) URN Namespace", RFC 4122, 545 DOI 10.17487/RFC4122, July 2005, . 548 [RFC4627] Crockford, D., "The application/json Media Type for 549 JavaScript Object Notation (JSON)", RFC 4627, 550 DOI 10.17487/RFC4627, July 2006, . 553 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 554 Considerations for IPv6 Address Generation Mechanisms", 555 RFC 7721, DOI 10.17487/RFC7721, March 2016, 556 . 558 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 559 Interchange Format", STD 90, RFC 8259, 560 DOI 10.17487/RFC8259, December 2017, . 563 [W3C.REC-xml-19980210] 564 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 565 Recommendation", World Wide Web Consortium FirstEdition 566 REC-xml-19980210, February 1998, 567 . 569 [OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage, 570 2018, . 572 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 573 Application Protocol (CoAP)", RFC 7252, 574 DOI 10.17487/RFC7252, June 2014, . 577 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 578 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 579 DOI 10.17487/RFC8428, August 2018, . 582 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 583 Keranen, A., and P. Hallam-Baker, "Naming Things with 584 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 585 . 587 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 588 Gosden, "A Uniform Resource Name Namespace for the Global 589 System for Mobile Communications Association (GSMA) and 590 the International Mobile station Equipment Identity 591 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, 592 . 594 [I-D.atarius-dispatch-meid-urn] 595 Atarius, R., "A Uniform Resource Name Namespace for the 596 Device Identity and the Mobile Equipment Identity (MEID)", 597 draft-atarius-dispatch-meid-urn-18 (work in progress), 598 June 2018. 600 Appendix A. Changes from Previous Version 602 Version -04 of the WG draft cleaned up the ABNF: 604 o Parts of the ANBF now allow for use cases for the component part 605 that were not previously covered: the syntax now allows the 606 character "." to appear, and serial numbers can have dashes in 607 them. 609 o The syntax was also extended to allow for extensibility by adding 610 additional ":" separated parts for the org, op, ops, and other 611 subtypes. 613 o The ABNF was changed to include directly the ALPHA and DIGIT parts 614 imported from RFC 5234, instead of just having a verbal comment 615 about it. (Note that the style in existing RFCs differs on this.) 617 In addition, in -04 the MAC example was corrected to use the inserted 618 value ffff instead of fffe, required by Section 4.1, the org example 619 was corrected, the os: examples and otherbody examples were added. 620 The IANA rules for allocating new subtypes was slightly relaxed in 621 order to cover for new subtype cases that are brought up regularly, 622 and often not from inside the IETF. Finally, the allocation of PEN 623 numbers and the use of product classes and serial numbers was better 624 explained. 626 Version -03 of the WG draft removed some unnecessary references, 627 updated some other references, removed pct-encoding to ensure the DEV 628 URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the 629 original source of the "os" and "ops" subtypes. 631 Version -02 of the WG draft folded in the "ops" and "os" branches of 632 the dev:urn syntax from LwM2M, as they seemed to match well what 633 already existed in this memo under the "org" branch. However, as a 634 part of this three changes were incorporated: 636 o The syntax for the "org:" changes to use "-" rather than ":" 637 between the OUI and the rest of the URN. 639 o The organizations for the "ops" and "os" branches have been 640 changed to use PEN numbers rather than OUI numbers [OUI]. The 641 reason for this is that PEN numbers are allocated through a 642 simpler and less costly process. However, this is a significant 643 change to how LwM2M identifiers were specified before. 645 o There were also changes to what general characters can be used in 646 the otherbody branch of the ABNF. 648 The rationale for all these changes is that it would be helpful for 649 the community collect and unify syntax between the different uses of 650 DEV URNs. If there is significant use of either the org:, os:, or 651 ops: subtypes, then changes at this point may not be warranted, but 652 otherwise unified syntax, as well as the use of PEN numbers would 653 probably be beneficial. Comments on this topic are appreciated. 655 Version -01 of the WG draft converted the draft to use the new URN 656 registration template from [RFC8141]. 658 Version -00 of the WG draft renamed the file name and fixed the ABNF 659 to correctly use "org:" rather than "dn:". 661 Version -05 made a change to the delimiter for parameters within a 662 DEV URN. Given discussions on allowed character sets in SenML 663 [RFC8428], we would like to suggest that the "_" character be used 664 instead of ";", to avoid the need to translate DEV URNs in SenML- 665 formatted communications or files. However, this reverses the 666 earlier decision to not use unreserved characters. This also means 667 that device IDs cannot use "_" characters, and have to employ other 668 characters instead. Feedback on this decision is sought. 670 Version -05 also introduced local or organisation-specific device 671 identifiers. Organisations are identified by their PEN number 672 (although we considered FQDNs as a potential alternative. The 673 authors belive an organisation-specific device identifier type will 674 make experiments and local use easier, but feedback on this point and 675 the choice of PEN numbers vs. other possible organisation identifiers 676 would be very welcome. 678 Version -05 also added some discussion of privacy concerns around 679 long-term stable identifiers. 681 Finally, version -05 clarified the situations when new allocations 682 within the registry of possible device identifier subtypes is 683 appropriate. 685 Version -04 is a refresh, as the need and interest for this 686 specification has re-emerged. And the editing author has emerged 687 back to actual engineering from the depths of IETF administration. 689 Version -02 introduced several changes. The biggest change is that 690 with the NI URNs [RFC6920], it was no longer necessary to define 691 cryptographic identifiers in this specification. Another change was 692 that we incorporated a more generic syntax for future extensions; 693 non-hexstring identifiers can now also be supported, if some future 694 device identifiers for some reason would, for instance, use BASE64. 695 As a part of this change, we also changed the component part 696 separator character from '-' to ';' so that the general format of the 697 rest of the URN can employ the unreserved characters [RFC3986]. 699 Version -03 made several minor corrections to the ABNF as well as 700 some editorial corrections. 702 Appendix B. Acknowledgments 704 The authors would like to thank Ari Keranen, Stephen Farrell, 705 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 706 Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, and 707 Ahmad Muhanna for interesting discussions in this problem space. We 708 would also like to note prior documents that focused on specific 709 device identifiers, such as [RFC7254] or 710 [I-D.atarius-dispatch-meid-urn]. 712 Authors' Addresses 714 Jari Arkko 715 Ericsson 716 Jorvas 02420 717 Finland 719 Email: jari.arkko@piuha.net 720 Cullen Jennings 721 Cisco 722 170 West Tasman Drive 723 San Jose, CA 95134 724 USA 726 Phone: +1 408 421-9990 727 Email: fluffy@cisco.com 729 Zach Shelby 730 ARM 731 Kidekuja 2 732 Vuokatti 88600 733 FINLAND 735 Phone: +358407796297 736 Email: Zach.Shelby@arm.com