idnits 2.17.1 draft-ietf-core-dev-urn-08.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 date (November 2, 2020) is 1271 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 informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-25 Summary: 0 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: May 6, 2021 Cisco 6 Z. Shelby 7 ARM 8 November 2, 2020 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-core-dev-urn-08 13 Abstract 15 This document describes a new Uniform Resource Name (URN) namespace 16 for 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 May 6, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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.2.1. Character Case and URN-Equivalence . . . . . . . . . 6 62 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. Security and Privacy . . . . . . . . . . . . . . . . . . 7 64 3.5. Interoperability . . . . . . . . . . . . . . . . . . . . 7 65 3.6. Resolution . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.7. Documentation . . . . . . . . . . . . . . . . . . . . . . 7 67 3.8. Additional Information . . . . . . . . . . . . . . . . . 7 68 3.9. Revision Information . . . . . . . . . . . . . . . . . . 7 69 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 7 71 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8 72 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 8 73 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9 74 4.5. Organization Product and Serial Numbers . . . . . . . . . 9 75 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 81 8.2. Informative References . . . . . . . . . . . . . . . . . 14 82 Appendix A. Changes from Previous Version . . . . . . . . . . . 15 83 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 18 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 This document describes a new Uniform Resource Name (URN) [RFC8141] 89 namespace for hardware device identifiers. A general representation 90 of device identity can be useful in many applications, such as in 91 sensor data streams and storage [RFC8428], or equipment inventories 92 [RFC7252], [I-D.ietf-core-resource-directory]. 94 A URN-based representation can be easily passed along in any 95 application that needs the information, as it fits in protocols 96 mechanisms that are designed to carry URNs [RFC7230], [RFC7540], 98 [RFC3261], [RFC7252]. Finally, URNs can also be easily carried and 99 stored in formats such as XML [W3C.REC-xml-19980210] or JSON 100 [RFC8259] [RFC8428]. Using URNs in these formats is often preferable 101 as they are universally recognized and self-describing, and therefore 102 avoid the need for agreeing to interpret an octet string as a 103 specific form of a MAC address, for instance. 105 This document defines identity URN types for situations where no such 106 convenient type already exists. For instance, [RFC6920] defines 107 cryptographic identifiers, [RFC7254] defines International Mobile 108 station Equipment Identity (IMEI) identifiers for use with 3GPP 109 cellular systems, and [RFC8464] defines Mobile Equipment Identity 110 (MEID) identifiers for use with 3GPP2 cellular systems. Those URN 111 types should be employed when such identities are transported; this 112 document does not redefine these identifiers in any way. 114 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 115 alternative way for representing device identifiers, and already 116 support MAC addresses as one of type of an identifier. However, 117 UUIDs can be inconvenient in environments where it is important that 118 the identifiers are as simple as possible and where additional 119 requirements on stable storage, real-time clocks, and identifier 120 length can be prohibitive. UUID-based identifiers are recommended 121 for all general purpose uses when MAC addresses are available as 122 identifiers. The device URN defined in this document is recommended 123 for constrained environments. 125 Future device identifier types can extend the device URN type defined 126 here, or define their own URNs. 128 Note that long-term stable unique identifiers are problematic for 129 privacy reasons and should be used with care or avoided as described 130 in [RFC7721]. 132 The rest of this document is organized as follows. Section 3 defines 133 the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 134 EUI-48 and EUI-64 addresses and 1-wire device identifiers. Section 5 135 gives examples. Section 6 discusses the security and privacy 136 considerations of the new URN type. Finally, Section 7 specifies the 137 IANA registration for the new URN type and sets requirements for 138 subtype allocations within this type. 140 2. Requirements language 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in BCP 145 14 [RFC2119] [RFC8174] when, and only when, they appear in all 146 capitals, as shown here. 148 3. DEV URN Definition 150 Namespace Identifier: "dev" requested 152 Version: 1 154 Date: 2020-06-24 156 Registrant: IETF and the CORE working group. Should the working 157 group cease to exist, discussion should be directed to the general 158 IETF discussion forums or the IESG. 160 3.1. Purpose 162 Purpose: The DEV URNs identify devices with device-specific 163 identifiers such as network card hardware addresses. DEV URN is 164 global in scope. 166 Some typical applications include equipment inventories and smart 167 object systems. 169 DEV URNs can be used in various ways in applications, software 170 systems, and network components, in tasks ranging from discovery (for 171 instance when discovering 1-wire network devices or detecting MAC- 172 addressable devices on a LAN) to intrusion detection systems and 173 simple catalogues of system information. 175 While it is possible to implement resolution systems for specific 176 applications or network locations, DEV URNs are typically not used in 177 a way that requires resolution beyond direct observation of the 178 relevant identity fields in local link communication. However, it is 179 often useful to be able to pass device identity information in 180 generic URN fields in databases or protocol fields, which makes the 181 use of URNs for this purpose convenient. 183 The DEV URN name space complements existing name spaces such as those 184 involving IMEI or UUID identifiers. DEV URNs are expected to be a 185 part of the IETF-provided basic URN types, covering identifiers that 186 have previously not been possible to use in URNs. 188 3.2. Syntax 190 Syntax: The identifier is expressed in ASCII characters and has a 191 hierarchical structure as follows: 193 devurn = "urn:dev:" body componentpart 194 body = macbody / owbody / orgbody / osbody / opsbody / otherbody 195 macbody = "mac:" hexstring 196 owbody = "ow:" hexstring 197 orgbody = "org:" number "-" identifier *( ":" identifier ) 198 osbody = "os:" number "-" serial *( ":" identifier ) 199 opsbody = "ops:" number "-" product "-" serial *( ":" identifier ) 200 otherbody = subtype ":" identifier *( ":" identifier ) 201 subtype = ALPHA *(DIGIT / ALPHA) 202 identifier = 1*unreserved 203 identifiernodash = 1*unreservednodash 204 product = identifiernodash 205 serial = identifier 206 componentpart = *( "_" identifier ) 207 unreservednodash = ALPHA / DIGIT / "." 208 unreserved = unreservednodash / "-" 209 hexstring = 1*(hexdigit hexdigit) 210 hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 211 number = 1*DIGIT 212 ALPHA = %x41-5A / %x61-7A 213 DIGIT = %x30-39 215 The above Augmented Backus-Naur Form (ABNF) copies the DIGIT and 216 ALPHA rules originally defined in [RFC5234], exactly as defined 217 there. 219 The device identity namespace includes three subtypes (see Section 4, 220 and more may be defined in the future as specified in Section 7. 222 The optional underscore-separated components following the hexstring 223 are strings depicting individual aspects of a device. The specific 224 strings and their semantics are up to the designers of the device, 225 but could be used to refer to specific interfaces or functions within 226 the device. 228 With the exception of the MAC-address and 1-Wire DEV URNs, each DEV 229 URN may also contain optional colon-separated identifiers. These are 230 provided for extensibility. 232 There are no special character encoding rules or considerations for 233 conforming with the URN syntax, beyond those applicable for URNs in 234 general [RFC8141], or the context where these URNs are carried (e.g., 235 inside JSON [RFC8259] or SenML [RFC8428]). 237 DEV URNs do not use r-, q-, or f-components. 239 Specific subtypes of DEV URNs may be validated through mechanisms 240 discussed in Section 4. 242 The string representation of the device identity URN and of the MEID 243 sub namespace is fully compatible with the URN syntax. 245 3.2.1. Character Case and URN-Equivalence 247 The DEV URN syntax allows both upper and lower case characters. The 248 URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1, 249 i.e,. two URNs are URN-equivalent if their assigned-name portions are 250 octet-by-octet equal after applying case normalization to the URI 251 scheme ("urn"), namespace identifier ("dev"), and any percent-encoded 252 characters. The rest of the DEV URN is compared in a case sensitive 253 manner. It should be noted that URN-equivalence matching merely 254 quickly shows that two URNs are definitely the same for the purposes 255 of caching and other similar uses. Two DEV URNs may still refer to 256 the same entity, and not be found URN-equivalent according to the RFC 257 8141 definition. For instance, in the ABNF syntax strings are case- 258 insensitive, and a MAC address could be represented either with 259 uppercase or lowercase hexadecimal digits. 261 Character case is not otherwise significant for the DEV URN subtypes 262 defined in this document. However, future subtypes might include 263 identifiers that use encodings such as BASE64, which encode strings 264 in a larger variety of characters, and might even encode binary data. 266 To facilitate equivalence checks, it is RECOMMENDED that 267 implementations always use lower case letters where they have a 268 choice in case, unless there is a reason otherwise. (Such a reason 269 might be, for instance, the use of a subtype that requires the use of 270 both upper case and lower case letters.) 272 3.3. Assignment 274 Assignment: The process for identifier assignment is dependent on the 275 used subtype, and documented in the specific subsection under 276 Section 4. 278 Device identifiers are generally expected to be unique, barring the 279 accidental issue of multiple devices with the same identifiers. In 280 many cases, device identifiers can also be changed by users, or 281 sometimes assigned in an algorithmic fashion. Any potential 282 conflicts arising from such assignments are not something that the 283 DEV URNs as such manage; they simply are there to refer to a 284 particular identifier. 286 The DEV URN type SHOULD only be used for persistent identifiers, such 287 as hardware-based identifiers or cryptographic identifiers based on 288 keys intended for long-term usage. 290 3.4. Security and Privacy 292 Security and Privacy: As discussed in Section 6, care must be taken 293 in the use of device-identifier-based identifiers due to their nature 294 as long-term identifiers that are not normally changeable. Leakage 295 of these identifiers outside systems where their use is justified 296 should be controlled. 298 3.5. Interoperability 300 Interoperability: There are no specific interoperability concerns. 302 3.6. Resolution 304 Resolution: The device identities are not expected to be globally 305 resolvable. No identity resolution system is expected. Systems may 306 perform local matching of identities to previously seen identities or 307 configured information, however. 309 3.7. Documentation 311 See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the 312 RFC number of this document). 314 3.8. Additional Information 316 See Section 1 for a discussion of related name spaces. 318 3.9. Revision Information 320 Revision Information: This is the first version of this registration. 322 4. DEV URN Subtypes 324 4.1. MAC Addresses 326 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 327 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 328 The EUI-64 is formed from 24 or 36 bits of organization identifier 329 followed by 40 or 28 bits of device-specific extension identifier 330 assigned by that organization. 332 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 333 identifier represented as a hexadecimal string. It is always exactly 334 16 characters long. 336 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 337 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 338 OUI of the Ethernet address (the first three octets) becomes the 339 organization identifier of the EUI-64 (the first three octets). The 340 fourth and fifth octets of the EUI are set to the fixed value FFFF 341 hexadecimal. The last three octets of the Ethernet address become 342 the last three octets of the EUI-64. The same process is used to 343 convert an EUI-48 identifier, but the fixed value FFFE is used 344 instead. 346 Identifier assignment for all of these identifiers rests within the 347 IEEE. 349 4.2. 1-Wire Device Identifiers 351 The 1-Wire* system is a device communications bus system designed by 352 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 353 64-bit identifier that consists of 8 byte family code, 48 bit 354 identifier unique within a family, and 8 bit CRC code [OW]. 356 *) 1-Wire is a registered trademark. 358 In DEV URNs with the "ow" subtype the hexstring is a representation 359 of the full 64 bit identifier as a hexadecimal string. It is always 360 exactly 16 characters long. Note that the last two characters 361 represent the 8-bit CRC code. Implementations MAY check the validity 362 of this code. 364 Family code and identifier assignment for all 1-wire devices rests 365 with the manufacturers. 367 4.3. Organization-Defined Identifiers 369 Device identifiers that have only a meaning within an organisation 370 can also be used to represent vendor-specific or experimental 371 identifiers or identifiers designed for use within the context of an 372 organisation. 374 Organisations are identified by their Private Enterprise Number (PEN) 375 [RFC2578]. These numbers can be obtained from IANA. Current PEN 376 assignments can be viewed at https://www.iana.org/assignments/ 377 enterprise-numbers/enterprise-numbers and new assignments requested 378 at https://pen.iana.org/pen/PenApplication.page. 380 When included in an "org" DEV URN, the number MUST NOT be padded with 381 extra leading zeroes. 383 4.4. Organization Serial Numbers 385 The "os" subtype specifies an organization and a serial number. 386 Organizations are identified by their PEN. As with the organization- 387 defined identifiers (Section 4.3), PEN number assignments are 388 maintained by IANA, and assignments for new organizations can be made 389 easily. 391 Editor's Note (Please remove before publication): The DEV URN "os" 392 subtype has originally been defined in the LwM2M standard, but has 393 been incorporated here to collect all syntax associated with DEV 394 URNs in one place. At the same time, the syntax of this subtype 395 was changed to avoid the possibility of characters that are not 396 allowed in SenML Name field (see [RFC8428] Section 4.5.1). 398 When included in an "os" DEV URN, the PEN number MUST NOT be 399 padded with extra leading zeroes. Organizations are also 400 encouraged to select serial number formats that avoid possibility 401 for ambiguity, in the form of leading zeroes or otherwise. 403 Organization serial number DEV URNs consist of the PEN number and the 404 serial number. As with other DEV URNs, for carrying additional 405 information and extensibility, optional colon-separated identifiers 406 and underscore-separated components may also be included. The serial 407 numbers themselves are defined by the organization, and this 408 specification does not specify how they are allocated. 410 4.5. Organization Product and Serial Numbers 412 The DEV URN "ops" subtype has originally been defined in the LwM2M 413 standard, but has been incorporated here to collect all syntax 414 associated with DEV URNs in one place. The "ops" subtype specifies 415 an organization, product class, and a serial number. Organizations 416 are identified by their PEN. Again, as with the organization-defined 417 identifiers (Section 4.3), PEN number assignments are maintained by 418 IANA. 420 Editor's Note (Please remove before publication): As with the "os" 421 subtype, the "ops" subtype has originally been defined in the 422 LwM2M standard, and its format has been slightly changed. 424 Organization product and serial number DEV URNs consist of the PEN 425 number, product class, and the serial number. As with other DEV 426 URNs, for carrying additional information and extensibility, optional 427 colon-separated identifiers and underscore-separated components may 428 also be included. Both the product class and serial numbers 429 themselves are defined by the organization, and this specification 430 does not specify how thy are allocated. 432 When included in an "ops" DEV URN, the PEN number MUST NOT be padded 433 with extra leading zeroes. Organizations are also encouraged to 434 select product and serial number formats that avoid possibility for 435 ambiguity. 437 5. Examples 439 The following three examples provide examples of MAC-based, 1-Wire, 440 and Cryptographic identifiers: 442 urn:dev:mac:0024beffff804ff1 # The MAC-48 address of 443 # 0024be804ff1, converted 444 # to EUI-64 format 446 urn:dev:mac:0024befffe804ff1 # The EUI-48 address of 447 # 0024be804ff1, converted 448 # to EUI-64 format 450 urn:dev:mac:acde48234567019f # The EUI-64 address of 451 # acde48234567019f 453 urn:dev:ow:10e2073a01080063 # The 1-Wire temperature 454 # sensor in Jari's 455 # kitchen 457 urn:dev:ow:264437f5000000ed_humidity # The laundry sensor's 458 # humidity part 460 urn:dev:ow:264437f5000000ed_temperature # The laundry sensor's 461 # temperature part 463 urn:dev:org:32473-foo # An organization- 464 # specific URN in 465 # the RFC 5612 example 466 # organisation, 32473. 468 urn:dev:os:32473-123456 # Device 123456 in 469 # the RFC 5612 example 470 # organisation 472 urn:dev:os:32473-12-34-56 # A serial number with 473 # dashes in it 475 urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial 476 # number 5002 in the 477 # RFC 5612 example 478 # organisation 480 urn:dev:newsubtype:example-1-2-3_comp # A yet-to-be-defined 481 # subtype 483 6. Security Considerations 485 On most devices, the user can display device identifiers. Depending 486 on circumstances, device identifiers may or may not be modified or 487 tampered with by the user. An implementation of the DEV URN MUST NOT 488 change these properties from what they were intended. In particular, 489 a device identifier that is intended to be immutable should not 490 become mutable as a part of implementing the DEV URN type. More 491 generally, nothing in this document should be construed to override 492 what the relevant device specifications have already said about the 493 identifiers. 495 6.1. Privacy 497 Other devices in the same network may or may not be able to identify 498 the device. For instance, on an Ethernet network, the MAC address of 499 a device is visible to all other devices. 501 The URNs generated according to the rules defined in this document 502 result in long-term stable unique identifiers for the devices. Such 503 identifiers may have privacy and security implications because they 504 may enable correlating information about a specific device over a 505 long period of time, location tracking, and device specific 506 vulnerability exploitation [RFC7721]. Also, usually there is no easy 507 way to change the identifier. Therefore these identifiers need to be 508 used with care and especially care should be taken to avoid leaking 509 them outside of the system that is intended to use the identifiers. 511 7. IANA Considerations 513 This document requests the registration of a new URN namespace for 514 "DEV", as described in Section 3. 516 IANA is asked to create a "DEV URN Subtypes" registry. The initial 517 values in this registry are as follows: 519 Subtype Description Reference 520 ------------------------------------------------------------------------ 521 mac MAC Addresses (THIS RFC) Section 4.1 522 ow 1-Wire Device Identifiers (THIS RFC) Section 4.2 523 org Organization-Defined Identifiers (THIS RFC) Section 4.3 524 os Organization Serial Numbers (THIS RFC) Section 4.4 525 ops Organization Product and Serial Numbers (THIS RFC) Section 4.5 527 Additional subtypes for DEV URNs can be defined through Specification 528 Required or IESG Approval [RFC8126]. These allocations are 529 appropriate when there is a new namespace of some type of device 530 identifiers, defined in stable fashion and with a publicly available 531 specification that can be pointed to. 533 Note that the organisation (Section 4.3) device identifiers can also 534 be used in some cases, at least as a temporary measure. It is 535 preferable, however, that long-term usage of a broadly employed 536 device identifier be registered with IETF rather than used through 537 the organisation device identifier type. 539 8. References 541 8.1. Normative References 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, 545 DOI 10.17487/RFC2119, March 1997, . 548 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 549 Schoenwaelder, Ed., "Structure of Management Information 550 Version 2 (SMIv2)", STD 58, RFC 2578, 551 DOI 10.17487/RFC2578, April 1999, . 554 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 555 Resource Identifier (URI): Generic Syntax", STD 66, 556 RFC 3986, DOI 10.17487/RFC3986, January 2005, 557 . 559 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 560 Specifications: ABNF", STD 68, RFC 5234, 561 DOI 10.17487/RFC5234, January 2008, . 564 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 565 Writing an IANA Considerations Section in RFCs", BCP 26, 566 RFC 8126, DOI 10.17487/RFC8126, June 2017, 567 . 569 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 570 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 571 . 573 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 574 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 575 May 2017, . 577 [IEEE.EUI64] 578 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 579 IEEE , unknown year, 580 . 583 [OW] IEEE, "Overview of 1-Wire(R) Technology and Its Use", 584 MAXIM 585 http://www.maxim-ic.com/app-notes/index.mvp/id/1796, June 586 2008, 587 . 589 8.2. Informative References 591 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 592 A., Peterson, J., Sparks, R., Handley, M., and E. 593 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 594 DOI 10.17487/RFC3261, June 2002, . 597 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 598 Unique IDentifier (UUID) URN Namespace", RFC 4122, 599 DOI 10.17487/RFC4122, July 2005, . 602 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 603 Protocol (HTTP/1.1): Message Syntax and Routing", 604 RFC 7230, DOI 10.17487/RFC7230, June 2014, 605 . 607 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 608 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 609 DOI 10.17487/RFC7540, May 2015, . 612 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 613 Considerations for IPv6 Address Generation Mechanisms", 614 RFC 7721, DOI 10.17487/RFC7721, March 2016, 615 . 617 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 618 Interchange Format", STD 90, RFC 8259, 619 DOI 10.17487/RFC8259, December 2017, . 622 [W3C.REC-xml-19980210] 623 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 624 Recommendation", World Wide Web Consortium FirstEdition 625 REC-xml-19980210, February 1998, 626 . 628 [OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage, 629 2018, . 631 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 632 Application Protocol (CoAP)", RFC 7252, 633 DOI 10.17487/RFC7252, June 2014, . 636 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 637 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 638 DOI 10.17487/RFC8428, August 2018, . 641 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 642 Keranen, A., and P. Hallam-Baker, "Naming Things with 643 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 644 . 646 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 647 Gosden, "A Uniform Resource Name Namespace for the Global 648 System for Mobile Communications Association (GSMA) and 649 the International Mobile station Equipment Identity 650 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, 651 . 653 [RFC8464] Atarius, R., "A URN Namespace for Device Identity and 654 Mobile Equipment Identity (MEID)", RFC 8464, 655 DOI 10.17487/RFC8464, September 2018, . 658 [I-D.ietf-core-resource-directory] 659 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 660 Amsuess, "CoRE Resource Directory", draft-ietf-core- 661 resource-directory-25 (work in progress), July 2020. 663 Appendix A. Changes from Previous Version 665 Version -08 of the WG draft took into account Barry Leiba's AD review 666 comments. To address these comments, changes were made in 668 o Further updates of the upper/lower case rules for the DEV URNs. 670 o Further updates to the ABNF. 672 o The use of HEXDIG from RFC 5234. 674 o IANA considerations for the creation of separate registry for the 675 own parameters of DEV URNs. 677 o Editorial improvements. 679 Version -07 of the WG draft took into account Carsten Bormann's 680 feedback, primarily on character case issues and editorials. 682 Version -06 of the WG draft took into account Marco Tiloca's feedback 683 before a second WGLC, primarily on further cleanup of references and 684 editorial issues. 686 Version -05 of the WG draft made some updates based on WGLC input: 687 examples for MAC-48 and EUI-48, clarification with regards to leading 688 zeroes, new recommendation with the use of lower-case letters to 689 avoid comparison problems, small update of the RFC 8141 template 690 usage, reference updates, and editorial corrections. 692 Version -04 of the WG draft cleaned up the ABNF: 694 o Parts of the ANBF now allow for use cases for the component part 695 that were not previously covered: the syntax now allows the 696 character "." to appear, and serial numbers can have dashes in 697 them. 699 o The syntax was also extended to allow for extensibility by adding 700 additional ":" separated parts for the org, op, ops, and other 701 subtypes. 703 o The ABNF was changed to include directly the ALPHA and DIGIT parts 704 imported from RFC 5234, instead of just having a verbal comment 705 about it. (Note that the style in existing RFCs differs on this.) 707 In addition, in -04 the MAC example was corrected to use the inserted 708 value ffff instead of fffe, required by Section 4.1, the org example 709 was corrected, the os: examples and otherbody examples were added. 710 The IANA rules for allocating new subtypes was slightly relaxed in 711 order to cover for new subtype cases that are brought up regularly, 712 and often not from inside the IETF. Finally, the allocation of PEN 713 numbers and the use of product classes and serial numbers was better 714 explained. 716 Version -03 of the WG draft removed some unnecessary references, 717 updated some other references, removed pct-encoding to ensure the DEV 718 URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the 719 original source of the "os" and "ops" subtypes. 721 Version -02 of the WG draft folded in the "ops" and "os" branches of 722 the dev:urn syntax from LwM2M, as they seemed to match well what 723 already existed in this document under the "org" branch. However, as 724 a part of this three changes were incorporated: 726 o The syntax for the "org:" changes to use "-" rather than ":" 727 between the OUI and the rest of the URN. 729 o The organizations for the "ops" and "os" branches have been 730 changed to use PEN numbers rather than OUI numbers [OUI]. The 731 reason for this is that PEN numbers are allocated through a 732 simpler and less costly process. However, this is a significant 733 change to how LwM2M identifiers were specified before. 735 o There were also changes to what general characters can be used in 736 the otherbody branch of the ABNF. 738 The rationale for all these changes is that it would be helpful for 739 the community collect and unify syntax between the different uses of 740 DEV URNs. If there is significant use of either the org:, os:, or 741 ops: subtypes, then changes at this point may not be warranted, but 742 otherwise unified syntax, as well as the use of PEN numbers would 743 probably be beneficial. Comments on this topic are appreciated. 745 Version -01 of the WG draft converted the draft to use the new URN 746 registration template from [RFC8141]. 748 Version -00 of the WG draft renamed the file name and fixed the ABNF 749 to correctly use "org:" rather than "dn:". 751 Version -05 made a change to the delimiter for parameters within a 752 DEV URN. Given discussions on allowed character sets in SenML 753 [RFC8428], we would like to suggest that the "_" character be used 754 instead of ";", to avoid the need to translate DEV URNs in SenML- 755 formatted communications or files. However, this reverses the 756 earlier decision to not use unreserved characters. This also means 757 that device IDs cannot use "_" characters, and have to employ other 758 characters instead. Feedback on this decision is sought. 760 Version -05 also introduced local or organisation-specific device 761 identifiers. Organisations are identified by their PEN number 762 (although we considered FQDNs as a potential alternative. The 763 authors belive an organisation-specific device identifier type will 764 make experiments and local use easier, but feedback on this point and 765 the choice of PEN numbers vs. other possible organisation identifiers 766 would be very welcome. 768 Version -05 also added some discussion of privacy concerns around 769 long-term stable identifiers. 771 Finally, version -05 clarified the situations when new allocations 772 within the registry of possible device identifier subtypes is 773 appropriate. 775 Version -04 is a refresh, as the need and interest for this 776 specification has re-emerged. And the editing author has emerged 777 back to actual engineering from the depths of IETF administration. 779 Version -02 introduced several changes. The biggest change is that 780 with the NI URNs [RFC6920], it was no longer necessary to define 781 cryptographic identifiers in this specification. Another change was 782 that we incorporated a more generic syntax for future extensions; 783 non-hexstring identifiers can now also be supported, if some future 784 device identifiers for some reason would, for instance, use BASE64. 785 As a part of this change, we also changed the component part 786 separator character from '-' to ';' so that the general format of the 787 rest of the URN can employ the unreserved characters [RFC3986]. 789 Version -03 made several minor corrections to the ABNF as well as 790 some editorial corrections. 792 Appendix B. Acknowledgments 794 The authors would like to thank Ari Keranen, Stephen Farrell, 795 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 796 Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim 797 Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba, 798 and Ahmad Muhanna for feedback and interesting discussions in this 799 problem space. We would also like to note prior documents that 800 focused on specific device identifiers, such as [RFC7254] or 801 [RFC8464]. 803 Authors' Addresses 805 Jari Arkko 806 Ericsson 807 Jorvas 02420 808 Finland 810 Email: jari.arkko@piuha.net 812 Cullen Jennings 813 Cisco 814 170 West Tasman Drive 815 San Jose, CA 95134 816 USA 818 Phone: +1 408 421-9990 819 Email: fluffy@cisco.com 820 Zach Shelby 821 ARM 822 Kidekuja 2 823 Vuokatti 88600 824 FINLAND 826 Phone: +358407796297 827 Email: Zach.Shelby@arm.com