idnits 2.17.1 draft-ietf-core-dev-urn-10.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 13, 2021) is 1192 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'OW' -- 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-26 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 6 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: Standards Track C. Jennings 5 Expires: July 17, 2021 Cisco 6 Z. Shelby 7 ARM 8 January 13, 2021 10 Uniform Resource Names for Device Identifiers 11 draft-ietf-core-dev-urn-10 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 passed along in applications that need the 20 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 July 17, 2021. 39 Copyright Notice 41 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 4 58 3. DEV URN Definition . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. Character Case and URN-Equivalence . . . . . . . . . 6 62 3.3. Assignment . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . 8 69 4. DEV URN Subtypes . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. 1-Wire Device Identifiers . . . . . . . . . . . . . . . . 8 72 4.3. Organization-Defined Identifiers . . . . . . . . . . . . 9 73 4.4. Organization Serial Numbers . . . . . . . . . . . . . . . 9 74 4.5. Organization Product and Serial Numbers . . . . . . . . . 10 75 4.6. Future Subtypes . . . . . . . . . . . . . . . . . . . . . 10 76 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 6.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.2. Validity . . . . . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Appendix A. Changes from Previous Version . . . . . . . . . . . 16 85 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 This document describes a new Uniform Resource Name (URN) [RFC8141] 91 namespace for hardware device identifiers. A general representation 92 of device identity can be useful in many applications, such as in 93 sensor data streams and storage [RFC8428], or equipment inventories 94 [RFC7252], [I-D.ietf-core-resource-directory]. 96 A URN-based representation can be passed along in applications that 97 need the information. It fits particularly well for protocols 98 mechanisms that are designed to carry URNs [RFC7230], [RFC7540], 99 [RFC3261], [RFC7252]. Finally, URNs can also be easily carried and 100 stored in formats such as XML [W3C.REC-xml-19980210] or JSON 101 [RFC8259] [RFC8428]. Using URNs in these formats is often preferable 102 as they are universally recognized and self-describing, and therefore 103 avoid the need for agreeing to interpret an octet string as a 104 specific form of a MAC address, for instance. Passing URNs may 105 consume additional bytes compared to, for instance, passing 4-byte 106 binary IPv4 addresses, but offers some flexibility in return. 108 This document defines identifier URN types for situations where no 109 such convenient type already exists. For instance, [RFC6920] defines 110 cryptographic identifiers, [RFC7254] defines International Mobile 111 station Equipment Identity (IMEI) identifiers for use with 3GPP 112 cellular systems, and [RFC8464] defines Mobile Equipment Identity 113 (MEID) identifiers for use with 3GPP2 cellular systems. Those URN 114 types should be employed when such identifiers are transported; this 115 document does not redefine these identifiers in any way. 117 Universally Unique IDentifier (UUID) URNs [RFC4122] are another 118 alternative way for representing device identifiers, and already 119 support MAC addresses as one type of an identifier. However, UUIDs 120 can be inconvenient in environments where it is important that the 121 identifiers are as simple as possible and where additional 122 requirements on stable storage, real-time clocks, and identifier 123 length can be prohibitive. UUID-based identifiers are recommended 124 for all general purpose uses when MAC addresses are available as 125 identifiers. The device URN defined in this document is recommended 126 for constrained environments. 128 Future device identifier types can extend the device URN type defined 129 here, or define their own URNs. 131 Note that long-term stable unique identifiers are problematic for 132 privacy reasons and should be used with care as described in 133 [RFC7721]. 135 The rest of this document is organized as follows. Section 3 defines 136 the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, 137 EUI-48 and EUI-64 addresses and 1-Wire device identifiers. Section 5 138 gives examples. Section 6 discusses the security and privacy 139 considerations of the new URN type. Finally, Section 7 specifies the 140 IANA registration for the new URN type and sets requirements for 141 subtype allocations within this type. 143 2. Requirements language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3. DEV URN Definition 153 Namespace Identifier: "dev" requested 155 Version: 1 157 Date: 2020-06-24 159 Registrant: IETF and the CORE working group. Should the working 160 group cease to exist, discussion should be directed to the 161 application area or general IETF discussion forums, or the IESG. 163 3.1. Purpose 165 Purpose: The DEV URNs identify devices with device-specific 166 identifiers such as network card hardware addresses. DEV URNs are 167 scoped to be globally applicable (see [RFC8141] Section 6.4.1) and, 168 in general, enable systems to use these identifiers from multiple 169 sources in an interoperable manner. Note that in some deployments, 170 ensuring uniqueness requires care if manual or local assignment 171 mechanisms are used, as discussed in Section 3.3. 173 Some typical DEV URN applications include equipment inventories and 174 smart object systems. 176 DEV URNs can be used in various ways in applications, software 177 systems, and network components, in tasks ranging from discovery (for 178 instance when discovering 1-Wire network devices or detecting MAC- 179 addressable devices on a LAN) to intrusion detection systems and 180 simple catalogues of system information. 182 While it is possible to implement resolution systems for specific 183 applications or network locations, DEV URNs are typically not used in 184 a way that requires resolution beyond direct observation of the 185 relevant identifier fields in local link communication. However, it 186 is often useful to be able to pass device identifier information in 187 generic URN fields in databases or protocol fields, which makes the 188 use of URNs for this purpose convenient. 190 The DEV URN name space complements existing name spaces such as those 191 involving IMEI or UUID identifiers. DEV URNs are expected to be a 192 part of the IETF-provided basic URN types, covering identifiers that 193 have previously not been possible to use in URNs. 195 3.2. Syntax 197 Syntax: The identifier is expressed in ASCII characters and has a 198 hierarchical structure as follows: 200 devurn = "urn:dev:" body componentpart 201 body = macbody / owbody / orgbody / osbody / opsbody / otherbody 202 macbody = %s "mac:" hexstring 203 owbody = %s "ow:" hexstring 204 orgbody = %s "org:" posnumber "-" identifier *( ":" identifier ) 205 osbody = %s "os:" posnumber "-" serial *( ":" identifier ) 206 opsbody = %s "ops:" posnumber "-" product "-" serial *( ":" identifier ) 207 otherbody = subtype ":" identifier *( ":" identifier ) 208 subtype = LALPHA *(DIGIT / LALPHA) 209 identifier = 1*devunreserved 210 identifiernodash = 1*devunreservednodash 211 product = identifiernodash 212 serial = identifier 213 componentpart = *( "_" identifier ) 214 devunreservednodash = ALPHA / DIGIT / "." 215 devunreserved = devunreservednodash / "-" 216 hexstring = 1*(hexdigit hexdigit) 217 hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" 218 posnumber = NZDIGIT *DIGIT 219 ALPHA = %x41-5A / %x61-7A 220 LALPHA = %x41-5A 221 NZDIGIT = %x31-39 222 DIGIT = %x30-39 224 The above syntax is represented in Augmented Backus-Naur Form (ABNF) 225 form as defined in [RFC5234] and [RFC7405]. The syntax also copies 226 the DIGIT and ALPHA rules originally defined in [RFC5234], exactly as 227 defined there. 229 The device identifier namespace includes five subtypes (see 230 Section 4, and more may be defined in the future as specified in 231 Section 7. 233 The optional underscore-separated components at the end of the DEV 234 URN depict individual aspects of a device. The specific strings and 235 their semantics are up to the designers of the device, but could be 236 used to refer to specific interfaces or functions within the device. 238 With the exception of the MAC-address and 1-Wire DEV URNs, each DEV 239 URN may also contain optional colon-separated identifiers. These are 240 provided for extensibility. 242 There are no special character encoding rules or considerations for 243 conforming with the URN syntax, beyond those applicable for URNs in 244 general [RFC8141], or the context where these URNs are carried (e.g., 245 inside JSON [RFC8259] or SenML [RFC8428]). Due to the SenML RFC 8428 246 Section 4.5.1 rules, it is not desirable to use percent-encoding in 247 DEV URNs, and the subtypes defined in this specification do not 248 really benefit from percent-encoding. However, this specification 249 does not deviate from the general syntax of URNs or their processing 250 and normalization rules as specified in [RFC3986] and [RFC8141]. 252 DEV URNs do not use r-, q-, or f-components as defined in [RFC8141]. 254 Specific subtypes of DEV URNs may be validated through mechanisms 255 discussed in Section 4. 257 The string representation of the device identifier URN is fully 258 compatible with the URN syntax. 260 3.2.1. Character Case and URN-Equivalence 262 The DEV URN syntax allows both upper and lower case characters. The 263 URN-equivalence of the DEV URNs is defined per [RFC8141] Section 3.1, 264 i.e., two URNs are URN-equivalent if their assigned-name portions are 265 octet-by-octet equal after applying case normalization to the URI 266 scheme ("urn") and namespace identifier ("dev"). The rest of the DEV 267 URN is compared in a case sensitive manner. It should be noted that 268 URN-equivalence matching merely quickly shows that two URNs are 269 definitely the same for the purposes of caching and other similar 270 uses. Two DEV URNs may still refer to the same entity, and not be 271 found URN-equivalent according to the RFC 8141 definition. For 272 instance, in ABNF, strings are case-insensitive (see [RFC5234] 273 Section 2.3), and a MAC address could be represented either with 274 uppercase or lowercase hexadecimal digits. 276 Character case is not otherwise significant for the DEV URN subtypes 277 defined in this document. However, future subtypes might include 278 identifiers that use encodings such as BASE64, which encode strings 279 in a larger variety of characters, and might even encode binary data. 281 To facilitate equivalence checks, it is RECOMMENDED that 282 implementations always use lower case letters where they have a 283 choice in case, unless there is a reason otherwise. (Such a reason 284 might be, for instance, the use of a subtype that requires the use of 285 both upper case and lower case letters.) 287 3.3. Assignment 289 Assignment: The process for identifier assignment is dependent on the 290 used subtype, and documented in the specific subsection under 291 Section 4. 293 Device identifiers are generally expected to identify a unique 294 device, barring the accidental issue of multiple devices with the 295 same identifiers. In many cases, device identifiers can also be 296 changed by users, or sometimes assigned in an algorithmic or local 297 fashion. Any potential conflicts arising from such assignments are 298 not something that the DEV URNs as such manage; they simply are there 299 to refer to a particular identifier. And of course, a single device 300 may (and often does) have multiple identifiers, e.g., identifiers 301 associated with different link technologies it supports. 303 The DEV URN type SHOULD only be used for persistent identifiers, such 304 as hardware-based identifiers. 306 3.4. Security and Privacy 308 Security and Privacy: As discussed in Section 6, care must be taken 309 in the use of device-identifier-based identifiers due to their nature 310 as long-term identifiers that are not normally changeable. Leakage 311 of these identifiers outside systems where their use is justified 312 should be controlled. 314 3.5. Interoperability 316 Interoperability: There are no specific interoperability concerns. 318 3.6. Resolution 320 Resolution: The device identifiers are not expected to be globally 321 resolvable. No identifier resolution system is expected. Systems 322 may perform local matching of identifiers to previously seen 323 identifiers or configured information, however. 325 3.7. Documentation 327 See RFC NNNN (RFC Editor: Please replace NNNN by a reference to the 328 RFC number of this document). 330 3.8. Additional Information 332 See Section 1 for a discussion of related name spaces. 334 3.9. Revision Information 336 Revision Information: This is the first version of this registration. 338 4. DEV URN Subtypes 340 4.1. MAC Addresses 342 DEV URNs of the "mac" subtype are based on the EUI-64 identifier 343 [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. 344 The EUI-64 is formed from 24 or 36 bits of organization identifier 345 followed by 40 or 28 bits of device-specific extension identifier 346 assigned by that organization. 348 In the DEV URN "mac" subtype the hexstring is simply the full EUI-64 349 identifier represented as a hexadecimal string. It is always exactly 350 16 characters long. 352 MAC-48 and EUI-48 identifiers are also supported by the same DEV URN 353 subtype. To convert a MAC-48 address to an EUI-64 identifier, The 354 OUI of the MAC-48 address (the first three octets) becomes the 355 organization identifier of the EUI-64 (the first three octets). The 356 fourth and fifth octets of the EUI are set to the fixed value FFFF 357 hexadecimal. The last three octets of the MAC-48 address become the 358 last three octets of the EUI-64. The same process is used to convert 359 an EUI-48 identifier, but the fixed value FFFE is used instead. 361 Identifier assignment for all of these identifiers rests within the 362 IEEE Registration Authority. 364 4.2. 1-Wire Device Identifiers 366 The 1-Wire* system is a device communications bus system designed by 367 Dallas Semiconductor Corporation. 1-Wire devices are identified by a 368 64-bit identifier that consists of 8 bit family code, 48 bit 369 identifier unique within a family, and 8 bit CRC code [OW]. 371 *) 1-Wire is a registered trademark. 373 In DEV URNs with the "ow" subtype the hexstring is a representation 374 of the full 64 bit identifier as a hexadecimal string. It is always 375 exactly 16 characters long. Note that the last two characters 376 represent the 8-bit CRC code. Implementations MAY check the validity 377 of this code. 379 Family code and identifier assignment for all 1-Wire devices rests 380 with the manufacturers. 382 4.3. Organization-Defined Identifiers 384 Device identifiers that have only a meaning within an organization 385 can also be used to represent vendor-specific or experimental 386 identifiers or identifiers designed for use within the context of an 387 organization. 389 Organizations are identified by their Private Enterprise Number (PEN) 390 [RFC2578]. These numbers can be obtained from IANA. Current PEN 391 assignments can be viewed at https://www.iana.org/assignments/ 392 enterprise-numbers/enterprise-numbers and new assignments requested 393 at https://pen.iana.org/pen/PenApplication.page. 395 Note that when included in an "org" DEV URN, the number can not be 396 zero or have leading zeroes, as the ABNF requires the number to start 397 with a non-zero digit. 399 4.4. Organization Serial Numbers 401 The "os" subtype specifies an organization and a serial number. 402 Organizations are identified by their PEN. As with the organization- 403 defined identifiers (Section 4.3), PEN number assignments are 404 maintained by IANA, and assignments for new organizations can be made 405 easily. 407 Historical note: The "os" subtype was originally been defined in 408 the Open Mobile Alliance "Lightweight Machine to Machine" standard 409 [LwM2M], but has been incorporated here to collect all syntax 410 associated with DEV URNs in one place. At the same time, the 411 syntax of this subtype was changed to avoid the possibility of 412 characters that are not allowed in SenML Name field (see [RFC8428] 413 Section 4.5.1). 415 Organization serial number DEV URNs consist of the PEN number and the 416 serial number. As with other DEV URNs, for carrying additional 417 information and extensibility, optional colon-separated identifiers 418 and underscore-separated components may also be included. The serial 419 numbers themselves are defined by the organization, and this 420 specification does not specify how they are allocated. 422 Organizations are also encouraged to select serial number formats 423 that avoid possibility for ambiguity, in the form of leading zeroes 424 or otherwise. 426 4.5. Organization Product and Serial Numbers 428 The DEV URN "ops" subtype has originally been defined in the LwM2M 429 standard, but has been incorporated here to collect all syntax 430 associated with DEV URNs in one place. The "ops" subtype specifies 431 an organization, product class, and a serial number. Organizations 432 are identified by their PEN. Again, as with the organization-defined 433 identifiers (Section 4.3), PEN number assignments are maintained by 434 IANA. 436 Historical note: As with the "os" subtype, the "ops" subtype has 437 originally been defined in OMA. 439 Organization product and serial number DEV URNs consist of the PEN 440 number, product class, and the serial number. As with other DEV 441 URNs, for carrying additional information and extensibility, optional 442 colon-separated identifiers and underscore-separated components may 443 also be included. Both the product class and serial numbers 444 themselves are defined by the organization, and this specification 445 does not specify how they are allocated. 447 Organizations are also encouraged to select product and serial number 448 formats that avoid possibility for ambiguity. 450 4.6. Future Subtypes 452 Additional subtypes may be defined in other, future specifications. 453 See Section 7. 455 The DEV URN "example" subtype is reserved for use in examples. It 456 has no specific requirements beyond those expressed by the ABNF in 457 Section 3.2. 459 5. Examples 461 The following provides some examples of DEV URNs: 463 urn:dev:mac:0024beffff804ff1 # The MAC-48 address of 464 # 0024be804ff1, converted 465 # to EUI-64 format 467 urn:dev:mac:0024befffe804ff1 # The EUI-48 address of 468 # 0024be804ff1, converted 469 # to EUI-64 format 471 urn:dev:mac:acde48234567019f # The EUI-64 address of 472 # acde48234567019f 474 urn:dev:ow:10e2073a01080063 # A 1-Wire temperature 475 # sensor 477 urn:dev:ow:264437f5000000ed_humidity # The humidity 478 # part of a multi-sensor 479 # device 481 urn:dev:ow:264437f5000000ed_temperature # The temperature 482 # part of a multi-sensor 483 # device 485 urn:dev:org:32473-foo # An organization- 486 # specific URN in 487 # the RFC 5612 example 488 # organization, 32473. 490 urn:dev:os:32473-123456 # Device 123456 in 491 # the RFC 5612 example 492 # organization 494 urn:dev:os:32473-12-34-56 # A serial number with 495 # dashes in it 497 urn:dev:ops:32473-Refrigerator-5002 # Refrigerator serial 498 # number 5002 in the 499 # RFC 5612 example 500 # organization 502 urn:dev:example:new-1-2-3_comp # An example of something 503 # that is not defined today, 504 # and is not one of the 505 # mac, ow, os, or ops 506 # subtypes 508 The DEV URNs themselves can then appear in various contexts. A 509 simple example of this is the use of DEV URNs in SenML data. For 510 example, this example from [RFC8428] shows a measurement from a 511 1-Wire temperature gauge encoded in the JSON syntax. 513 [ 514 {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1} 515 ] 517 6. Security Considerations 519 On most devices, the user can display device identifiers. Depending 520 on circumstances, device identifiers may or may not be modified or 521 tampered with by the user. An implementation of the DEV URN MUST 522 preserve such limitations and behaviors associated with the device 523 identifiers. In particular, a device identifier that is intended to 524 be immutable should not become mutable as a part of implementing the 525 DEV URN type. More generally, nothing in this document should be 526 construed to override what the relevant device specifications have 527 already said about the identifiers. 529 6.1. Privacy 531 Other devices in the same network may or may not be able to identify 532 the device. For instance, on an Ethernet network, the MAC address of 533 a device is visible to all other devices. 535 DEV URNs often represent long-term stable unique identifiers for 536 devices. Such identifiers may have privacy and security implications 537 because they may enable correlating information about a specific 538 device over a long period of time, location tracking, and device 539 specific vulnerability exploitation [RFC7721]. Also, usually there 540 is no easy way to change the identifier. Therefore these identifiers 541 need to be used with care and especially care should be taken to 542 avoid leaking them outside of the system that is intended to use the 543 identifiers. 545 6.2. Validity 547 Information about identifiers may have significant effects in some 548 applications. For instance, in many sensor systems the identifier 549 information is used for deciding how to use the data carried in a 550 measurement report. On some other systems, identifiers may be used 551 in policy decisions. 553 It is important that systems are designed to take into account the 554 possibility of devices reporting incorrect identifiers (either 555 accidentally or maliciously) and the manipulation of identifiers in 556 communications by illegitimate entities on the path. Integrity 557 protection of communications or data objects, the use of trusted 558 devices, and various management practices can help address these 559 issues. 561 7. IANA Considerations 563 This document requests the registration of a new URN namespace for 564 "DEV", as described in Section 3. 566 IANA is asked to create a "DEV URN Subtypes" registry. The initial 567 values in this registry are as follows: 569 Subtype Description Reference 570 ------------------------------------------------------------------------ 571 mac MAC Addresses (THIS RFC) Section 4.1 572 ow 1-Wire Device Identifiers (THIS RFC) Section 4.2 573 org Organization-Defined Identifiers (THIS RFC) Section 4.3 574 os Organization Serial Numbers (THIS RFC) Section 4.4 575 ops Organization Product and Serial Numbers (THIS RFC) Section 4.5 576 example Reserved for examples (THIS RFC) Section 4.6 578 Additional subtypes for DEV URNs can be defined through Specification 579 Required or IESG Approval [RFC8126]. These allocations are 580 appropriate when there is a new namespace of some type of device 581 identifiers, defined in stable fashion and with a publicly available 582 specification. 584 Note that the organization (Section 4.3) device identifiers can also 585 be used in some cases, at least as a temporary measure. It is 586 preferable, however, that long-term usage of a broadly employed 587 device identifier be registered with IETF rather than used through 588 the organization device identifier type. 590 8. References 592 8.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, 596 DOI 10.17487/RFC2119, March 1997, . 599 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 600 Schoenwaelder, Ed., "Structure of Management Information 601 Version 2 (SMIv2)", STD 58, RFC 2578, 602 DOI 10.17487/RFC2578, April 1999, . 605 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 606 Resource Identifier (URI): Generic Syntax", STD 66, 607 RFC 3986, DOI 10.17487/RFC3986, January 2005, 608 . 610 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 611 Specifications: ABNF", STD 68, RFC 5234, 612 DOI 10.17487/RFC5234, January 2008, . 615 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 616 Writing an IANA Considerations Section in RFCs", BCP 26, 617 RFC 8126, DOI 10.17487/RFC8126, June 2017, 618 . 620 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 621 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 622 . 624 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 625 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 626 May 2017, . 628 [IEEE.EUI64] 629 IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", 630 IEEE , unknown year, 631 . 634 [OW] Maxim, "Guide to 1-Wire Communication", MAXIM 635 https://www.maximintegrated.com/en/design/technical- 636 documents/tutorials/1/1796.html, June 2008, 637 . 640 8.2. Informative References 642 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 643 A., Peterson, J., Sparks, R., Handley, M., and E. 644 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 645 DOI 10.17487/RFC3261, June 2002, . 648 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 649 Unique IDentifier (UUID) URN Namespace", RFC 4122, 650 DOI 10.17487/RFC4122, July 2005, . 653 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 654 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 655 . 657 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 658 Protocol (HTTP/1.1): Message Syntax and Routing", 659 RFC 7230, DOI 10.17487/RFC7230, June 2014, 660 . 662 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 663 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 664 DOI 10.17487/RFC7540, May 2015, . 667 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 668 Considerations for IPv6 Address Generation Mechanisms", 669 RFC 7721, DOI 10.17487/RFC7721, March 2016, 670 . 672 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 673 Interchange Format", STD 90, RFC 8259, 674 DOI 10.17487/RFC8259, December 2017, . 677 [W3C.REC-xml-19980210] 678 Sperberg-McQueen, C., Bray, T., and J. Paoli, "XML 1.0 679 Recommendation", World Wide Web Consortium FirstEdition 680 REC-xml-19980210, February 1998, 681 . 683 [OUI] IEEE, SA., "Registration Authority", IEEE-SA webpage, 684 2018, . 686 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 687 Application Protocol (CoAP)", RFC 7252, 688 DOI 10.17487/RFC7252, June 2014, . 691 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 692 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 693 DOI 10.17487/RFC8428, August 2018, . 696 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 697 Keranen, A., and P. Hallam-Baker, "Naming Things with 698 Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, 699 . 701 [RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. 702 Gosden, "A Uniform Resource Name Namespace for the Global 703 System for Mobile Communications Association (GSMA) and 704 the International Mobile station Equipment Identity 705 (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, 706 . 708 [RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", 709 RFC 7405, DOI 10.17487/RFC7405, December 2014, 710 . 712 [RFC8464] Atarius, R., "A URN Namespace for Device Identity and 713 Mobile Equipment Identity (MEID)", RFC 8464, 714 DOI 10.17487/RFC8464, September 2018, . 717 [I-D.ietf-core-resource-directory] 718 Amsuess, C., Shelby, Z., Koster, M., Bormann, C., and P. 719 Stok, "CoRE Resource Directory", draft-ietf-core-resource- 720 directory-26 (work in progress), November 2020. 722 [LwM2M] "OMA Lightweight Machine to Machine Requirements", OMA 723 Standard Candidate Version 1.2, January 2019. 725 Appendix A. Changes from Previous Version 727 Editor's note: Please remove this section before publication. 729 Version -10 made the following changes: 731 o Restricted the case of "mac", "ow", etc. any subtype to lower 732 case. This required the adoption of RFC 7405 syntax in the ABNF. 734 o Added a reserved "example" subtype to be used in examples. 736 o Clarified global applicability, particularly in cases with local 737 or manual assignment mechanisms. 739 o Corrected byte/bit counts in for 1-Wire identifiers in 740 Section 4.2. 742 o Clarified that optional underscore-separated components come at 743 the end of the DEV URN, not just "after the hexstring". 745 o Changed the requirement to not use percent-encoding to a 746 preference instead of a hard rule, based on the needs of SenML but 747 not wishing to break rules of RFC 8141. 749 o Added a description of tradeoffs involving using URNs instead of 750 some more compact but more specific formats, in Section 1. 752 o Several minor corrections to the names in the ABNF. 754 o Added a reference for Base64 for clarity. 756 o Made the history of the OS and OPS subtypes a part of the 757 permanent text, rather than an editor's note. 759 o Updated the 1-Wire reference URL. 761 o Some editorial corrections. 763 Version -09 of the WG draft took into account IANA, SECDIR, Gen-ART, 764 and OPSDIR reviews. The following changes were made: 766 o Aligned the use of identifiers vs. identity terms. 768 o Added a security considerations subsection on validity of claimed 769 identifiers. 771 o Focused on "care" in the RFC 7721 reference, rather than "care and 772 avoidance". 774 o Renamed the "unreserved" ABNF terminal to avoid confusion with the 775 general URN ABNF terminal with the same name. 777 o Removed the mistakenly included text about MEID subtype. 779 o Clarified URN syntax differences and normalization rules wrt the 780 lack of percent-encoding in DEV URNs. 782 o Required PEN numbers to start with non-zero digit in the ABNF and 783 changed the associated language later in the draft. 785 o Text about case-insensitivity in RFC 5234 was clarified. 787 o Text about uniqueness was clarified. 789 o Text about global scope was clarified. 791 o An example of DEV URN usage in SenML was added. 793 o Editorial changes. 795 Version -08 of the WG draft took into account Barry Leiba's AD review 796 comments. To address these comments, changes were made in 797 o Further updates of the upper/lower case rules for the DEV URNs. 799 o Further updates to the ABNF. 801 o The use of HEXDIG from RFC 5234. 803 o IANA considerations for the creation of separate registry for the 804 own parameters of DEV URNs. 806 o Editorial improvements. 808 Version -07 of the WG draft took into account Carsten Bormann's 809 feedback, primarily on character case issues and editorials. 811 Version -06 of the WG draft took into account Marco Tiloca's feedback 812 before a second WGLC, primarily on further cleanup of references and 813 editorial issues. 815 Version -05 of the WG draft made some updates based on WGLC input: 816 examples for MAC-48 and EUI-48, clarification with regards to leading 817 zeroes, new recommendation with the use of lower-case letters to 818 avoid comparison problems, small update of the RFC 8141 template 819 usage, reference updates, and editorial corrections. 821 Version -04 of the WG draft cleaned up the ABNF: 823 o Parts of the ANBF now allow for use cases for the component part 824 that were not previously covered: the syntax now allows the 825 character "." to appear, and serial numbers can have dashes in 826 them. 828 o The syntax was also extended to allow for extensibility by adding 829 additional ":" separated parts for the org, op, ops, and other 830 subtypes. 832 o The ABNF was changed to include directly the ALPHA and DIGIT parts 833 imported from RFC 5234, instead of just having a verbal comment 834 about it. (Note that the style in existing RFCs differs on this.) 836 In addition, in -04 the MAC example was corrected to use the inserted 837 value ffff instead of fffe, required by Section 4.1, the org example 838 was corrected, the os: examples and otherbody examples were added. 839 The IANA rules for allocating new subtypes was slightly relaxed in 840 order to cover for new subtype cases that are brought up regularly, 841 and often not from inside the IETF. Finally, the allocation of PEN 842 numbers and the use of product classes and serial numbers was better 843 explained. 845 Version -03 of the WG draft removed some unnecessary references, 846 updated some other references, removed pct-encoding to ensure the DEV 847 URNs fit [RFC8428] Section 4.5.1 rules, and clarified that the 848 original source of the "os" and "ops" subtypes. 850 Version -02 of the WG draft folded in the "ops" and "os" branches of 851 the dev:urn syntax from LwM2M, as they seemed to match well what 852 already existed in this document under the "org" branch. However, as 853 a part of this three changes were incorporated: 855 o The syntax for the "org:" changes to use "-" rather than ":" 856 between the OUI and the rest of the URN. 858 o The organizations for the "ops" and "os" branches have been 859 changed to use PEN numbers rather than OUI numbers [OUI]. The 860 reason for this is that PEN numbers are allocated through a 861 simpler and less costly process. However, this is a significant 862 change to how LwM2M identifiers were specified before. 864 o There were also changes to what general characters can be used in 865 the otherbody branch of the ABNF. 867 The rationale for all these changes is that it would be helpful for 868 the community collect and unify syntax between the different uses of 869 DEV URNs. If there is significant use of either the org:, os:, or 870 ops: subtypes, then changes at this point may not be warranted, but 871 otherwise unified syntax, as well as the use of PEN numbers would 872 probably be beneficial. Comments on this topic are appreciated. 874 Version -01 of the WG draft converted the draft to use the new URN 875 registration template from [RFC8141]. 877 Version -00 of the WG draft renamed the file name and fixed the ABNF 878 to correctly use "org:" rather than "dn:". 880 Version -05 made a change to the delimiter for parameters within a 881 DEV URN. Given discussions on allowed character sets in SenML 882 [RFC8428], we would like to suggest that the "_" character be used 883 instead of ";", to avoid the need to translate DEV URNs in SenML- 884 formatted communications or files. However, this reverses the 885 earlier decision to not use unreserved characters. This also means 886 that device IDs cannot use "_" characters, and have to employ other 887 characters instead. Feedback on this decision is sought. 889 Version -05 also introduced local or organization-specific device 890 identifiers. Organizations are identified by their PEN number 891 (although we considered FQDNs as a potential alternative. The 892 authors belive an organization-specific device identifier type will 893 make experiments and local use easier, but feedback on this point and 894 the choice of PEN numbers vs. other possible organization identifiers 895 would be very welcome. 897 Version -05 also added some discussion of privacy concerns around 898 long-term stable identifiers. 900 Finally, version -05 clarified the situations when new allocations 901 within the registry of possible device identifier subtypes is 902 appropriate. 904 Version -04 is a refresh, as the need and interest for this 905 specification has re-emerged. And the editing author has emerged 906 back to actual engineering from the depths of IETF administration. 908 Version -02 introduced several changes. The biggest change is that 909 with the NI URNs [RFC6920], it was no longer necessary to define 910 cryptographic identifiers in this specification. Another change was 911 that we incorporated a more generic syntax for future extensions; 912 non-hexstring identifiers can now also be supported, if some future 913 device identifiers for some reason would, for instance, use some kind 914 of encoding such as Base64 [RFC4648]. As a part of this change, we 915 also changed the component part separator character from '-' to ';' 916 so that the general format of the rest of the URN can employ the 917 unreserved characters [RFC3986]. 919 Version -03 made several minor corrections to the ABNF as well as 920 some editorial corrections. 922 Appendix B. Acknowledgments 924 The authors would like to thank Ari Keranen, Stephen Farrell, 925 Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, 926 Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim 927 Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba, 928 Amanda Baber, Juha Hakala, Dale Worley, Brian Weis, John Klensin, 929 Dave Thaler, Russ Housley, Dan Romascanu, and Ahmad Muhanna for 930 feedback and interesting discussions in this problem space. We would 931 also like to note prior documents that focused on specific device 932 identifiers, such as [RFC7254] or [RFC8464]. 934 Authors' Addresses 935 Jari Arkko 936 Ericsson 937 Jorvas 02420 938 Finland 940 Email: jari.arkko@piuha.net 942 Cullen Jennings 943 Cisco 944 170 West Tasman Drive 945 San Jose, CA 95134 946 USA 948 Phone: +1 408 421-9990 949 Email: fluffy@cisco.com 951 Zach Shelby 952 ARM 953 Kidekuja 2 954 Vuokatti 88600 955 FINLAND 957 Phone: +358407796297 958 Email: Zach.Shelby@arm.com