--- 1/draft-ietf-regext-dnrd-objects-mapping-07.txt 2020-06-03 07:13:22.087196478 -0700 +++ 2/draft-ietf-regext-dnrd-objects-mapping-08.txt 2020-06-03 07:13:22.403204522 -0700 @@ -1,20 +1,20 @@ Network Working Group G. Lozano Internet-Draft ICANN Intended status: Standards Track J. Gould -Expires: October 30, 2020 C. Thippeswamy +Expires: December 5, 2020 C. Thippeswamy VeriSign - Apr 28, 2020 + Jun 3, 2020 Domain Name Registration Data (DNRD) Objects Mapping - draft-ietf-regext-dnrd-objects-mapping-07 + draft-ietf-regext-dnrd-objects-mapping-08 Abstract This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -23,21 +23,21 @@ 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 October 30, 2020. + This Internet-Draft will expire on December 5, 2020. Copyright Notice Copyright (c) 2020 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 @@ -46,24 +46,24 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in This Document . . . . . . . . . . . . . . 6 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 - 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 6 + 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 7 4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 7 4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 7 4.6. Conventions applicable to the CSV Model . . . . . . . . . 7 5. Object Description . . . . . . . . . . . . . . . . . . . . . 15 5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 15 5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 34 5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 44 5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 62 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 70 @@ -93,70 +93,73 @@ 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 128 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 128 9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 130 10. Internationalization Considerations . . . . . . . . . . . . . 130 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 138 12.1. Implementation in the gTLD space . . . . . . . . . . . . 139 13. Security Considerations . . . . . . . . . . . . . . . . . . . 139 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 140 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 140 - 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 140 + 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 141 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 141 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 141 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 141 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 142 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 142 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 143 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 144 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 144 - 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 144 + 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 145 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 145 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 145 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 145 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 145 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 145 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 147 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 147 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 148 16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 148 16.19. Changes REGEXT 06 to REGEXT 07 . . . . . . . . . . . . . 148 - 17. Example of a Full Deposit using the XML model . . . . . . . . 148 + 16.20. Changes REGEXT 07 to REGEXT 08 . . . . . . . . . . . . . 148 + 17. Example of a Full Deposit using the XML model . . . . . . . . 149 18. Example of Differential Deposit using the XML model . . . . . 154 - 19. Example of a Full Deposit using the CSV model . . . . . . . . 155 - 20. Example of Differential Deposit using the CSV model . . . . . 164 + 19. Example of a Full Deposit using the CSV model . . . . . . . . 156 + 20. Example of Differential Deposit using the CSV model . . . . . 165 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 175 21.1. Normative References . . . . . . . . . . . . . . . . . . 175 21.2. Informative References . . . . . . . . . . . . . . . . . 177 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178 1. Introduction Registry Data Escrow is the process by which a registry periodically submits data deposits to a third-party called an escrow agent. These deposits comprise the minimum data needed by a third-party to resume operations if the registry cannot function and is unable or unwilling to facilitate an orderly transfer of service. For example, for a domain name registry or registrar, the data to be deposited would include all the objects related to registered domain names, e.g., names, contacts, name servers, etc. The goal of data escrow is higher resiliency of registration services, for the benefit of Internet users. The beneficiaries of a - registry are not just those registering information there, but all - relying parties that need to identify the owners of objects. + registry are not just those registering information there, but also + the users of services relying on the registry data. In the context of domain name registries, registration data escrow is - a requirement for generic top-level domains and some country code - top-level domain managers are also currently escrowing data. There - is also a similar requirement for ICANN-accredited domain registrars. + a requirement for generic top-level domains (e.g., Specification 2 of + the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and + some country code top-level domain managers are also currently + escrowing data. There is also a similar requirement for ICANN- + accredited domain registrars. This document defines the standard set of objects for a Domain Name Registry that uses the Registry Data Escrow Specification described in [I-D.ietf-regext-data-escrow] for escrow. The set of objects include: o Domain: Internet domain names that are typically provisioned in a Domain Name Registry using the EPP domain name mapping [RFC5731]. The attributes defined in the EPP domain name mapping [RFC5731] are fully supported by this document. @@ -189,20 +192,25 @@ o EPP parameters: Definition of the specific EPP parameters supported by the Registry Operator. o Header: Used to specify counters of objects in the database at a certain point in time (watermark). o Policy: Used to specify OPTIONAL elements from this specification that are REQUIRED based on the business model of the registry. + Extensible Markup Language (XML) 1.0 as described in + [W3C.REC-xml-20081126] and XML Schema notation as described in + [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are + used in this specification. + 2. Models This document defines two different models that can be used to deposit data escrow objects: XML and CSV. The data escrow deposit MAY contain a mix of both models but an object MUST be escrowed only in one model. This document does not suggest the use of a particular model, and both are equivalent. A Domain Name Registry may choose the model @@ -6285,25 +6293,27 @@ agreements-en 13. Security Considerations This specification does not define the security mechanisms to be used in the transmission of the data escrow deposits, since it only specifies the minimum necessary to enable the rebuilding of a registry from deposits without intervention from the original registry. - Depending on local policies, some elements or, most likely, the whole - deposit will be considered confidential. As such, the registry - transmitting the data to the escrow agent SHOULD take all the - necessary precautions such as encrypting the data itself and/or the - transport channel to avoid inadvertent disclosure of private data. + Depending on local policies, some elements, or, most likely, the + whole deposit will be considered confidential. As such, the parties + SHOULD take all the necessary precautions such as encrypting the data + at rest and in transit to avoid inadvertent disclosure of private + data. Regardless of the precautions taken by the parties regarding + data at rest and in transit, authentication credentials MUST NOT be + escrowed. Authentication of the parties passing data escrow deposit files is also of the utmost importance. The escrow agent MUST properly authenticate the identity of the registry before accepting data escrow deposits. In a similar manner, the registry MUST authenticate the identity of the escrow agent before submitting any data. Additionally, the registry and the escrow agent MUST use integrity checking mechanisms to ensure the data transmitted is what the source intended. Validation of the contents by the escrow agent is @@ -6701,20 +6711,30 @@ 16.19. Changes REGEXT 06 to REGEXT 07 1. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/hDLz2ym4oR-ukA4Fm- QJ8FzaxxE 2. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/780Xw- z1RMRb79nmZ6ABmRTo1fU +16.20. Changes REGEXT 07 to REGEXT 08 + + 1. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + UaMNvl1xh60ldjpqHHYc3TNsfhg + + 2. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + B3QTxUCWUE4R_QharAQlA3041j0 + 17. Example of a Full Deposit using the XML model Example of a Full Deposit using the XML model: 21. References 21.1. Normative References [I-D.ietf-regext-data-escrow] Lozano, G., "Registry Data Escrow Specification", draft- - ietf-regext-data-escrow-08 (work in progress), April 2020. + ietf-regext-data-escrow-10 (work in progress), June 2020. [ISO-3166-1] 3166, I. S., "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166, November 2006. [ITU-E164] International Telecommunication Union, "The international public telecommunication numbering plan", ITU-T Recommendation E.164, February 2005. @@ -8083,20 +8102,25 @@ xmlschema-1-20041028", October 2004, . [W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028", October 2004, . 21.2. Informative References + [ICANN-GTLD-RA-20170731] + ICANN, "Base Registry Agreement 2017-07-31", July 2017, + . + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer