--- 1/draft-ietf-regext-dnrd-objects-mapping-03.txt 2019-12-16 14:13:15.005698337 -0800 +++ 2/draft-ietf-regext-dnrd-objects-mapping-04.txt 2019-12-16 14:13:15.301705894 -0800 @@ -1,20 +1,20 @@ Network Working Group G. Lozano Internet-Draft ICANN Intended status: Standards Track J. Gould -Expires: May 29, 2020 C. Thippeswamy +Expires: June 18, 2020 C. Thippeswamy VeriSign - Nov 26, 2019 + Dec 16, 2019 Domain Name Registration Data (DNRD) Objects Mapping - draft-ietf-regext-dnrd-objects-mapping-03 + draft-ietf-regext-dnrd-objects-mapping-04 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,120 +23,141 @@ 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 May 29, 2020. + This Internet-Draft will expire on June 18, 2020. Copyright Notice Copyright (c) 2019 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 extracted from this document must 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 5 + 4. General Conventions . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 6 - 4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 6 - 4.6. CSV Parent Child Relationship . . . . . . . . . . . . . . 6 - 4.7. CSV elements . . . . . . . . . . . . . . . . . . . . . . 7 - 4.8. Internationalized and Localized Elements . . . . . . . . 12 - 5. Object Description . . . . . . . . . . . . . . . . . . . . . 14 - 5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 14 - 5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 33 - 5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 43 - 5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 61 - 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 69 - 5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 73 - 5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 78 - 5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 80 - 5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 80 - 6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 83 - 7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 - 8. Data escrow agent extended verification process . . . . . . . 84 - 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 85 - 9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 85 - 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 95 - 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 98 - 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 103 - 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 105 - 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 108 - 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 111 - 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 117 - 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 121 - 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 125 - 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 127 - 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 129 - 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 131 - 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 133 - 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 136 - 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 137 - 10. Internationalization Considerations . . . . . . . . . . . . . 139 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 139 - 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 145 - 12.1. Implementation in the gTLD space . . . . . . . . . . . . 145 + 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 + 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 . . . . . . . . . . . . . . . . . . . . . 86 + 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 96 + 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 99 + 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 104 + 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 106 + 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 109 + 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 112 + 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 118 + 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 122 + 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 126 + 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 128 + 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 130 + 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 132 + 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 134 + 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 137 + 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 138 + 10. Internationalization Considerations . . . . . . . . . . . . . 140 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 + 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 146 + 12.1. Implementation in the gTLD space . . . . . . . . . . . . 146 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 146 - 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 146 - 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 146 - 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 147 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 147 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 147 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 147 + 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 148 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 - to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 147 - 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 147 - 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 148 - 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 148 - 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 148 - 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 150 - 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 150 - 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 151 - 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 151 - 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 151 - 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 151 - 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 151 - 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 151 - 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 151 - 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 153 - 17. Example of a full deposit using the XML model . . . . . . . . 153 - 18. Example of differential deposit using the XML model . . . . . 159 - 19. Example of a full deposit using the CSV model . . . . . . . . 160 - 20. Example of differential deposit using the CSV model . . . . . 169 - 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 180 - 21.1. Normative References . . . . . . . . . . . . . . . . . . 180 - 21.2. Informative References . . . . . . . . . . . . . . . . . 181 - 21.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 182 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 182 + to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 148 + 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 148 + 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 149 + 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 149 + 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 149 + 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 151 + 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 151 + 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 152 + 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 152 + 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 152 + 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 152 + 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 152 + 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 152 + 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 152 + 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 154 + 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 154 + 17. Example of a full deposit using the XML model . . . . . . . . 155 + 18. Example of differential deposit using the XML model . . . . . 160 + 19. Example of a full deposit using the CSV model . . . . . . . . 162 + 20. Example of differential deposit using the CSV model . . . . . 171 + 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 182 + 21.1. Normative References . . . . . . . . . . . . . . . . . . 182 + 21.2. Informative References . . . . . . . . . . . . . . . . . 183 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 184 1. Introduction - This document defines the data escrow structure of the standard set - of objects for a Domain Name Registry which include: + 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. + + 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. + + 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. o Host: Internet host names that are typically provisioned in a Domain Name Registry using the EPP host mapping [RFC5732]. The attributes defined in the EPP host mapping [RFC5732] are fully supported by this document. @@ -136,70 +157,84 @@ The attributes defined in the EPP domain name mapping [RFC5731] are fully supported by this document. o Host: Internet host names that are typically provisioned in a Domain Name Registry using the EPP host mapping [RFC5732]. The attributes defined in the EPP host mapping [RFC5732] are fully supported by this document. 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): A lightweight domain-like object - that is not linked to a Registrar. + o NNDN (NNDN's not domain name): Domain Name Registries may maintain + domain names without them 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. 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. 2. Models This document defines two different models that can be used to - deposit data escrow objects: + deposit data escrow objects: XML and CSV. - o XML: The XML model includes all the deposit information (meta-data + 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. + +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 (urn:ietf:params:xml:ns:rdeDomain-1.0). + 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 + (urn:ietf:params:xml:ns:rdeDomain-1.0). - o CSV: The CSV model uses XML to define the data escrow format of - the data contained in referenced Comma-Separated Values (CSV) - files. As a convention, the objects represented using the CSV - model is referenced using CSV and an XML namespace that is - prefixed with "csv". For example, the Domain Name object - represented using the CSV model can be referred to as the CSV - Domain Name with the XML namespace including csvDomain - (urn:ietf:params:xml:ns:csvDomain-1.0). +2.2. CSV Model - The data escrow deposit MAY contain a mix of both models but an - object MUST be escrowed only in one model. + CSV: The CSV model uses XML to define the data escrow format of the + data contained in referenced Comma-Separated Values (CSV) files. As + a convention, the objects represented using the CSV model is + referenced using CSV and an XML namespace that is prefixed with + "csv". For example, the Domain Name object represented using the CSV + model can be referred to as the CSV Domain Name with the XML + 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 @@ -255,24 +290,26 @@ 4.4. Checksum Checksum of the CSV data escrow files MUST use CRC32, that is the algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 of ITU-T recommendation V.42. 4.5. IP addresses IP addresses syntax MUST conform to the text representation of either - of, Internet Protocol [RFC0791], for IPv4 addresses, or IP Version 6 - Addressing Architecture [RFC4291], for IPv6 addresses. + Internet Protocol Version 4 [RFC0791] or Internet Protocol Version 6 + [RFC4291]. -4.6. CSV Parent Child Relationship +4.6. Conventions applicable to the CSV Model + +4.6.1. CSV Parent Child Relationship The CSV model represents a relational model, where the CSV files represent relational tables, the fields of the CSV files represent columns of the tables, and each line of the CSV file represents a record. As in a relational model, the CSV files can have relationships utilizing primary keys in the parent CSV file definitions and foreign keys in the child CSV file definitions for a 1-to-many relationship. The primary keys are not explicitly defined, but the foreign keys are using the boolean "parent" field attribute in the child CSV file. The relationships between the CSV files are @@ -323,50 +360,50 @@ sampleStatuses-YYYYMMDD.csv ... -4.7. CSV elements -4.7.1. element +4.6.2. CSV elements - To support a CSV model with the Registry Data Escrow Specification - [1], an element is defined for each object that substitutes for the - element and for the element, that contains - one or more elements. For example, the Domain Name - Object (Section 5.1) defines the element, that - substitutes for the element, and the - element, that substitutes for the - element. Both the element and the - elements contain one or more +4.6.2.1. element + + To support the CSV model, an element is defined for each object that + substitutes for the element and for the + element, that contains one or more elements. For + example, the Domain Name Object (Section 5.1) defines the + element, that substitutes for the + element, and the element, that substitutes for + the element. Both the element and + the elements contain one or more elements. The element has the following child elements: Ordered list of CSV fields used in the CSV files. There is one or more child elements that substitute for the abstract element. Each element defines the format of the CSV field contained in the CSV files. The elements support the "type" attribute that defines the XML simple data type of the field element. The elements support the "isRequired" attribute, with a default value of "false", when set to "true" indicates that the field must be non- empty in the CSV files and when set to "false" indicates that the field MAY be empty in the CSV files. The "isRequired" attribute MAY be specifically set for the field elements within the XML schema and MAY be overridden when specifying the fields under the element. The element supports an OPTIONAL "parent" attribute that identifies the field as a reference to a parent object, as defined in CSV Parent Child - Relationship (Section 4.6). For example, the 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" @@ -413,21 +450,21 @@ domain-YYYYMMDD.csv ... The following is example of the "domain-YYYYMMDD.csv" file with one record matching the definition. - domain1.test,Ddomain2-TEST,,,registrantid,registrarX,registrarX, + domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX, clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, 2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z The following is an example of the element for domain name records. ... @@ -438,28 +475,28 @@ domain-delete-YYYYMMDD.csv ... The following is example of the "domain-delete-YYYYMMDD.csv" file with three records that matches the single field. - domain1.test - domain2.test - domainN.test + domain1.example + domain2.example + domainN.example -4.7.2. CSV common field elements +4.6.2.2. CSV common field elements The element defined in the element - (Section 4.7.1) section has child elements that substitute for the + (Section 4.6.2.1) section has child elements that substitute for the abstract element. By convention elements include an 'f' prefix to identify them as field definition elements. There are a set of common field elements that are used across multiple data escrow objects. The common field elements are defined using the "urn:ietf:params:xml:ns:rdeCsv-1.0" namespace and using the "rdeCsv" sample namespace prefix. The CSV common field elements include: UTF-8 encoded name field with type="eppcom:labelType". @@ -529,21 +566,21 @@ General positive integer field with type="positiveInteger". Contains the URL of an object like a registrar object with type="anyURI". Custom field with name attribute that defines the custom field name" with type="token". -4.8. Internationalized and Localized Elements +4.6.3. Internationalized and Localized Elements Some elements MAY be provided in either internationalized form ("int") or provided in localized form ("loc"). Those elements use a field value or "isLoc" attribute to specify the form used. If an "isLoc" attribute is used, a value of "true" indicates the use of the localized form and a value of "false" indicates the use of the internationalized form. This MAY override the form specified for a parent element. A value of "int" is used to indicate the internationalized form and a value of "loc" is used to indicate the localized form. When the internalized form ("int") is provided, the @@ -774,51 +811,51 @@ the registry. For all other status types, the value identifies the date and time when the request was completed. * An OPTIONAL element that contains the end of the domain name object's validity period (expiry date) if the transfer caused or causes a change in the validity period. Example of a domain object: ... - - example1.test - Dexample1-TEST - - jd1234 - sh8013 - sh8013 - + + example1.example + Dexample1-TEST + + jd1234 + sh8013 + sh8013 + ns1.example.com - ns1.example1.test - - RegistrarX - RegistrarX - 1999-04-03T22:00:00.0Z - 2015-04-03T22:00:00.0Z - + ns1.example1.example + + 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 name that was deleted and purged. Example of object: ... ... - foo.test - bar.test + foo.example + bar.example ... ... 5.1.2. CSV Model For the CSV Model of the domain name object, the child element of the element is used to hold the new or updated domain name objects for the deposit. The @@ -878,21 +915,21 @@ or A choice of: Identifier of the sponsoring client with isRequired="true". Contains the ID assigned by ICANN with type="positiveInteger". The attribute "isRequired" MUST equal "true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "domain" + elements (Section 4.6.2.2), MAY be used in the "domain" element: Identifier of the registrar, defined in Section 5.4, of the client that created the object. Identifier of the client that created the domain name object. Identifier of the registrar, defined in Section 5.4, of the client that updated the object. @@ -950,30 +987,30 @@ ... ... Example of the corresponding domain-YYYYMMDD.csv file. The file contains four records (two active ASCII domains, original IDN with LANG-1 language rules, and variant IDN with LANG-1 language rules). - domain1.test,Ddomain1-TEST,,,registrantid,registrarX,registrarX, + domain1.example,Ddomain1-TEST,,,registrantid,registrarX,registrarX, clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, 2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z - domain2.test,Ddomain2-TEST,,,registrantid,registrarX,registrarX, + domain2.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX, clientY,1999-04-03T22:00:00.0Z,registrarX,clientY, 2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z - xn--abc123.test,Dxnabc123-TEST,LANG-1,,registrantid,registrarX, + xn--abc123.example,Dxnabc123-TEST,LANG-1,,registrantid,registrarX, registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY, 2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z - xn--abc321.test,Dxnabc321-TEST,LANG-1,xn--abc123.test, + xn--abc321.example,Dxnabc321-TEST,LANG-1,xn--abc123.example, registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z, registrarX,clientY,2009-12-03T09:05:00.0Z,2015-04-03T22:00:00.0Z 5.1.2.1.2. "domainContacts" CSV File Definition The "domainContacts" CSV File Definition defines the fields and CSV file references used for the domain name object link records to contact objects, as described in Contact Object (Section 5.3). The following "csvDomain" field elements, defined for the "domain" @@ -1014,56 +1051,56 @@ domainContacts-YYYYMMDD.csv ... ... Example of the corresponding domainContacts-YYYYMMDD.csv file. The file contains an admin, tech, and billing contact for the four domain - names domain1.test, domain2.test, xn--abc123.test and xn-- - abc321.test. + names domain1.example, domain2.example, xn--abc123.example and xn-- + abc321.example. - domain1.test,domain1admin,admin - domain1.test,domain1tech,tech - domain1.test,domain1billing,billing - domain2.test,domain2admin,admin - domain2.test,domain2tech,tech - domain2.test,domain2billing,billing - xn--abc123.test,xnabc123admin,admin - xn--abc123.test,xnabc123tech,tech - xn--abc123.test,xnabc123billing,billing - xn--abc321.test,xnabc123admin,admin - xn--abc321.test,xnabc123tech,tech - xn--abc321.test,xnabc123billing,billing + domain1.example,domain1admin,admin + domain1.example,domain1tech,tech + domain1.example,domain1billing,billing + domain2.example,domain2admin,admin + domain2.example,domain2tech,tech + domain2.example,domain2billing,billing + xn--abc123.example,xnabc123admin,admin + xn--abc123.example,xnabc123tech,tech + xn--abc123.example,xnabc123billing,billing + xn--abc321.example,xnabc123admin,admin + xn--abc321.example,xnabc123tech,tech + xn--abc321.example,xnabc123billing,billing 5.1.2.1.3. "domainStatuses" CSV File Definition The "domainStatuses" CSV File Definition defines the fields and CSV file references used for the domain name object statuses. 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 following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "domainStatuses" + 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. Example of a "domainStatuses" element. @@ -1083,30 +1120,30 @@ cksum="98D139A3"> domainStatuses-YYYYMMDD.csv ... ... Example of the corresponding domainStatuses-YYYYMMDD.csv file. The - file contains the statuses for the four domain names domain1.test, - domain2.test, xn--abc123.test and xn--abc321.test. + file contains the statuses for the four domain names domain1.example, + domain2.example, xn--abc123.example and xn--abc321.example. - domain1.test,clientUpdateProhibited,"Disallow update", + domain1.example,clientUpdateProhibited,"Disallow update", en, - domain1.test,clientDeleteProhibited,"Disallow delete", + domain1.example,clientDeleteProhibited,"Disallow delete", en, - domain2.test,ok,,, - xn--abc123.test,ok,,, - xn--abc321.test,ok,,, + domain2.example,ok,,, + xn--abc123.example,ok,,, + xn--abc321.example,ok,,, 5.1.2.1.4. "domainNameServers" CSV File Definition The "domainNameServers" CSV File Definition defines the fields and CSV file references used for the domain name delegated hosts (name servers). The "domainNameServers" CSV files define the relationship between a domain name object and a delegated host. The "domainNameServers" CSV File is used to support the model, defined in [RFC5731]. @@ -1145,31 +1182,31 @@ domainNameServers-YYYYMMDD.csv ... ... Example of the corresponding domainNameServers-YYYYMMDD.csv file. The file contains the delegated hosts (name servers) for the four - domain names domain1.test, domain2.test, xn--abc123.test and xn-- - abc321.test referenced via the field element. + domain names domain1.example, domain2.example, xn--abc123.example and + xn--abc321.example referenced via the field element. - domain1.test,Hns1_domain1_test-TEST - domain1.test,Hns2_domain1_test-TEST - domain2.test,Hns1_domain2_test-TEST - domain2.test,Hns2_domain2_test-TEST - xn--abc123.test,Hns1_example_test-TEST - xn--abc123.test,Hns2_example_test-TEST - xn--abc321.test,Hns1_example_test-TEST - xn--abc321.test,Hns2_example_test-TEST + domain1.example,Hns1_domain1_test-TEST + domain1.example,Hns2_domain1_test-TEST + domain2.example,Hns1_domain2_test-TEST + domain2.example,Hns2_domain2_test-TEST + xn--abc123.example,Hns1_example_test-TEST + xn--abc123.example,Hns2_example_test-TEST + xn--abc321.example,Hns1_example_test-TEST + xn--abc321.example,Hns2_example_test-TEST 5.1.2.1.5. "domainNameServersAddresses" CSV File Definition The "domainNameServersAddresses" CSV File Definition defines the fields and CSV file references used for supporting the host as domain attributes model. The following "csvDomain" fields, defined for the "domain" CSV File Definition (Section 5.1.2.1.1), MUST be used in the "domainNameServersAddresses" element: @@ -1214,31 +1251,31 @@ domainNameServersAddresses-YYYYMMDD.csv ... ... Example of the corresponding domainNameServersAddresses-YYYYMMDD.csv file. The file contains the delegated hosts (name servers) for the - four domain names domain1.test, domain2.test, xn--abc123.test and - xn--abc321.test. + four domain names domain1.example, domain2.example, xn-- + abc123.example and xn--abc321.example. - domain1.test,ns1.domain1.test,192.0.2.1,v4 - domain1.test,ns2.domain1.test,2001:DB8::1,v6 - domain2.test,ns1.domain2.test2,192.0.2.2,v4 - domain2.test,ns2.domain2.test2,2001:DB8::2,v6 - xn--abc123.test,ns1.example.example,, - xn--abc123.test,ns2.example.example,, - xn--abc321.test,ns1.example.example,, - xn--abc321.test,ns2.example.example,, + domain1.example,ns1.domain1.example,192.0.2.1,v4 + domain1.example,ns2.domain1.example,2001:DB8::1,v6 + domain2.example,ns1.example.net,, + domain2.example,ns2.example.net,, + xn--abc123.example,ns1.example.net,, + xn--abc123.example,ns2.example.net,, + xn--abc321.example,ns1.example.net,, + xn--abc321.example,ns2.example.net,, 5.1.2.1.6. "dnssec" CSV File Definition The "dnssec" CSV File Definition defines the fields and CSV file references used for the domain name object DNSSEC records (DS or Key Data). The following "csvDomain" field elements MUST be used in the "dnssec" element when the DS Data Interface per [RFC5910] is used: @@ -1307,24 +1344,24 @@ cksum="10ED6C42"> dnssec-ds-YYYYMMDD.csv ... ... Example of the corresponding dnssec-ds-YYYYMMDD.csv file. The file - contains two DS records for domain1.test. + contains two DS records for domain1.example. - domain1.test,604800,12345,3,1,49FD46E6C4B45C55D4AC - domain1.test,604800,12346,3,1,38EC35D5B3A34B44C39B + domain1.example,604800,12345,3,1,49FD46E6C4B45C55D4AC + domain1.example,604800,12346,3,1,38EC35D5B3A34B44C39B Example of a "dnssec" element with the Key Data Interface of [RFC5910]: ... @@ -1337,54 +1374,54 @@ cksum="183C3F79"> dnssec-key-YYYYMMDD.csv ... ... Example of the corresponding dnssec-key-YYYYMMDD.csv file. The file - contains two key records for domain1.test. + contains two key records for domain1.example. - domain1.test,604800,257,3,1,AQPJ////4Q== - domain1.test,604800,257,3,1,AQPJ////4QQQ + domain1.example,604800,257,3,1,AQPJ////4Q== + domain1.example,604800,257,3,1,AQPJ////4QQQ 5.1.2.1.7. "domainTransfer" CSV File Definition The "domainTransfer" CSV File Definition defines the fields and CSV file references used for the domain name object pending and completed transfer records. No additional field elements were added for use in the "domainTransfer" element. The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "domainTransfer" + elements (Section 4.6.2.2), MUST be used in the "domainTransfer" element: State of the most recent transfer request with isRequired="true". Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with isRequired="true". Date and time that the transfer was requested with isRequired="true". Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with isRequired="true". Date and time that the transfer action should be taken or has been taken with isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "domainTransfer" + elements (Section 4.6.2.2), MAY be used in the "domainTransfer" element: Expiration date if the transfer command caused or causes a change in the validity period. Identifier of the client that requested the transfer. Identifier of the client that should take or took action for transfer. @@ -1420,21 +1457,21 @@ ... ... Example of the corresponding domainTransfer-YYYYMMDD.csv file. The file contains one domain transfer record with a pending status. - domain1.test,pending,registrarX,clientY, + domain1.example,pending,registrarX,clientY, 2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z, 2016-04-03T22:00:00.0Z 5.1.2.2. The is used to hold the deleted domain name objects in a differential or incremental deposit. All the domain name object data is deleted as part of a cascade delete. The is split into separate CSV file definitions using named elements with the "name" attribute. The following @@ -1465,22 +1502,22 @@ ... ... Example of the corresponding domain-delete-YYYYMMDD.csv file. The file contains two domain name records. - domain1.test - domain2.test + domain1.example + domain2.example 5.2. Host Object The host object is based on the EPP host name mapping in [RFC5732]. The host object supports both the XML Model and the CSV Model, defined in Models (Section 2) section. The elements used for both models are defined in the following sections. Both the and elements contain one or more elements with a set of named CSV file definitions using the "name" attribute. @@ -1539,21 +1576,21 @@ o An OPTIONAL element that contains the date and time of the most recent host object successful transfer. This element MUST NOT be present if the domain name object has never been transfered. Example of object: ... - ns1.example1.test + ns1.example1.example Hns1_example_test-TEST 192.0.2.2 192.0.2.29 1080:0:0:0:8:800:200C:417A RegistrarX RegistrarX 1999-05-08T12:10:00.0Z RegistrarX @@ -1568,21 +1605,21 @@ supports host removal based on roid to support SRS systems in which different hosts with the same fully qualified domain name are active at the same time. Example of object: ... ... - ns1.example.test + ns1.example.example ... ... 5.2.2. CSV Model For the CSV Model of the host object, the child element of the element is used to hold the new or updated host objects for the deposit. The child @@ -1614,21 +1651,21 @@ The "host" CSV File Definition defines the fields and CSV file references used for the host object records. The following "csvHost" field elements MUST be used in the "host" element: Host name field with type="eppcom:labelType" and isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "host" + elements (Section 4.6.2.2), MUST be used in the "host" element: Repository Object IDentifier (ROID) assigned to the host object with isRequired="true". The following "rdeCsv" and "csvRegistrar" fields, MAY be used in the "host" element: or A choice of: @@ -1684,60 +1721,60 @@ ... ... Example of the corresponding host-YYYYMMDD.csv file. The file contains six host records with four being internal hosts and two being external hosts. - ns1.domain1.test,Hns1_example_test-TEST,registrarX,registrarX, + ns1.domain1.example,Hns1_example_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z - ns2.domain1.test,Hns2_domain1_test-TEST,registrarX,registrarX, + ns2.domain1.example,Hns2_domain1_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z - ns1.domain2.test,Hns1_domain2_test-TEST,registrarX,registrarX, + ns1.domain2.example,Hns1_domain2_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z - ns2.domain2.test,Hns2_domain2_test-TEST,registrarX,registrarX, + ns2.domain2.example,Hns2_domain2_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z - ns1.example.example,Hns1_example_test-TEST,registrarX,registrarX, + ns1.example.net,Hns1_example_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z - ns2.example.example,Hns2_example_test-TEST,registrarX,registrarX, + ns2.example.net,Hns2_example_test-TEST,registrarX,registrarX, clientY,1999-05-08T12:10:00.0Z,registrarX, clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z 5.2.2.1.2. "hostStatuses" CSV File Definition The "hostStatuses" CSV File Definition defines the fields and CSV file references used for the host object statuses. The following "csvHost" fields, defined for the "host" CSV File Definition (Section 5.2.2.1.1), MUST be used in the "hostStatuses" element: The status of the host with type="host:statusValueType" and isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "hostStatuses" + elements (Section 4.6.2.2), MUST be used in the "hostStatuses" element: Host object Registry Object IDentifier (ROID) assigned to the host object with isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "hostStatuses" + elements (Section 4.6.2.2), MAY be used in the "hostStatuses" element: Host object status description which is free form text describing the rationale for the status. The attribute "isRequired" MUST equal "true". Language of the field. Example of a "hostStatuses" element. @@ -1756,23 +1793,23 @@ cksum="0DAE0583"> hostStatuses-YYYYMMDD.csv ... ... Example of the corresponding hostStatuses-YYYYMMDD.csv file. The - file contains the statuses for the six host names ns1.domain1.test, - ns2.domain1.test, ns1.domain2.test, ns2.domain2.test, - ns1.example.example and ns2.example.example. + file contains the statuses for the six host names + ns1.domain1.example, ns2.domain1.example, ns1.domain2.example, + ns2.domain2.example, ns1.example.net and ns2.example.net. Hns1_domain1_test-TEST,ok,, Hns2_domain1_test-TEST,ok,, Hns1_domain2_test-TEST,ok,, Hns2_domain2_test-TEST,ok,, Hns1_example_test-TEST,ok,, Hns2_example_test-TEST,ok,, 5.2.2.1.3. "hostAddresses" CSV File Definition @@ -1785,21 +1822,21 @@ IP addresses associated with the host object with type="host:addrStringType". The attribute "isRequired" MUST equal "true". IP addresses version associated with the host object with type="host:ipType". "host:ipType" has the enumerated values of "v4" or "v6". The attribute "isRequired" MUST equal "true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "hostAddresses" + elements (Section 4.6.2.2), MUST be used in the "hostAddresses" element: Host object Registry Object IDentifier (ROID) assigned to the host object with isRequired="true". Example of a "hostAddresses" element. ... ... @@ -1814,41 +1851,42 @@ cksum="28B194B0"> hostAddresses-YYYYMMDD.csv ... ... Example of the corresponding hostAddressesObj-YYYYMMDD.csv file. The - file contains the IP addresses for the host names ns1.domain1.test, - ns2.domain1.test, ns1.domain2.test and ns2.domain2.test. + file contains the IP addresses for the host names + ns1.domain1.example, ns2.domain1.example, ns1.domain2.example and + ns2.domain2.example. Hns1_domain1_test-TEST,192.0.2.1,v4 Hns2_domain1_test-TEST,2001:DB8::1,v6 Hns1_domain2_test-TEST,192.0.2.2,v4 Hns2_domain2_test-TEST,2001:DB8::2,v6 5.2.2.2. The is used to hold the deleted host objects in a differential or incremental deposit. All the host object data is deleted as part of a cascade delete. The is split into separate CSV file definitions using named elements with the "name" attribute. The following section defines the supported host deletes CSV file definition. 5.2.2.2.1. "host" Deletes CSV File Definition The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "host" + elements (Section 4.6.2.2), MUST be used in the "host" element: Repository Object IDentifier (ROID) assigned to the host object with isRequired="true". Example of a "host" element. ... ... @@ -2030,21 +2068,21 @@ 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 - jdoe@example.test + jdoe@example.example RegistrarX RegistrarX 2009-09-13T08:01:00.0Z RegistrarX 2009-11-26T09:10:00.0Z 2009-12-03T09:05:00.0Z pending clientW 2011-03-08T19:38:00.0Z @@ -2146,21 +2184,21 @@ or A choice of: Identifier of the sponsoring client with isRequired="true". Contains the ID assigned by ICANN with type="positiveInteger". The attribute "isRequired" MUST equal "true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "contact" + elements (Section 4.6.2.2), MAY be used in the "contact" element: Identifier of the registrar, defined in Section 5.4, of the client that created the object. Identifier of the client that created the contact object. Identifier of the registrar, defined in Section 5.4, of the client that updated the object. @@ -2206,73 +2244,73 @@ ... ... Example of the contact-YYYYMMDD.csv file. The file contains nine object contact records. domain1admin,Cdomain1admin-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z domain1tech,Cdomain1tech-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z domain1billing,Cdomain1billing-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z domain2admin,Cdomain2admin-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z domain2tech,Cdomain2tech-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z domain2billing,Cdomain2billing-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z xnabc123admin,Cxnabc123admin-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z xnabc123tech,Cxnabc123tech-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z xnabc123billing,Cxnabc123billing-TEST,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,registrarX,registarX, + +1.7035555556,,jdoe@example.example,registrarX,registarX, clientY,2009-09-13T08:01:00.0Z,registarX,clientY, 2009-11-26T09:10:00.0Z 5.3.2.1.2. "contactStatuses" CSV File Definition The "contactStatuses" CSV File Definition defines the fields and CSV file references used for the contact object statuses. The following "csvContact" field elements, defined for the "contact" CSV File Definition (Section 5.3.2.1.1), MUST be used in the "contactStatuses" element: Server-unique contact identifier of status with isRequired="true". The status of the contact with type="contact:statusValueType" and isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "contactStatuses" + elements (Section 4.6.2.2), MAY be used in the "contactStatuses" element: The contact object status description which is free form text describing the rationale for the status. Language of the field. Example of a "contactStatuses" element. @@ -2314,65 +2352,65 @@ The "contactPostal" CSV File Definition defines the fields and CSV file references used for the contact postal info object records. The following "csvContact" field elements MUST be used in the "contactPostal" element: Contains the form of the postal-address information with type="contact:postalLineType" and isRequired="true". This field specifies the form ("int" or - "loc"), as defined in Section 4.8, of the , + "loc"), as defined in Section 4.6.3, of the , , , , , , fields. Contains the contact's name of the individual or role represented by the contact with type="contact:postalLineType" and isRequired="true". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as defined in - section Section 4.8. + section Section 4.6.3. Contains the contact's contact's street address line with type="contact:fPostalLineType". An index attribute is required to indicate which street address line the field represents with index "0" for the first line and index "2" for the last line. An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as defined in section - Section 4.8. + Section 4.6.3. Contains the contact's city with type="contact:postalLineType" and isRequired="true". An OPTIONAL "isLoc" attribute to used to indicate the localized or - internationalized form as defined in section Section 4.8. + internationalized form as defined in section Section 4.6.3. Contains the contact's country code with type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized - form as defined in section Section 4.8. + form as defined in section Section 4.6.3. The following "csvContact" field elements MAY be used in the "contactPostal" element: Contains the name of the organization with which the contact is affiliated with type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute to used to indicate the localized or - internationalized form as defined in section Section 4.8. + internationalized form as defined in section Section 4.6.3. Contains the contact's state or province with type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as - defined in section Section 4.8. + defined in section Section 4.6.3. Contains the contact's postal code with type="contact:pcType". An OPTIONAL "isLoc" attribute to used to indicate the localized or internationalized form as defined in - section Section 4.8. + section Section 4.6.3. The following "csvContact" fields, defined for the "contact" CSV File Definition (Section 5.3.2.1.1), MUST be used in the "contactPostal" element: Server-unique contact identifier for the contact object with isRequired="true". Example of a "contactPostal" element. @@ -2427,41 +2465,41 @@ xnabc123billing,int,"John Doe","Example Inc.", "123 Example Dr.","Suite 100",,Reston,VA,20190,US 5.3.2.1.4. "contactTransfer" CSV File Definition The "contactTransfer" CSV File Definition defines the fields and CSV file references used for the contact object pending and completed transfer records. No additional field elements were added for use in the "contactTransfer" element. The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MUST be used in the "contactTransfer" + elements (Section 4.6.2.2), MUST be used in the "contactTransfer" element: State of the most recent transfer request with isRequired="true". Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with isRequired="true". Date and time that the transfer was requested with isRequired="true". Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with isRequired="true". Date and time that the transfer action should be taken or has been taken with isRequired="true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "contactTransfer" + elements (Section 4.6.2.2), MAY be used in the "contactTransfer" element: Identifier of the client that requested the transfer. Identifier of the client that should take or took action for transfer. The following "csvContact" fields, defined for the "contact" CSV File Definition (Section 5.3.2.1.1), MUST be used in the "contactTransfer" element: @@ -2753,25 +2791,25 @@ 123 Example Dr. Suite 100 Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 - jdoe@example.test - http://www.example.test + jdoe@example.example + http://www.example.example - whois.example.test - http://whois.example.test + whois.example.example + http://whois.example.example 2005-04-23T11:49:00.0Z 2009-02-17T17:51:00.0Z ... 5.4.1.2. object The element contains the id of a registrar that was deleted. @@ -2850,58 +2888,58 @@ Contains the ID assigned by ICANN with type="positiveInteger". This field is included in this section in addition to the section above to support optionally providing the field when the field is used. Contains the Whois URL of the registrar with type="anyURI". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "registrar" - element: + elements (Section 4.6.2.2), MAY be used in the "registrar" + element: Created date and time of the registrar object. Date and time of the last update to the registrar object. URL for the registrar web home page. The following "csvContact" fields, defined in section Contact Object (Section 5.3), MAY be used in the "registrar" element: Registrar street address line with an "index" attribute that represents the order of the street address line from "0" to "2". An OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, as defined in - Section 4.8. + Section 4.6.3. Registrar city with an OPTIONAL "isLoc" attribute that is used to indicate the localized or internationalized form, - as defined in Section 4.8. + as defined in Section 4.6.3. Registrar country code with an OPTIONAL "isLoc" attribute that is used to indicate the localized or - internationalized form, as defined in Section 4.8. + internationalized form, as defined in Section 4.6.3. Registrar email address. The attribute "isRequired" MUST equal "false". Registrar state or province with an OPTIONAL "isLoc" attribute that is used to indicate the localized or - internationalized form, as defined in Section 4.8. + internationalized form, as defined in Section 4.6.3. Registrar postal code with an OPTIONAL "isLoc" attribute that is used to indicate the localized or - internationalized form, as defined in Section 4.8. + internationalized form, as defined in Section 4.6.3. Registrar voice telephone number. Registrar voice telephone number extension. Registrar facsimile telephone number. Registrar facsimile telephone number extension. Example of a "registrar" @@ -2942,32 +2980,32 @@ ... ... Example of the registrar-YYYYMMDD.csv file. The file contains three registrar records. registrarX,"Example Inc.",1234,ok,"123 Example Dr.", "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,http://www.example.test, - http://whois.example.test,2005-04-23T11:49:00.0Z, + +1.7035555556,,jdoe@example.example,http://www.example.example, + http://whois.example.example,2005-04-23T11:49:00.0Z, 2009-02-17T17:51:00.0Z registrarY,"Example2 Inc.",1234,ok,"123 Example Dr.", "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,http://www.example.test, - http://whois.example.test,2005-04-23T11:49:00.0Z, + +1.7035555556,,jdoe@example.example,http://www.example.example, + http://whois.example.example,2005-04-23T11:49:00.0Z, 2009-02-17T17:51:00.0Z registrarZ,"Example2 Inc.",1234,ok,"123 Example Dr.", "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, - +1.7035555556,,jdoe@example.test,http://www.example.test, - http://whois.example.test,2005-04-23T11:49:00.0Z, + +1.7035555556,,jdoe@example.example,http://www.example.example, + http://whois.example.example,2005-04-23T11:49:00.0Z, 2009-02-17T17:51:00.0Z 5.4.2.2. The is used to hold the deleted registrar objects in a differential or incremental deposit. All the registrar object data is deleted as part of a cascade delete. The is split into separate CSV file definitions using named elements with the "name" attribute. The following section defines the supported registrar deletes CSV file @@ -3077,22 +3115,22 @@ reference object information for the deposit. The is split into separate CSV file definitions using named elements with the "name" attribute. The following sections include the supported IDN table reference CSV file definitions. 5.5.2.1.1. "idnLanguage" CSV File Definition The "idnLanguage" CSV File Definition defines the fields and CSV file references used for the IDN table reference object records. - The following "rdeCsv" fields, defined in Section 4.7.2, MUST be used - in the "idnLanguage" element: + The following "rdeCsv" fields, defined in Section 4.6.2.2, MUST be + used in the "idnLanguage" element: The language identifier that matches the values for the field element in the "domain" CSV File Definition (Section 5.1.2.1.1) files. The attribute "isRequired" MUST equal "true". URL that defines the character code points that can be used for the language defined by the field element. The attribute "isRequired" MUST equal "true". @@ -3168,23 +3206,25 @@ Example of the idnLanguage-delete-YYYYMMDD.csv file. The file contains one IDN language record. LANG-2 5.6. NNDN Object A NNDN (NNDN's not domain name) can be used to store registry reserved names or (blocked, withheld or mirrored) IDN variants. - A NNDN is a lightweight domain-like object that is not linked - directly to a Registrar (a mirroring NNDN is linked to a Registrar - via the original name). + Domain Name Registries may maintain domain names without them 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. A domain name can only exist as a domain name object or NNDN object, but not both. The NNDN object supports both the XML and the CSV Model, defined in the Models (Section 2) section. The elements used for both models are defined in the following sections. 5.6.1. XML Model @@ -3238,40 +3278,40 @@ mirroringNS is true. If another mechanism such as DNAME is used, the value of mirroringNS attribute MUST be false. o An OPTIONAL element that contains the date and time of the NNDN object creation. Example of object: ... - xn--exampl-gva.test + xn--exampl-gva.example pt-BR - example1.test + example1.example withheld 2005-04-23T11:49:00.0Z ... 5.6.1.2. object The element contains the ACE of a NNDN that was deleted, i.e., the . Example of object: ... ... - xn--pingino-q2a.test + xn--pingino-q2a.example ... ... 5.6.2. CSV Model For the CSV Model of the NNDN object, the child element of the element is used to hold the new or updated NNDN objects for the deposit. The child @@ -3311,21 +3351,21 @@ Domain name used to generate the IDN variant with type="eppcom:labelType". Defines whether the "mirroring" uses the NS mirror mechanism, as described for the "mirroringNS" attribute in Section 5.6.1.1, with type="boolean". If the field element is not defined the default value is "true". The following "rdeCsv" fields, defined in section CSV common field - elements (Section 4.7.2), MAY be used in the "NNDN" + elements (Section 4.6.2.2), MAY be used in the "NNDN" element: Created date and time of the NNDN object. Name of the NNDN in Unicode character set for the field element. IDN Table Identifier for the NNDN that matches an IDN Table Reference Object record, as defined in Section 5.5.2. @@ -3351,23 +3391,23 @@ ... ... Example of the corresponding NNDN-YYYYMMDD.csv file. The file contains two NNDN records for an IDN with one blocked variant and one mirrored variant. - xn--abc456.test,LANG-1,xn--abc123.test, + xn--abc456.example,LANG-1,xn--abc123.example, blocked,,2005-04-23T11:49:00.0Z - xn--abc789.test,LANG-1,xn--abc123.test, + xn--abc789.example,LANG-1,xn--abc123.example, mirrored,1,2005-04-23T11:49:00.0Z 5.6.2.2. The is used to hold the deleted NNDN objects in a 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. @@ -3395,21 +3435,21 @@ ... ... Example of the corresponding NNDN-delete-YYYYMMDD.csv file. The file contains one NNDN records. - xn--abc456.test + xn--abc456.example 5.7. EPP Parameters Object The EPP Parameters Object is a pseudo-object that defines the set of object and object extension services supported by the registry, as defined in [RFC5730]. The EPP Parameters Object is only defined as XML but could be used in the XML model or CSV model. The EPP Parameters Object is defined using the element. The EPP Parameters Object SHOULD be included if the registry supports EPP. Only one EPP Parameters Object MUST exist at @@ -3471,38 +3511,38 @@ ... 5.8. Policy Object The Policy object is a pseudo-object that is used to specify which OPTIONAL elements from the XML Model are REQUIRED based on the business model of the registry. For the CSV Model, the OPTIONAL "isRequired" attribute of the elements, defined in - Section 4.7.1, is used to specify which OPTIONAL fields are REQUIRED - based on the business model of the registry. + Section 4.6.2.1, is used to specify which OPTIONAL fields are + REQUIRED based on the business model of the registry. 5.8.1. object The OPTIONAL contains the following attributes: o An that defines that the referenced is REQUIRED. o that defines the XPath of the element referenced by . Example of object: ... + element="rdeDomain:registrant" /> ... 5.9. Header Object The Header Object is a pseudo-object that is used to specify the number of objects in the repository at a specific point in time (watermark) regardless of the type of deposit: differential, full or incremental. The Header Object may also be used to provide additional information on the contents of the deposit. The Header Object is only defined as XML but one header object MUST always be @@ -6959,44 +6999,72 @@ definition to be consistent with the "registrar" CSV definition. 20. Made the and elements optional for the host and contact objects in the XML model to be consistent with the domain object. 16.15. Changes REGEXT 02 to REGEXT 03 1. Added the optional element contentTag in the header object. - 2. Editorial updates + 2. Editorial updates. + +16.16. Changes REGEXT 03 to REGEXT 04 + + 1. Note: Updates from version REGEXT 03 to REGEXT 04 attend the + feedback provided during the document shepherd review. + + 2. Editorial updates. + + 3. Examples now use domain names from the .example TLD. + + 4. The introduction was enhanced by explaining the need for data + escrow and the proposed solution. + + 5. Explanation regarding NNDN was improved. + + 6. Explanation regarding the CSV and XML model was improved. + + 7. Section 4.5 updated to make the text clearer. + + 8. draft-arias-noguchi-registry-data-escrow is now referenced from + the I-D repository. + + 9. The XML prefix "rdeDomain" is now consistently used. + + 10. The prevID attribute was removed from the examples of full + deposits. + + 11. The examples were updated to use present dates. 17. Example of a full deposit using the XML model Example of a full deposit using the XML model: - - 2010-10-17T00:00:00Z + 2019-10-17T00:00:00Z 1.0 urn:ietf:params:xml:ns:rdeHeader-1.0 urn:ietf:params:xml:ns:rdeContact-1.0 urn:ietf:params:xml:ns:rdeHost-1.0 urn:ietf:params:xml:ns:rdeDomain-1.0 @@ -7023,65 +7091,64 @@ 1 1 1 - 1 1 - - - example1.test - Dexample1-TEST - - jd1234 - sh8013 - sh8013 - + + + example1.example + Dexample1-TEST + + jd1234 + sh8013 + sh8013 + ns1.example.com - ns1.example1.test - - RegistrarX - RegistrarX - 1999-04-03T22:00:00.0Z - 2015-04-03T22:00:00.0Z - + ns1.example1.example + + RegistrarX + RegistrarX + 1999-04-03T22:00:00.0Z + 2015-04-03T22:00:00.0Z + - - - example2.test - Dexample2-TEST - - - jd1234 - sh8013 - sh8013 - RegistrarX - RegistrarX - 1999-04-03T22:00:00.0Z - 2015-04-03T22:00:00.0Z - + + + example2.example + Dexample2-TEST + + + jd1234 + sh8013 + sh8013 + RegistrarX + RegistrarX + 1999-04-03T22:00:00.0Z + 2015-04-03T22:00:00.0Z + - + - ns1.example1.test + ns1.example1.example Hns1_example_test-TEST 192.0.2.2 192.0.2.29 1080:0:0:0:8:800:200C:417A RegistrarX RegistrarX 1999-05-08T12:10:00.0Z @@ -7104,21 +7171,21 @@ Dulles VA 20166-6503 US +1.7035555555 +1.7035555556 - jdoe@example.test + jdoe@example.example RegistrarX RegistrarX 2009-09-13T08:01:00.0Z RegistrarX 2009-11-26T09:10:00.0Z @@ -7141,33 +7207,34 @@ 123 Example Dr. Suite 100 Dulles VA 20166-6503 US + +1.7035555555 +1.7035555556 - jdoe@example.test + jdoe@example.example - http://www.example.test + http://www.example.example - whois.example.test + whois.example.example - http://whois.example.test + http://whois.example.example 2005-04-23T11:49:00.0Z 2009-02-17T17:51:00.0Z @@ -7169,29 +7236,28 @@ http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html http://registro.br/dominio/regras.html - - + - xn--exampl-gva.test + xn--exampl-gva.example pt-BR - example1.test + example1.example withheld 2005-04-23T11:49:00.0Z 1.0 en urn:ietf:params:xml:ns:domain-1.0 @@ -7218,48 +7284,47 @@ - + element="rdeDomain:registrant" /> 18. Example of differential deposit using the XML model Example of a differential deposit using the XML model: - - 2010-10-17T00:00:00Z + 2019-10-17T00:00:00Z 1.0 urn:ietf:params:xml:ns:rdeHeader-1.0 urn:ietf:params:xml:ns:rdeContact-1.0 urn:ietf:params:xml:ns:rdeHost-1.0 urn:ietf:params:xml:ns:rdeDomain-1.0 @@ -7268,23 +7333,23 @@ urn:ietf:params:xml:ns:rdeIDN-1.0 urn:ietf:params:xml:ns:rdeNNDN-1.0 urn:ietf:params:xml:ns:rdeEppParams-1.0 - - example2.test - + + example2.example + test 1 @@ -7321,22 +7387,22 @@ xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0" xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0" xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0" xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0" xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0" xmlns:csvIDN="urn:ietf:params:xml:ns:csvIDN-1.0" xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0" xmlns:csvNNDN="urn:ietf:params:xml:ns:csvNNDN-1.0" xmlns:rdeEppParams="urn:ietf:params:xml:ns:rdeEppParams-1.0" type="FULL" - id="20101017001" prevId="20101010001"> - 2010-10-18T00:00:00Z + id="20191017001"> + 2019-10-18T00:00:00Z 1.0 urn:ietf:params:xml:ns:csvDomain-1.0 urn:ietf:params:xml:ns:csvHost-1.0 urn:ietf:params:xml:ns:csvContact-1.0 urn:ietf:params:xml:ns:csvRegistrar-1.0 urn:ietf:params:xml:ns:csvIDN-1.0 urn:ietf:params:xml:ns:csvNNDN-1.0 urn:ietf:params:xml:ns:rdeEppParams-1.0 @@ -7756,22 +7823,22 @@ xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0" xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0" xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0" xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0" xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0" xmlns:csvIDN="urn:ietf:params:xml:ns:csvIDN-1.0" xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0" xmlns:csvNNDN="urn:ietf:params:xml:ns:csvNNDN-1.0" xmlns:rdeEppParams="urn:ietf:params:xml:ns:rdeEppParams-1.0" type="DIFF" - id="20101017001" prevId="20101010001"> - 2010-10-18T00:00:00Z + id="20191017001" prevId="20191010001"> + 2019-10-18T00:00:00Z 1.0 urn:ietf:params:xml:ns:csvDomain-1.0 urn:ietf:params:xml:ns:csvHost-1.0 urn:ietf:params:xml:ns:csvContact-1.0 urn:ietf:params:xml:ns:csvRegistrar-1.0 urn:ietf:params:xml:ns:csvIDN-1.0 @@ -8250,28 +8315,34 @@ + 21. References 21.1. Normative References + [I-D.ietf-regext-data-escrow] + Lozano, G., "Registry Data Escrow Specification", draft- + ietf-regext-data-escrow-02 (work in progress), November + 2019. + [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. @@ -8344,25 +8415,20 @@ RFC 7942, DOI 10.17487/RFC7942, July 2016, . [variantTLDsReport] Internet Corporation for Assigned Names and Numbers (ICANN), "A Study of Issues Related to the Management of IDN Variant TLDs", February 2012, . -21.3. URIs - - [1] http://tools.ietf.org/id/draft-arias-noguchi-registry-data- - escrow-05.txt - Authors' Addresses Gustavo Lozano Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles 90292 United States of America Phone: +1.310.823.9358 Email: gustavo.lozano@icann.org