Network Working Group H. Flanagan, Ed. Internet-Draft S. Crocker Intended status: Standards Track Edgemoor Research Institute Expires: 6 January 2023 5 July 2022 Registration Data Dictionary draft-ietf-regext-datadictionary-02 Abstract Multiple applications related to the registration of names and other identifiers are built around a list of data elements. There is currently no unified public list of these data elements, nor is there an organized and independent change control process. This document codifies the multiple similar but not quite identical lists of data elements into a neutral Data Dictionary to be maintained as an independent IANA Registry. The Data Dictionary defines data elements but does not specify which ones are to be used in any particular application; the Data Dictionary is policy-neutral. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 January 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Flanagan & Crocker Expires 6 January 2023 [Page 1] Internet-Draft Registration Data Dictionary July 2022 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Data Element Specification . . . . . . . . . . . . . . . . . 4 2.1. Element name: Domain Name . . . . . . . . . . . . . . . . 4 2.2. Element name: Registry . . . . . . . . . . . . . . . . . 4 2.3. Element name: NS . . . . . . . . . . . . . . . . . . . . 4 2.4. Element name: Registration Creation Date . . . . . . . . 5 2.5. Element name: Registration Expiration Date . . . . . . . 5 2.6. Element name: Registration Updated Date . . . . . . . . . 5 2.7. Element name: Registration Transfer Date . . . . . . . . 5 2.8. Element name: Protection . . . . . . . . . . . . . . . . 5 2.9. Element name: Nexus . . . . . . . . . . . . . . . . . . . 5 2.10. Element name: Person . . . . . . . . . . . . . . . . . . 5 2.11. Element name: Personal . . . . . . . . . . . . . . . . . 5 2.12. Element name: Status & Locks . . . . . . . . . . . . . . 5 2.13. Element name: Source & Method . . . . . . . . . . . . . . 5 2.14. Element name: Payment History . . . . . . . . . . . . . . 6 2.15. Element name: Transaction History . . . . . . . . . . . . 6 2.16. Element name: User Account ID . . . . . . . . . . . . . . 6 2.17. Element name: Reserved . . . . . . . . . . . . . . . . . 6 2.18. Element name: Name . . . . . . . . . . . . . . . . . . . 6 2.19. Element name: Org . . . . . . . . . . . . . . . . . . . . 6 2.20. Element name: Street . . . . . . . . . . . . . . . . . . 6 2.21. Element name: City . . . . . . . . . . . . . . . . . . . 6 2.22. Element name: State/Province . . . . . . . . . . . . . . 6 2.23. Element name: Postal code . . . . . . . . . . . . . . . . 6 2.24. Element name: Country . . . . . . . . . . . . . . . . . . 6 2.25. Element name: Phone . . . . . . . . . . . . . . . . . . . 7 2.26. Element name: Phone ext . . . . . . . . . . . . . . . . . 7 2.27. Element name: Fax . . . . . . . . . . . . . . . . . . . . 7 2.28. Element name: Fax ext . . . . . . . . . . . . . . . . . . 7 2.29. Element name: Email . . . . . . . . . . . . . . . . . . . 7 2.30. Element name: Email_or_phone . . . . . . . . . . . . . . 7 2.31. Element name: Registry UniqueID . . . . . . . . . . . . . 7 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 3.1. Report Specification . . . . . . . . . . . . . . . . . . 7 3.1.1. Designated Expert Evaluation Criteria . . . . . . . . 8 3.1.2. Registration Procedure . . . . . . . . . . . . . . . 9 3.2. Initial assignments . . . . . . . . . . . . . . . . . . . 10 3.2.1. Data Element Definition in IANA Registry . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 Flanagan & Crocker Expires 6 January 2023 [Page 2] Internet-Draft Registration Data Dictionary July 2022 6. Internationalization Considerations . . . . . . . . . . . . . 12 7. Draft Change Log . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Normative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction The Registration Data Dictionary provides a common set of names and definitions for data elements which may be used in any registration protocol, including the DNS. The dictionary is intended to be inclusive and not obligatory. That is, the existence of a data element in this dictionary does not imply the data element must be used or recognized in any particular protocol. The items in this dictionary should represent the union for what is in existing relevant protocols, and should prevent divergence in new protocols. We also expect that each application or protocol may have additional requirements specific to the application or protocol. Such additional requirements should be documented as part of the application or protocol specification. The data dictionary currently has thirty-one data elements. These data elements include the metadata regarding the registration, the detailed status of a registration, details for each of the contacts, and the account details and payment history. The proposed IANA registry lists standard data elements and is each element will be versioned in the registry. We expect the Registration Data Dictionary to evolve to meet the needs of various applications. With the exception of correction of errors, we expect the changes to the Registration Data Dictionary to be additions as opposed to deletions or changes. [Comment: We are looking for additional authors and contributors to add to and improve the data dictionary, keeping in line with the RFC Series Editor statement on authorship. https://www.rfc- editor.org/pipermail/rfc-interest/2015-May/008869.html] 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Flanagan & Crocker Expires 6 January 2023 [Page 3] Internet-Draft Registration Data Dictionary July 2022 2. Data Element Specification Each data element is a single unit of information that can be collected and compared during the registration process. The primary purposes of the IANA registry of data elements are to ensure that each data element is assigned a unique name and that the syntax of each data element is specified. Each data element is assigned to an element type to organize the taxonomy of the data dictionary. The name of the data element MUST be unique and this characteristic MUST be enforced by the registry. The character encoding recommendation for data elements is specified in Section 3. The subsections below comprise an initial list of known data elements commonly being used in the templates. The title of the subsection is the data element name for the data element. The combination of data element type and data element name MUST be unique and MUST be processed as case insensitive in the IANA registry. Note that the legal definition of any of the terms used in the data dictionary, such as 'personally identifiable information' or 'legal person', are to be determined locally. The organization using this dictionary will record their interpretation in the appropriate element. 2.1. Element name: Domain Name This is the name of the object being registered, e.g., the domain name.[RFC5890] See also " name" in [RFC8499]. 2.2. Element name: Registry The name of the registry. See also "Registry" in [RFC8499]. 2.3. Element name: NS The authoritative name server for the registration.[RFC1034] See also "Authoritative server" in [RFC8499] Flanagan & Crocker Expires 6 January 2023 [Page 4] Internet-Draft Registration Data Dictionary July 2022 2.4. Element name: Registration Creation Date The the date and time of the object's creation. 2.5. Element name: Registration Expiration Date The date and time identifying the end of the registration period. 2.6. Element name: Registration Updated Date The date and time of the most recent modification of the registration data. 2.7. Element name: Registration Transfer Date The date and time of the most recent successful registration transfer. 2.8. Element name: Protection Definition is TBD. 2.9. Element name: Nexus Definition is TBD. 2.10. Element name: Person Definition is TBD. 2.11. Element name: Personal Definition is TBD. 2.12. Element name: Status & Locks Examples include the EPP (Section 2.3 of [RFC5731]) and RDAP (Section 10.2.2 of [RFC9083]) codes (ex: clientTransferProhibited) that describe the current state of a registered object and the protocol actions that can (or cannot) be performed on the registered object. A registered object MAY be associated with multiple status values. Other managed objects, including name server and contact objects, can also have status and lock values. 2.13. Element name: Source & Method Definition is TBD. Flanagan & Crocker Expires 6 January 2023 [Page 5] Internet-Draft Registration Data Dictionary July 2022 2.14. Element name: Payment History Definition is TBD. 2.15. Element name: Transaction History Definition is TBD. 2.16. Element name: User Account ID Definition is TBD. 2.17. Element name: Reserved [this field is an artifact of prior use which was determined to not be necessary, but the field was left intact for future use] 2.18. Element name: Name Individual name is represented using character strings. 2.19. Element name: Org Organization name is represented using character strings. 2.20. Element name: Street Postal street address. 2.21. Element name: City Postal city address. 2.22. Element name: State/Province Postal state or province address. 2.23. Element name: Postal code Postal code. 2.24. Element name: Country Country code identifier. Flanagan & Crocker Expires 6 January 2023 [Page 6] Internet-Draft Registration Data Dictionary July 2022 2.25. Element name: Phone Telephone number. 2.26. Element name: Phone ext This field is intended to represent an "extension" within the phone number to reach the specific person or role desk telephone, appropriate queue or mailbox after successfully dialing the Phone element. 2.27. Element name: Fax Fax telephone number. 2.28. Element name: Fax ext This field is an "extension" within a phone tree or PBX that is necessary to connect to a fax machine after successfully dialing the fax element. 2.29. Element name: Email Email address. 2.30. Element name: Email_or_phone There is a requirement that either the phone or email element have been confirmed reachable, which this field is intended to represent. 2.31. Element name: Registry UniqueID This field represents server-unique identifiers assigned to entities, such as clients and contacts. 3. IANA Considerations This section describes the format of the IANA Registration Report Registry, which has two tables described below, and the procedures used to populate and manage the registry entries. 3.1. Report Specification This registry uses the "Specification Required" policy described in [RFC8126]. An English language version of the extension specification is required in the registry, though non-English versions of the specification may also be provided. Flanagan & Crocker Expires 6 January 2023 [Page 7] Internet-Draft Registration Data Dictionary July 2022 The "Specification Required" policy implies review by a "designated expert". Section 5.2 of RFC 8126 describes the role of designated experts and the function they perform. 3.1.1. Designated Expert Evaluation Criteria A high-level description of the role of the designated expert is described in Section 5.2 of RFC 8126. Specific guidelines for the appointment of designated experts and the evaluation of a new data element is provided here. The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5) to serve as designated experts, as described in Section 5.2 of RFC 8126. The pool should have a single administrative chair who is appointed by the IESG. The designated experts should use the existing regext mailing list (regext@ietf.org) for public discussion of registration requests. This implies that the mailing list should remain open after the work of the REGEXT working group has concluded. The results of the evaluation should be shared via email with the registrant and the regext mailing list. Issues discovered during the evaluation can be corrected by the registrant, and those corrections can be submitted to the designated experts until the designated experts explicitly decide to accept or reject the registration request. The designated experts must make an explicit decision and that decision must be shared via email with the registrant and the regext mailing list. If the specification for a data element or report is an IETF Standards Track document, no review is required by the designated expert. Designated experts should be permissive in their evaluation of requests for data elements and reports that have been implemented and deployed by at least one registry. This implies that it may indeed be possible to register multiple data elements or reports that provide the same functionality. Requests to register data elements or reports that have not been deployed should be evaluated with a goal of reducing duplication. A potential registrant who submits a request to register a new data element or report that includes similar functionality to existing data elements or reports should be made aware of the existing data elements and reports. The registrant should be asked to reconsider their request given the existence of similar data elements or reports. Should they decline to do so, perceived similarity should not be a sufficient reason for rejection as long as all other requirements are met. Flanagan & Crocker Expires 6 January 2023 [Page 8] Internet-Draft Registration Data Dictionary July 2022 3.1.2. Registration Procedure The registry contains information describing each registered data element or report. Registry entries are created and managed by sending forms to IANA that describe the data element or report for the registry entry. 3.1.2.1. Required Information The required information must be formatted consistently using the following registration form. Form field names and values may appear on the same line. 3.1.2.1.1. Data Element Definition Name of data element type MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive Name of data element MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive Reference document MUST define the data element, SHOULD be a URL to a RFC, and SHOULD include the section number (or other detailed internal document reference), MAY be a URL to any document available under equivalent terms Registrant Will be IESG for initial entries and all Standards Track specifications; otherwise as specified by the registran Status MUST be one of active, inactive, or unknown Flanagan & Crocker Expires 6 January 2023 [Page 9] Internet-Draft Registration Data Dictionary July 2022 3.1.2.2. Registration Processing Registrants should send each registration form to IANA with a single record for incorporation into the registry. Send the form via email to iana@iana.org or complete the online form found on the IANA web site. The subject line should indicate whether the enclosed form represents an insertion of a new record (indicated by the word "INSERT" in the subject line) or a replacement of an existing record (indicated by the word "MODIFY" in the subject line). At no time can a record be deleted from the registry. On receipt of the registration request, IANA will initiate review by the designated expert(s) if appropriate, who will evaluate the request using the criteria in Section 3.1.1 in consultation with the regext mailing list. 3.1.2.3. Updating Report Definition Registry Entries When submitting changes to existing registry entries, include text in the "Notes" field of the registration form describing the change. Under normal circumstances, registry entries are only to be updated by the registrant. If the registrant becomes unavailable or otherwise unresponsive, the designated expert can submit a registration form to IANA to update the registrant information. Entries can change state from "Active" to "Inactive" and back again as long as state-change requests conform to the processing requirements identified in this document. In addition to entries that become "Inactive" due to a lack of implementation, entries for which a specification becomes consistently unavailable over time should be marked "Inactive" by the designated expert until the specification again becomes reliably available. 3.2. Initial assignments 3.2.1. Data Element Definition in IANA Registry --- BEGIN FORM --- Name of data element: Name Reference: This RFC Section 2.1. Registrant: IESG, iesg@ietf.org Flanagan & Crocker Expires 6 January 2023 [Page 10] Internet-Draft Registration Data Dictionary July 2022 Status: Active --- END FORM --- --- BEGIN FORM --- Name of data element: ............ Reference: This RFC Section $2.n Registrant: IESG, iesg@ietf.org Status: Active --- END FORM --- 4. Security Considerations This specification does not consider the issues of distribution or access to the reports that are created and thus does not introduce any new security oncerns that are not already present in the local environment in which the report is created. A security principle to keep in mind as new reports are developed is that it is considered a bad practice to report or disclose security information. In the case of the registration system upon which this reporting mechanism is based, the authInfo code is a specific example of a data element that SHOULD NOT be included in a report. 5. Privacy Considerations This specification defines a mechanism for policy comparison based on data in a registration system. Some of that data is likely to be considered personally identifiable information (PII) and thus would be subject to privacy protection according to an applicable privacy regulation. It is outside the scope of this specification to address those specific concerns. Implementors are urged to consider these issues with their local legal authority and develop appropriate Flanagan & Crocker Expires 6 January 2023 [Page 11] Internet-Draft Registration Data Dictionary July 2022 requirements for their work. 6. Internationalization Considerations The character encoding for the file contents MUST use UTF-8. Throughout this document A-LABEL is indicated as a SHOULD and that MUST be interpreted as follows. All name labels MUST be in A-LABEL format if it is possible to represent it as an A-LABEL, otherwise U-LABEL MAY be used. 7. Draft Change Log -02: Removed all format syntax guidance. -02: Removed specific references to domain names and DNS where possible. -02: Revised the Introduction. -01: Updated abstract to clarify that this draft does not intend to set policy. -01: Updated definitions in 2.1, 2.4, 2.5, 2.6, 2.7 to remove normative reference to the EPP spec. -01: Updated 2. Data Element specification to note local interpretation expected for any legal definitions. -01: Added TBD to policy-related items, all data-related elements wrt format. -01: Moved several items from informative to normative references. 8. Acknowledgements With many thanks to James Galvin and Rod Rasmussen for their advice and feedback on this data dictionary. 9. References 9.1. Informative References [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . Flanagan & Crocker Expires 6 January 2023 [Page 12] Internet-Draft Registration Data Dictionary July 2022 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, . 9.2. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Authors' Addresses Heather Flanagan (editor) Edgemoor Research Institute Email: hlf@sphericalcowconsulting.com Steve Crocker Edgemoor Research Institute Email: steve@shinkuro.com Flanagan & Crocker Expires 6 January 2023 [Page 13]