--- 1/draft-ietf-regext-dnrd-objects-mapping-08.txt 2020-08-12 16:13:24.571087865 -0700 +++ 2/draft-ietf-regext-dnrd-objects-mapping-09.txt 2020-08-12 16:13:24.795090964 -0700 @@ -1,20 +1,20 @@ Network Working Group G. Lozano Internet-Draft ICANN Intended status: Standards Track J. Gould -Expires: December 5, 2020 C. Thippeswamy +Expires: February 13, 2021 C. Thippeswamy VeriSign - Jun 3, 2020 + Aug 12, 2020 Domain Name Registration Data (DNRD) Objects Mapping - draft-ietf-regext-dnrd-objects-mapping-08 + draft-ietf-regext-dnrd-objects-mapping-09 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 December 5, 2020. + This Internet-Draft will expire on February 13, 2021. 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 @@ -47,96 +47,98 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Conventions Used in This Document . . . . . . . . . . . . . . 6 - 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Conventions Used in This Document . . . . . . . . . . . . . . 7 + 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 7 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 - 5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 74 - 5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 79 - 5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 81 - 5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 81 - 5.10. DNRD Common Objects Collection . . . . . . . . . . . . . 84 - 6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 84 - 7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 - 8. Data escrow agent extended verification process . . . . . . . 85 - 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 86 - 9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 87 - 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 96 - 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 98 - 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 102 - 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 104 - 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 106 - 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 108 - 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 114 - 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 117 - 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 120 - 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 121 - 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 123 - 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 124 - 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 126 - 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 . . . . . . . . . . . . . . . . . . . . . . . 141 + 4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 8 + 4.6. Conventions applicable to the CSV Model . . . . . . . . . 8 + 5. Object Description . . . . . . . . . . . . . . . . . . . . . 16 + 5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 16 + 5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 35 + 5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 45 + 5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 63 + 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 71 + 5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 75 + 5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 80 + 5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 82 + 5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 82 + 5.10. DNRD Common Objects Collection . . . . . . . . . . . . . 85 + 6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 85 + 7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 + 8. Data escrow agent extended verification process . . . . . . . 86 + 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 87 + 9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 88 + 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 97 + 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 99 + 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 103 + 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 105 + 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 107 + 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 109 + 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 115 + 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 118 + 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 121 + 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 122 + 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 124 + 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 125 + 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 127 + 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 129 + 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 129 + 9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 131 + 10. Internationalization Considerations . . . . . . . . . . . . . 131 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131 + 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 139 + 12.1. Implementation in the gTLD space . . . . . . . . . . . . 140 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 140 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 141 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 141 + 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 142 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 . . . . . . . . . . . . . . . . . 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 - 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 . . . . . . . . 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 + to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 142 + 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 142 + 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 142 + 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 143 + 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 143 + 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 144 + 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 145 + 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 145 + 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 146 + 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 146 + 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 146 + 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 146 + 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 146 + 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 146 + 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 148 + 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 148 + 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 149 + 16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 149 + 16.19. Changes REGEXT 06 to REGEXT 07 . . . . . . . . . . . . . 149 + 16.20. Changes REGEXT 07 to REGEXT 08 . . . . . . . . . . . . . 149 + 16.21. Changes REGEXT 08 to REGEXT 09 . . . . . . . . . . . . . 150 + 17. Example of a Full Deposit using the XML model . . . . . . . . 150 + 18. Example of Differential Deposit using the XML model . . . . . 155 + 19. Example of a Full Deposit using the CSV model . . . . . . . . 157 + 20. Example of Differential Deposit using the CSV model . . . . . 166 + 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 176 + 21.1. Normative References . . . . . . . . . . . . . . . . . . 177 + 21.2. Informative References . . . . . . . . . . . . . . . . . 179 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 180 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., @@ -171,22 +173,22 @@ o Contact: Individual or organization social information provisioned in a Domain Name Registry using the EPP contact mapping [RFC5733]. The attributes defined in the EPP contact mapping [RFC5733] are fully supported by this document. o Registrar: The organization that sponsors objects like domains, hosts, and contacts in a Domain Name Registry. o NNDN (NNDN's not domain name): Domain Name Registries may maintain - domain names without their being persisted as domain objects in - the registry system, for example, a list of reserved names not + domain names without being persisted as domain objects in the + registry system, for example, a list of reserved names not available for registration. The NNDN is a lightweight domain-like object that is used to escrow domain names not maintained as domain name objects. This document defines the following pseudo-objects: o IDN Table Reference: Internationalized Domain Names (IDN) included in the Domain Object Data Escrow include references to the IDN Table and Policy used in IDN registration. @@ -208,24 +210,24 @@ 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 that is more appropriate for the peculiarities of its systems. For - example, a registry may use the CSV-export functionality of the RDBMS - for escrow; therefore, the CSV model may be more appropriate. - Another registry may use the code developed for EPP to implement - escrow. + example, a registry may use the CSV-export functionality of the + Relational Database Management System (RDBMS) for escrow; therefore, + the CSV model may be more appropriate. Another registry may use the + code developed for EPP to implement escrow. 2.1. XML Model XML: The XML model includes all the deposit information (meta-data and data) in an XML document. The definition of the XML format is fully defined in the XML schemas. As a convention, the objects represented using the XML model are referenced using RDE and an XML namespace that is prefixed with "rde". For example, the Domain Name object represented using the XML model can be referred to as the RDE Domain Name with the XML namespace including rdeDomain @@ -242,47 +244,85 @@ namespace including csvDomain (urn:ietf:params:xml:ns:csvDomain-1.0). 3. Terminology 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. - REGISTRY. In the context of this draft the definition will be - overloaded (from the definition in the base protocol) to indicate an - organization providing Registry Services for a REGISTRY-CLASS DOMAIN - NAME. - - REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) - or any other domain name at any level in the DNS tree for which a - Registry (either directly or through an affiliate company) provides - Registry Services for other organizations or individuals. For - example: .COM, .ORG, .BIZ, .CO.JP, .B.BR. +3.1. Glossary - REGISTRY SERVICES. Services offered by the Registry critical to the - following tasks: the provisioning of domain names on receipt of - requests and data from registrars; responding to registrar queries - for status information relating to the DNS servers for the RCDN; - dissemination of RCDN zone files; operation of the Registry DNS - servers; responding to queries for contact and other information - concerning DNS registrations in the RCDN; and any other products or - services that only a Registry is capable of providing, by reason of - its designation as the Registry. Typical examples of Registry - Services are DNS resolution for the RCDN, WHOIS and EPP. + In the following section, the most common terms are briefly + explained: - ALLOCATED. A status of some label with respect to a zone, whereby + o Allocated: a status of some label with respect to a zone, whereby the label is associated administratively to some entity that has requested the label. This term (and its cognates "allocation" and - "to allocate") may represent the first step on the way to delegation - in the DNS. + "to allocate") may represent the first step on the way to + delegation in the DNS. + + o Comma-Separated Values (CSV), see [RFC4180]. + + o Domain name: see definition of Domain name in [RFC8499]. + + o Extensible Provisioning Protocol (EPP), see definition of the + Extensible Provisioning Protocol in [RFC8499]. + + o Fully-Qualified Domain Name (FQDN), see definition of FQDN in + [RFC8499]. + + o Internationalized Domain Name (IDN), see definition of + Internationalized Domain Name in [RFC8499]. + + o Label: see definition of Label in [RFC8499]. + + o Registrant: see definition of Registrant in [RFC8499]. + + o Registrar: see definition of Registrar in [RFC8499]. + + o Registry: see definition of Registry in [RFC8499]. + + o Registry-class domain name (RCDN): refers to a top-level domain + (TLD) or any other domain name at any level in the DNS tree for + which a Registry (either directly or through an affiliate company) + provides Registry Services for other organizations or individuals. + For example: .COM, .ORG, .BIZ, .CO.JP, .B.BR. + + o Registry Data Escrow (RDE): 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. + + o Registry services: services offered by the Registry critical to + the following tasks: the provisioning of domain names on receipt + of requests and data from registrars; responding to registrar + queries for status information relating to the DNS servers for the + RCDN; dissemination of RCDN zone files; operation of the Registry + DNS servers; responding to queries for contact and other + information concerning DNS registrations in the RCDN; and any + other products or services that only a Registry is capable of + providing, by reason of its designation as the Registry. Typical + examples of Registry Services are DNS resolution for the RCDN, + WHOIS and EPP. + + o SRS: Shared Registration System, see also + [ICANN-GTLD-AGB-20120604]. + + o Top-Level Domain Name (TLD), see definition of Top-Level Domain in + [RFC8499]. + + o UTC: Coordinated Universal Time, as maintained by the Bureau + International des Poids et Mesures (BIPM); see also [RFC3339]. 4. Conventions Used in This Document 4.1. Date and Time Numerous fields indicate "dates", such as the creation and expiry dates for domain names. These fields SHALL contain timestamps indicating the date and time in UTC as specified in [RFC3339], with no offset from the zero meridian. @@ -290,28 +330,32 @@ Country identifiers SHALL be represented using two character identifiers as specified in [ISO-3166-1]. 4.3. Telephone numbers Telephone numbers (both voice and facsimile) SHALL be formatted based on structures defined in [ITU-E164]. Telephone numbers described in this specification are character strings that MUST begin with a plus sign ("+", ASCII value 0x002B), followed by a country code defined in + [ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by a sequence of digits representing the telephone number. 4.4. Checksum - The checksum of the CSV data escrow files MUST use CRC32, which is - the algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 - of ITU-T recommendation V.42. + A checksum MAY be used to verify the integrity of the CSV files, for + example, if another layer (i.e., encryption of an archive containing + the deposit files) does not provide integrity. By default the CRC32 + algorithm (see, 8.1.1.6.2 of [V42]) is used. A stronger algorithm, + such as SHA-256 (see, [RFC6234]) MAY be specified for enhanced + security if required. 4.5. IP addresses The syntax of IP addresses MUST conform to the text representation of either Internet Protocol Version 4 [RFC0791] or Internet Protocol Version 6 [RFC4291]. 4.6. Conventions applicable to the CSV Model 4.6.1. CSV Parent Child Relationship @@ -412,28 +456,38 @@ name="domainStatuses"> field SHOULD set the "parent" attribute to "true" to identify it as the parent domain name of the domain status. A list of one or more CSV files using the child element. The child element defines a reference to the CSV file name and has the following optional attributes: compression If the CSV file is compressed, the "compression" - attribute defines the compression format like "gzip" or "zip". + attribute defines the compression format. For example, setting + this attribute to "gzip" signals that the CSV file is + compressed using the GZIP file format (see, [RFC1952]). The + supported compression formats are negotiated out-of-band. encoding Defines the encoding of the CSV file with the default encoding of "UTF-8". - cksum Defines the checksum of the CSV file using CRC32, as - defined in Section 4.4. This attribute is used to validate - that the full CSV file exists and has not been tampered with. + cksum Defines the checksum of the CSV file, as described in + Section 4.4, using the algorithm defined by the "cksumAlg" + attribute. If the "cksumAlg" attribute is not present, the + checksum is calculated using "CRC32". + + cksumAlg Defines the checksum algorithm used to calculate the + "cksum" attribute, with the default value of "CRC32". If this + attribute is present, the "cksum" attribute MUST also be + present. The supported checksum algorithms are negotiated out- + of-band. The element requires a "name" attribute that defines the purpose of the CSV file with values like "domain", "host", "contact". The supported "name" attribute values are defined for each object type. The OPTIONAL "sep" attribute defines the CSV separator character with the default separator character of ",". The following is an example of the element for domain name records where the is set as required with isRequired="true". @@ -697,38 +751,39 @@ There are two elements used in the data escrow of the domain name objects for the XML model including the , under the element, and the element, under the element. 5.1.1.1. object The domain element is based on the EPP domain response for an authorized client (see Section 3.1.2. of [RFC5731]) with additional data from an EPP Query Response, see Section 3.1.3. of - [RFC5731], RGP status from [RFC3915], and data from the EPP - command, see Section 5.2.1. of [RFC5910]. + [RFC5731], Registry Grace Period (RGP) status from [RFC3915], and + data from the EPP command, see Section 5.2.1. of + [RFC5910]. A element substitutes for the abstract element to define a concrete definition of a domain. The element can be replaced by other domain definitions using the XML schema substitution groups feature. The element contains the following child elements: - o A element that contains the fully qualified name of the + o A element that contains the fully-qualified name of the domain name object. For IDNs the A-Label is used (see [RFC5891], Section 4.4). o A element that contains the repository object identifier assigned to the domain name object when it was created. - o An OPTIONAL element that contains the fully qualified + o An OPTIONAL element that contains the fully-qualified domain name in Unicode character set. It MUST be provided if available. o An OPTIONAL element that references the IDN Table used for the IDN. This corresponds to the "id" attribute of the element. This element MUST be present if the domain name is an IDN. o An OPTIONAL element is used to indicate that the domain name is an IDN variant. This element contains the domain @@ -744,21 +799,21 @@ [RFC3915]. o An OPTIONAL element that contains the identifier for the human or organizational social information object associated as the holder of the domain name object. o Zero or more OPTIONAL elements that contain identifiers for the human or organizational social information objects associated with the domain name object. - o An OPTIONAL element that contains the fully qualified names + o An OPTIONAL element that contains the fully-qualified names of the delegated host objects or host attributes (name servers) associated with the domain name object. See Section 1.1 of [RFC5731] for a description of the elements used to specify host objects or host attributes. o A element that contains the identifier of the sponsoring registrar. o An OPTIONAL element that contains the identifier of the registrar that created the domain name object. An OPTIONAL client @@ -845,21 +900,21 @@ RegistrarX RegistrarX 1999-04-03T22:00:00.0Z 2015-04-03T22:00:00.0Z ... 5.1.1.2. object - The element contains the fully qualified domain + The element contains the fully-qualified domain name that was deleted and purged. Example of object: ... ... foo.example bar.example @@ -909,21 +964,21 @@ The following "csvDomain" field elements MUST be used in the "domain" element: Domain name field with type="eppcom:labelType" and isRequired="true". The following "csvDomain" field elements MAY be used in the "domain" element: - Fully qualified name of the original IDN + Fully-qualified name of the original IDN domain name object related to the variant domain name object with type="eppcom:labelType". The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the "domain" element: Registry Object IDentifier (ROID) for the domain name object with isRequired="true". or A choice of: @@ -1095,23 +1150,23 @@ The following "csvDomain" fields, defined for the "domain" CSV File Definition (Section 5.1.2.1.1), MUST be used in the "domainStatuses" element: Domain name of status with isRequired="true". The status of the domain name with type="domain:statusValueType" and isRequired="true". - The Registry Grace Period (RGP) status, as a - sub-status of the "pendingDelete" status - value, with type="rgp:statusValueType" as defined in [RFC3915]. + The RGP status, as a sub-status of the + "pendingDelete" status value, with + type="rgp:statusValueType" as defined in [RFC3915]. The following "rdeCsv" fields, defined in section CSV common field elements (Section 4.6.2.2), MAY be used in the "domainStatuses" element: Domain object status description which is free form text describing the rationale for the status. Language of the field. @@ -1549,21 +1604,21 @@ element can be replaced by other host definitions using the XML schema substitution groups feature. 5.2.1.1. element The RDE host object is based on the EPP host response for an authorized client (Section 3.1.2. of [RFC5732]). The OPTIONAL element contains the following child elements: - o A element that contains the fully qualified name of the + o A element that contains the fully-qualified name of the host object. o A element that contains the repository object identifier assigned to the host object when the object was created. o One or more elements that describe the status of the host object. o Zero or more elements that contain the IP addresses associated with the host object. @@ -1597,35 +1652,35 @@ Example of object: ... ns1.example1.example Hns1_example_test-TEST 192.0.2.2 192.0.2.29 - 1080:0:0:0:8:800:200C:417A + 2001:DB8:1::1 RegistrarX RegistrarX 1999-05-08T12:10:00.0Z RegistrarX 2009-10-03T09:34:00.0Z ... 5.2.1.2. object - The element contains the fully qualified domain name + The element contains the fully-qualified domain name of a host that was deleted. The element also supports host removal based on roid to support SRS systems in which - different hosts with the same fully qualified domain name are active + different hosts with the same fully-qualified domain name are active at the same time. Example of object: ... ... ns1.example.example @@ -3248,24 +3303,25 @@ A element substitutes for the abstract element to define a concrete definition of an NNDN. The element can be replaced by other NNDN definitions using the XML schema substitution groups feature. 5.6.1.1. object The element contains the following child elements: - o An element that contains the fully qualified name of the - NNDN. For IDNs the A-Label is used (see [RFC5891], Section 4.4). + o An element that contains the fully-qualified qualified + name of the NNDN. For IDNs the A-Label is used (see [RFC5891], + Section 4.4). - o An OPTIONAL element that contains the fully qualified name + o An OPTIONAL element that contains the fully-qualified name of the NNDN in Unicode character set. It MUST be provided if available. o An OPTIONAL element that references the IDN Table used for the NNDN. This corresponds to the "id" attribute of the element. This element MUST be present if the NNDN is an IDN. o An OPTIONAL element is used to indicate that the NNDN is used for an IDN variant. This element contains the domain @@ -3342,21 +3398,21 @@ NNDN CSV file definitions. 5.6.2.1.1. "NNDN" CSV File Definition The "NNDN" CSV File Definition defines the fields and CSV file references used for the NNDN object records. The following "csvNNDN" field elements MUST be used in the "NNDN" element: - Fully qualified name of the NNDN with + Fully-qualified name of the NNDN with type="eppcom:labelType" and isRequired="true". For IDNs the A-Label is used (see [RFC5891], Section 4.4). State of the NNDN: blocked or withheld with type="rdeNNDN:nameState" and isRequired="true". See Section 5.6.1.1 for a description of the possible values for the element. The following field elements MAY be used in the "NNDN" element: @@ -3422,21 +3478,21 @@ Differential or Incremental Deposit. The is split into separate CSV file definitions using named elements with the "name" attribute. The following section defines the supported NNDN deletes CSV file definition. 5.6.2.2.1. "NNDN" Deletes CSV File Definition The following "NNDN" field elements MUST be used in the deletes "NNDN" element: - Fully qualified name of the NNDN with + Fully-qualified name of the NNDN with type="eppcom:labelType" and isRequired="true". Example of an "NNDN" element. ... ... @@ -3565,24 +3621,23 @@ 5.9.1. object The contains the following elements: o A choice of one of the elements defined in the "repositoryTypeGroup" group element that indicates the unique identifier for the repository being escrowed. Possible elements are: - * A element that defines TLD or the REGISTRY- - CLASS DOMAIN NAME (RCDN) being escrowed in the case of a - Registry data escrow deposit. For IDNs the A-Label is used - (see [RFC5891], Section 4.4). + * A element that defines TLD or the RCDN being + escrowed in the case of a Registry data escrow deposit. For + IDNs the A-Label is used (see [RFC5891], Section 4.4). * A element that defines the Registrar ID corresponding to a Registrar data escrow deposit. In the case of an ICANN-accredited Registrar, the element MUST be the IANA Registrar ID assigned by ICANN. * A element that defines the provider ID corresponding to a Privacy and Proxy Services Provider data escrow deposit. In the case of an ICANN-accredited Privacy and Proxy Services Provider, the element MUST be @@ -3596,34 +3651,33 @@ deposit: Differential, Full or Incremental. The element supports the following attributes: * A "uri" attribute reflects the XML namespace URI of the primary objects for the XML Model and CSV Model. For example, the "uri" is set to "urn:ietf:params:xml:ns:rdeDomain-1.0" for domain name objects using the XML Model, and the "uri" is set to "urn:ietf:params:xml:ns:csvDomain-1.0" for domain name objects using the CSV Model. - * An OPTIONAL "rcdn" attribute indicates the REGISTRY-CLASS - DOMAIN NAME (RCDN) of the objects included in the - element. For IDNs the A-Label is used [RFC5891], Section 4.4. - If the "rcdn" attribute is present, the value of the - element must include only objects related to registrations in - the same and lower levels. For example in a data escrow - deposit for the .EXAMPLE TLD, a value of "example" in the - "rcdn" attribute within the element indicates the - number of objects in the TLD including objects in other RCDNs - within the TLD, whereas a value of "com.example" indicates the - number of elements for objects under "com.example" and lower - levels. Omitting the "rcdn" attribute indicates that the total - includes all objects of the specified "uri" in the repository - (e.g. the TLD, Registrar, or PPSP). + * An OPTIONAL "rcdn" attribute indicates the RCDN of the objects + included in the element. For IDNs the A-Label is used + [RFC5891], Section 4.4. If the "rcdn" attribute is present, + the value of the element must include only objects + related to registrations in the same and lower levels. For + example in a data escrow deposit for the .EXAMPLE TLD, a value + of "example" in the "rcdn" attribute within the element + indicates the number of objects in the TLD including objects in + other RCDNs within the TLD, whereas a value of "com.example" + indicates the number of elements for objects under + "com.example" and lower levels. Omitting the "rcdn" attribute + indicates that the total includes all objects of the specified + "uri" in the repository (e.g. the TLD, Registrar, or PPSP). * An OPTIONAL "registrarId" attribute indicates the identifier of the sponsoring Registrar of the objects included in the element. In the case of an ICANN-accredited Registrar, the value MUST be the IANA Registrar ID assigned by ICANN. o An OPTIONAL element that contains a tag that defines the expected content in the deposit. The producer and consumer of the deposits will coordinate the set of possible element values. @@ -4185,20 +4239,22 @@ + @@ -6721,20 +6777,26 @@ 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 +16.21. Changes REGEXT 08 to REGEXT 09 + + 1. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + EmKW32exlPgLbBUIbS8OjdYUJWc + 17. Example of a Full Deposit using the XML model Example of a Full Deposit using the XML model: ns1.example1.example Hns1_example_test-TEST 192.0.2.2 192.0.2.29 - 1080:0:0:0:8:800:200C:417A - + 2001:DB8:1::1 RegistrarX RegistrarX 1999-05-08T12:10:00.0Z RegistrarX 2009-10-03T09:34:00.0Z sh8013 @@ -8083,52 +8146,80 @@ [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS + Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, + January 2019, . + + [V42] International Telecommunication Union, "V.42 : Error- + correcting procedures for DCEs using asynchronous-to- + synchronous conversion", March 2002, + . + [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126", November 2008, . [W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition REC- 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-AGB-20120604] + ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June + 2012, . + [ICANN-GTLD-RA-20170731] ICANN, "Base Registry Agreement 2017-07-31", July 2017, . + [RFC1952] Deutsch, P., "GZIP file format specification version 4.3", + RFC 1952, DOI 10.17487/RFC1952, May 1996, + . + [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, . + [RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma- + Separated Values (CSV) Files", RFC 4180, + DOI 10.17487/RFC4180, October 2005, + . + + [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and SHA-based HMAC and HKDF)", RFC 6234, + DOI 10.17487/RFC6234, May 2011, + . + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, .