idnits 2.17.1 draft-ietf-regext-datadictionary-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO19160-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.E164.2005' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Flanagan, Ed. 3 Internet-Draft S. Crocker 4 Intended status: Standards Track Edgemoor Research Institute 5 Expires: 8 September 2022 7 March 2022 7 Registration Data Dictionary 8 draft-ietf-regext-datadictionary-01 10 Abstract 12 Multiple applications related to the registration of names and other 13 identifiers are built around a list of data elements. There is 14 currently no unified public list of these data elements, nor is there 15 an organized and independent change control process. This document 16 codifies the multiple similar but not quite identical lists of data 17 elements into a neutral Data Dictionary to be maintained as an 18 independent IANA Registry. The Data Dictionary defines data elements 19 but does not specify which ones are to be used in any particular 20 application; the Data Dictionary is policy-neutral. 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 https://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 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 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 (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Data Element Specification . . . . . . . . . . . . . . . . . 4 58 2.1. Element name: Domain Name . . . . . . . . . . . . . . . . 4 59 2.2. Element name: Registry . . . . . . . . . . . . . . . . . 4 60 2.3. Element name: NS . . . . . . . . . . . . . . . . . . . . 4 61 2.4. Element name: Registration Creation Date . . . . . . . . 5 62 2.5. Element name: Registration Expiration Date . . . . . . . 5 63 2.6. Element name: Registration Updated Date . . . . . . . . . 5 64 2.7. Element name: Registration Transfer Date . . . . . . . . 5 65 2.8. Element name: Protection . . . . . . . . . . . . . . . . 5 66 2.9. Element name: Nexus . . . . . . . . . . . . . . . . . . . 5 67 2.10. Element name: Person . . . . . . . . . . . . . . . . . . 5 68 2.11. Element name: Personal . . . . . . . . . . . . . . . . . 5 69 2.12. Element name: Status & Locks . . . . . . . . . . . . . . 5 70 2.13. Element name: Source & Method . . . . . . . . . . . . . . 6 71 2.14. Element name: Payment History . . . . . . . . . . . . . . 6 72 2.15. Element name: Transaction History . . . . . . . . . . . . 6 73 2.16. Element name: User Account ID . . . . . . . . . . . . . . 6 74 2.17. Element name: Reserved . . . . . . . . . . . . . . . . . 6 75 2.18. Element name: Name . . . . . . . . . . . . . . . . . . . 6 76 2.19. Element name: Org . . . . . . . . . . . . . . . . . . . . 6 77 2.20. Element name: Street . . . . . . . . . . . . . . . . . . 6 78 2.21. Element name: City . . . . . . . . . . . . . . . . . . . 6 79 2.22. Element name: State/Province . . . . . . . . . . . . . . 7 80 2.23. Element name: Postal code . . . . . . . . . . . . . . . . 7 81 2.24. Element name: Country . . . . . . . . . . . . . . . . . . 7 82 2.25. Element name: Phone . . . . . . . . . . . . . . . . . . . 7 83 2.26. Element name: Phone ext . . . . . . . . . . . . . . . . . 7 84 2.27. Element name: Fax . . . . . . . . . . . . . . . . . . . . 7 85 2.28. Element name: Fax ext . . . . . . . . . . . . . . . . . . 7 86 2.29. Element name: Email . . . . . . . . . . . . . . . . . . . 8 87 2.30. Element name: Email_or_phone . . . . . . . . . . . . . . 8 88 2.31. Element name: Registry UniqueID . . . . . . . . . . . . . 8 89 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 90 3.1. Report Specification . . . . . . . . . . . . . . . . . . 8 91 3.1.1. Designated Expert Evaluation Criteria . . . . . . . . 8 92 3.1.2. Registration Procedure . . . . . . . . . . . . . . . 9 93 3.2. Initial assignments . . . . . . . . . . . . . . . . . . . 11 94 3.2.1. Data Element Definition in IANA Registry . . . . . . 11 95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 96 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 97 6. Internationalization Considerations . . . . . . . . . . . . . 12 98 7. Draft Change Log . . . . . . . . . . . . . . . . . . . . . . 12 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 9.1. Informative References . . . . . . . . . . . . . . . . . 13 102 9.2. Normative References . . . . . . . . . . . . . . . . . . 13 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 105 1. Introduction 107 The DNS Data Dictionary provides a common set of names and 108 definitions for data elements which may be used in a DNS related 109 protocol. The dictionary is intended to be inclusive and not 110 obligatory. That is, the existence of a data element in this 111 dictionary does not imply the data element must be used or recognized 112 in any particular protocol. The items in this dictionary should 113 represent the union for what is in existing relevant protocols, and 114 should prevent divergence in new protocols. We also expect that each 115 application or protocol may have additional requirements specific to 116 the application or protocol. Such additional requirements should be 117 documented as part of the application or protocol specification. 119 The data dictionary currently has thirty-one data elements. These 120 data elements include the DNS records, the detailed status of a 121 registration to the details for each of the contacts, and the account 122 details and payment history. The proposed IANA registry lists 123 standard data elements and their syntax for inclusion in the files. 125 We expect the DNS data dictionary to evolve to meet the needs of 126 various applications. With the exception of correction of errors, we 127 expect the changes to the DNS Data Dictionary to be additions as 128 opposed to deletions or changes. 130 [Comment: We are looking for additional authors and contributors to 131 add to and improve the data dictionary, keeping in line with the RFC 132 Series Editor statement on authorship. https://www.rfc- 133 editor.org/pipermail/rfc-interest/2015-May/008869.html] 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Data Element Specification 145 Each data element is a single unit of information that can be 146 collected and compared during the registration process. The primary 147 purposes of the IANA registry of data elements are to ensure that 148 each data element is assigned a unique name and that the syntax of 149 each data element is specified. 151 Each data element is assigned to an element type to organize the 152 taxonomy of the data dictionary. 154 The name of the data element MUST be unique and this characteristic 155 MUST be enforced by the registry. The character encoding 156 recommendation for data elements is specified in Section 3. 158 The subsections below comprise an initial list of known data elements 159 commonly being used in the templates. The title of the subsection is 160 the data element name for the data element. The combination of data 161 element type and data element name MUST be unique and MUST be 162 processed as case insensitive in the IANA registry. 164 Note that the legal definition of any of the terms used in the data 165 dictionary, such as 'personally identifiable information' or 'legal 166 person', are to be determined locally. The organization using this 167 dictionary will record their interpretation in the appropriate 168 element. 170 2.1. Element name: Domain Name 172 This is the domain name as formatted according to the 173 Internationalized Domain Names for Applications (IDNA) 174 specification.[RFC5890] 176 See also "Domain name" in [RFC8499]. 178 2.2. Element name: Registry 180 The name of the registry. This data element is text/string with no 181 naming convention enforced. 183 See also "Registry" in [RFC8499]. 185 2.3. Element name: NS 187 The authoritative name server for the domain.[RFC1034] 189 See also "Authoritative server" in [RFC8499] 191 2.4. Element name: Registration Creation Date 193 The the date and time of domain object creation. Format TBD. 195 2.5. Element name: Registration Expiration Date 197 The date and time identifying the end of the domain object's 198 registration period. Format TBD. 200 2.6. Element name: Registration Updated Date 202 The date and time of the most recent domain-object modification. 203 Format TBD. 205 2.7. Element name: Registration Transfer Date 207 The date and time of the most recent successful domain-object 208 transfer. Format TBD. 210 2.8. Element name: Protection 212 Definition is TBD. 214 2.9. Element name: Nexus 216 Definition is TBD. 218 2.10. Element name: Person 220 Definition is TBD. 222 2.11. Element name: Personal 224 Definition is TBD. 226 2.12. Element name: Status & Locks 228 Examples include the EPP (Section 2.3 of [RFC5731]) and RDAP 229 (Section 10.2.2 of [RFC9083]) codes (ex: clientTransferProhibited) 230 that describe the current state of a registered domain name and the 231 protocol actions that can (or cannot) be performed on the domain 232 name. A registered domain name MAY be associated with multiple 233 status values. Other managed objects, including name server and 234 contact objects, can also have status and lock values. 236 2.13. Element name: Source & Method 238 Definition is TBD. 240 2.14. Element name: Payment History 242 Definition is TBD. 244 2.15. Element name: Transaction History 246 Definition is TBD. 248 2.16. Element name: User Account ID 250 Definition is TBD. 252 2.17. Element name: Reserved 254 [this field is an artifact of prior use which was determined to not 255 be necessary, but the field was left intact for future use] 257 2.18. Element name: Name 259 Individual name is represented using character strings. These 260 strings have a specified minimum length and a specified maximum 261 length. Individual names MAY be provided in either UTF-8 [RFC3629] 262 or a subset of UTF-8 that can be represented in 7-bit ASCII, 263 depending on local needs. 265 2.19. Element name: Org 267 Organization name is represented using character strings. These 268 strings have a specified minimum length and a specified maximum 269 length. Organizational names MAY be provided in either UTF-8 270 [RFC3629] or a subset of UTF-8 that can be represented in 7-bit 271 ASCII, depending on local needs. 273 2.20. Element name: Street 275 Postal street address, formatted as per [ISO19160-4]. 277 2.21. Element name: City 279 Postal city address, formatted as per [ISO19160-4]. 281 2.22. Element name: State/Province 283 Postal state or province address, formatted as per [ISO19160-4]. 285 2.23. Element name: Postal code 287 Postal code, formatted as per [ISO19160-4]. Contact postal codes are 288 represented using character strings. These strings have a specified 289 minimum length and a specified maximum length. 291 2.24. Element name: Country 293 Country code identifier. Contact country identifiers are represented 294 using two-character identifiers specified in [ISO3166-1]. 296 2.25. Element name: Phone 298 Telephone number structure is derived from structures defined in 299 [ITU.E164.2005]. Telephone numbers described in this mapping are 300 character strings that MUST begin with a plus sign ("+", ASCII value 301 0x002B), followed by a country code defined in [ITU.E164.2005], 302 followed by a dot (".", ASCII value 0x002E), followed by a sequence 303 of digits representing the telephone number. An optional "x" 304 attribute is provided to note telephone extension information. 306 2.26. Element name: Phone ext 308 This field is intended to represent an "extension" within the phone 309 number to reach the specific person or role desk telephone, 310 appropriate queue or mailbox after successfully dialing the Phone 311 element. 313 2.27. Element name: Fax 315 Fax telephone number structure is derived from structures defined in 316 [ITU.E164.2005]. Telephone numbers described in this mapping are 317 character strings that MUST begin with a plus sign ("+", ASCII value 318 0x002B), followed by a country code defined in [ITU.E164.2005], 319 followed by a dot (".", ASCII value 0x002E), followed by a sequence 320 of digits representing the telephone number. 322 2.28. Element name: Fax ext 324 This field is an "extension" within a phone tree or PBX that is 325 necessary to connect to a fax machine after successfully dialing the 326 fax element. 328 2.29. Element name: Email 330 Email address syntax is defined in [RFC5322]. 332 2.30. Element name: Email_or_phone 334 There is a requirement that either the phone or email element have 335 been confirmed reachable, which this field is intended to represent. 337 2.31. Element name: Registry UniqueID 339 This field represents server-unique identifiers assigned to entities, 340 such as clients and contacts. These identifiers are character 341 strings that typically have a specified minimum length, a specified 342 maximum length, and a specified format. 344 3. IANA Considerations 346 This section describes the format of the IANA Registration Report 348 Registry, which has two tables described below, and the procedures 350 used to populate and manage the registry entries. 352 3.1. Report Specification 354 This registry uses the "Specification Required" policy described in 355 [RFC8126]. An English language version of the extension 356 specification is required in the registry, though non-English 357 versions of the specification may also be provided. 359 The "Specification Required" policy implies review by a "designated 360 expert". Section 5.2 of RFC 8126 describes the role of designated 361 experts and the function they perform. 363 3.1.1. Designated Expert Evaluation Criteria 365 A high-level description of the role of the designated expert is 366 described in Section 5.2 of RFC 8126. Specific guidelines for the 367 appointment of designated experts and the evaluation of a new data 368 element is provided here. 370 The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5) 371 to serve as designated experts, as described in Section 5.2 of RFC 372 8126. The pool should have a single administrative chair who is 373 appointed by the IESG. The designated experts should use the 374 existing regext mailing list (regext@ietf.org) for public discussion 375 of registration requests. This implies that the mailing list should 376 remain open after the work of the REGEXT working group has concluded. 378 The results of the evaluation should be shared via email with the 379 registrant and the regext mailing list. Issues discovered during the 380 evaluation can be corrected by the registrant, and those corrections 381 can be submitted to the designated experts until the designated 382 experts explicitly decide to accept or reject the registration 383 request. The designated experts must make an explicit decision and 384 that decision must be shared via email with the registrant and the 385 regext mailing list. If the specification for a data element or 386 report is an IETF Standards Track document, no review is required by 387 the designated expert. 389 Designated experts should be permissive in their evaluation of 390 requests for data elements and reports that have been implemented and 391 deployed by at least one registry. This implies that it may indeed 392 be possible to register multiple data elements or reports that 393 provide the same functionality. Requests to register data elements 394 or reports that have not been deployed should be evaluated with a 395 goal of reducing duplication. A potential registrant who submits a 396 request to register a new data element or report that includes 397 similar functionality to existing data elements or reports should be 398 made aware of the existing data elements and reports. The registrant 399 should be asked to reconsider their request given the existence of 400 similar data elements or reports. Should they decline to do so, 401 perceived similarity should not be a sufficient reason for rejection 402 as long as all other requirements are met. 404 3.1.2. Registration Procedure 406 The registry contains information describing each registered data 407 element or report. Registry entries are created and managed by 408 sending forms to IANA that describe the data element or report for 409 the registry entry. 411 3.1.2.1. Required Information 413 The required information must be formatted consistently using the 414 following registration form. Form field names and values may appear 415 on the same line. 417 3.1.2.1.1. Data Element Definition 419 Name of data element type 421 MUST be unique within the registry, enforced to be unique, and MUST 422 be processed as case insensitive 424 Name of data element 426 MUST be unique within the registry, enforced to be unique, and MUST 427 be processed as case insensitive 429 Reference document 431 MUST define the data element, SHOULD be a URL to a RFC, and SHOULD 432 include the section number (or other detailed internal document 433 reference), MAY be a URL to any document available under equivalent 434 terms 436 Registrant 438 Will be IESG for initial entries and all Standards Track 439 specifications; otherwise as specified by the registran 441 Status 443 MUST be one of active, inactive, or unknown 445 3.1.2.2. Registration Processing 447 Registrants should send each registration form to IANA with a single 448 record for incorporation into the registry. Send the form via email 449 to iana@iana.org or complete the online form found on the IANA web 450 site. The subject line should indicate whether the enclosed form 451 represents an insertion of a new record (indicated by the word 452 "INSERT" in the subject line) or a replacement of an existing record 453 (indicated by the word "MODIFY" in the subject line). At no time can 454 a record be deleted from the registry. On receipt of the 455 registration request, IANA will initiate review by the designated 456 expert(s) if appropriate, who will evaluate the request using the 457 criteria in Section 3.1.1 in consultation with the regext mailing 458 list. 460 3.1.2.3. Updating Report Definition Registry Entries 462 When submitting changes to existing registry entries, include text in 463 the "Notes" field of the registration form describing the change. 464 Under normal circumstances, registry entries are only to be updated 465 by the registrant. If the registrant becomes unavailable or 466 otherwise unresponsive, the designated expert can submit a 467 registration form to IANA to update the registrant information. 468 Entries can change state from "Active" to "Inactive" and back again 469 as long as state-change requests conform to the processing 470 requirements identified in this document. In addition to entries 471 that become "Inactive" due to a lack of implementation, entries for 472 which a specification becomes consistently unavailable over time 473 should be marked "Inactive" by the designated expert until the 474 specification again becomes reliably available. 476 3.2. Initial assignments 478 3.2.1. Data Element Definition in IANA Registry 480 --- BEGIN FORM --- 482 Name of data element: 484 Domain Name 486 Reference: 488 This RFC Section 2.1. 490 Registrant: 492 IESG, iesg@ietf.org 494 Status: 496 Active 498 --- END FORM --- 500 --- BEGIN FORM --- 502 Name of data element: 504 ............ 506 Reference: 508 This RFC Section $2.n 510 Registrant: 512 IESG, iesg@ietf.org 514 Status: 516 Active 518 --- END FORM --- 520 4. Security Considerations 522 This specification does not consider the issues of distribution or 523 access to the reports that are created and thus does not introduce 524 any new security oncerns that are not already present in the local 525 environment in which the report is created. 527 A security principle to keep in mind as new reports are developed is 528 that it is considered a bad practice to report or disclose security 529 information. In the case of the registration system upon which this 530 reporting mechanism is based, the authInfo code is a specific example 531 of a data element that SHOULD NOT be included in a report. 533 5. Privacy Considerations 535 This specification defines a mechanism for policy comparison based on 536 data in a registration system. Some of that data is likely to be 537 considered personally identifiable information (PII) and thus would 538 be subject to privacy protection according to an applicable privacy 539 regulation. It is outside the scope of this specification to address 540 those specific concerns. Implementors are urged to consider these 541 issues with their local legal authority and develop appropriate 542 requirements for their work. 544 6. Internationalization Considerations 546 The character encoding for the file contents MUST use UTF-8. 547 Throughout this document A-LABEL is indicated as a SHOULD and that 548 MUST be interpreted as follows. All domain name labels MUST be in 549 A-LABEL format if it is possible to represent it as an A-LABEL, 550 otherwise U-LABEL MAY be used. 552 7. Draft Change Log 554 -01: Updated abstract to clarify that this draft does not intend to 555 set policy. 557 -01: Updated definitions in 2.1, 2.4, 2.5, 2.6, 2.7 to remove 558 normative reference to the EPP spec. 560 -01: Updated 2. Data Element specification to note local 561 interpretation expected for any legal definitions. 563 -01: Added TBD to policy-related items, all data-related elements wrt 564 format. 566 -01: Moved several items from informative to normative references. 568 8. Acknowledgements 570 With many thanks to James Galvin and Rod Rasmussen for their advice 571 and feedback on this data dictionary. 573 9. References 575 9.1. Informative References 577 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 578 Domain Name Mapping", STD 69, RFC 5731, 579 DOI 10.17487/RFC5731, August 2009, 580 . 582 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 583 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 584 January 2019, . 586 [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the 587 Registration Data Access Protocol (RDAP)", STD 95, 588 RFC 9083, DOI 10.17487/RFC9083, June 2021, 589 . 591 9.2. Normative References 593 [ISO19160-4] 594 International Organization for Standardization, 595 "ISO19160-4: Addressing — Part 4: International postal 596 address components and template language", November 2017. 598 [ISO3166-1] 599 International Organization for Standardization, 600 "ISO3166-1: Codes for the representation of names of 601 countries and their subdivisions -- Part1: Country codes", 602 November 2006. 604 [ITU.E164.2005] 605 International Telecommunication Union, "ITU-T 606 Recommendation E.164: The international public 607 telecommunication numbering plan", February 2005. 609 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 610 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 611 . 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 619 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 620 2003, . 622 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 623 DOI 10.17487/RFC5322, October 2008, 624 . 626 [RFC5890] Klensin, J., "Internationalized Domain Names for 627 Applications (IDNA): Definitions and Document Framework", 628 RFC 5890, DOI 10.17487/RFC5890, August 2010, 629 . 631 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 632 Writing an IANA Considerations Section in RFCs", BCP 26, 633 RFC 8126, DOI 10.17487/RFC8126, June 2017, 634 . 636 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 637 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 638 May 2017, . 640 Authors' Addresses 642 Heather Flanagan (editor) 643 Edgemoor Research Institute 644 Email: hlf@sphericalcowconsulting.com 646 Steve Crocker 647 Edgemoor Research Institute 648 Email: steve@shinkuro.com