--- 1/draft-ietf-regext-dnrd-objects-mapping-09.txt 2020-10-08 15:13:14.194800399 -0700 +++ 2/draft-ietf-regext-dnrd-objects-mapping-10.txt 2020-10-08 15:13:14.366802897 -0700 @@ -1,20 +1,20 @@ Network Working Group G. Lozano Internet-Draft ICANN Intended status: Standards Track J. Gould -Expires: February 13, 2021 C. Thippeswamy +Expires: April 11, 2021 C. Thippeswamy VeriSign - Aug 12, 2020 + Oct 08, 2020 Domain Name Registration Data (DNRD) Objects Mapping - draft-ietf-regext-dnrd-objects-mapping-09 + draft-ietf-regext-dnrd-objects-mapping-10 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 February 13, 2021. + This Internet-Draft will expire on April 11, 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 @@ -45,111 +45,112 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5 - 2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 5 + 2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 8 + 4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 8 + 4.4. CSV Integrity Check . . . . . . . . . . . . . . . . . . . 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. Object Description . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 17 + 5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 36 + 5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 46 + 5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 64 + 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 72 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.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 87 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 97 - 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 99 + 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 100 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.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 110 + 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 116 + 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 119 + 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 122 + 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 123 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 + 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 130 + 9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 132 + 10. Internationalization Considerations . . . . . . . . . . . . . 132 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132 + 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 140 + 12.1. Implementation in the gTLD space . . . . . . . . . . . . 141 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 141 + 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 142 + 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 142 + 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 143 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 - 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 + to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 143 + 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 143 + 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 144 + 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 144 + 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 144 + 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 145 + 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 146 + 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 146 + 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 147 + 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 147 + 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 147 + 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 147 + 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 147 + 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 147 + 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 149 + 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 149 + 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 150 + 16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 150 + 16.19. Changes REGEXT 06 to REGEXT 07 . . . . . . . . . . . . . 150 + 16.20. Changes REGEXT 07 to REGEXT 08 . . . . . . . . . . . . . 150 + 16.21. Changes REGEXT 08 to REGEXT 09 . . . . . . . . . . . . . 151 + 16.22. Changes REGEXT 09 to REGEXT 10 . . . . . . . . . . . . . 151 + 17. Example of a Full Deposit using the XML model . . . . . . . . 151 + 18. Example of Differential Deposit using the XML model . . . . . 157 + 19. Example of a Full Deposit using the CSV model . . . . . . . . 158 + 20. Example of Differential Deposit using the CSV model . . . . . 167 + 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 178 + 21.1. Normative References . . . . . . . . . . . . . . . . . . 178 + 21.2. Informative References . . . . . . . . . . . . . . . . . 181 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 182 1. Introduction - Registry Data Escrow is the process by which a registry periodically - submits data deposits to a third-party called an escrow agent. These - deposits comprise the minimum data needed by a third-party to resume - operations if the registry cannot function and is unable or unwilling - to facilitate an orderly transfer of service. For example, for a - domain name registry or registrar, the data to be deposited would - include all the objects related to registered domain names, e.g., - names, contacts, name servers, etc. + Registry Data Escrow (RDE) 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 also the users of services relying on the registry data. In the context of domain name registries, registration data escrow is a requirement for generic top-level domains (e.g., Specification 2 of the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and some country code top-level domain managers are also currently @@ -185,22 +186,22 @@ 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 EPP parameters: Contains the EPP parameters supported by the + Registry Operator. o Header: Used to specify counters of objects in the database at a certain point in time (watermark). o Policy: Used to specify OPTIONAL elements from this specification that are REQUIRED based on the business model of the registry. Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20081126] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are @@ -329,68 +330,67 @@ 4.2. Country names 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. + sign ("+", ASCII value 0x2B), followed by a country code defined in + [ITU-E164], followed by a dot (".", ASCII value 0x2E), followed by a + sequence of digits representing the telephone number. -4.4. Checksum +4.4. CSV Integrity Check 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. + such as SHA-256 (see, [RFC6234]) MAY be used 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]. + Version 6 [RFC5952]. 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 used to support a cascade replace or cascade delete of records starting from the parent record in Differential and Incremental Deposits (see [I-D.ietf-regext-data-escrow]). - The following is an example of the CSV file definitions for a Sample - object consisting of a parent "sample" CSV File Definition and a - child "sampleStatuses" CSV File Definition. The primary key for the - Sample object is the field that is used as the - foreign key in the "sampleStatuses" CSV File Definition by specifying - the "parent=true" attribute. If a Sample record is updated or - deleted in a Differential or Incremental Deposit, it should cascade - replace the data using the records included in the child - "sampleStatuses" CSV File Definition or cascade delete the existing - records in the child "sampleStatuses" CSV File Definition, - respectively. + The following is an example of the CSV file definitions, using the + element (see Section 4.6.2.1), for a Sample object + consisting of a parent "sample" CSV File Definition and a child + "sampleStatuses" CSV File Definition. The primary key for the Sample + object is the field that is used as the foreign key + in the "sampleStatuses" CSV File Definition by specifying the + "parent=true" attribute. If a Sample record is updated or deleted in + a Differential or Incremental Deposit, it should cascade replace the + data using the records included in the child "sampleStatuses" CSV + File Definition or cascade delete the existing records in the child + "sampleStatuses" CSV File Definition, respectively. ... @@ -470,30 +470,35 @@ encoding Defines the encoding of the CSV file with the default encoding of "UTF-8". 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. + "cksum" attribute, with the default value of "CRC32". If the + value "SHA256" is specified, the SHA-256 algorithm (see, + [RFC6234]) MUST be used to calculate the "cksum" attribute. + Parties receiving and processing data escrow deposits MUST + support CRC32 and SHA-256. If this attribute is present, the + "cksum" attribute MUST also be present. Additional 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 ",". + character with the default separator character of ",". The need for + quoting/escaping of the CSV data could be avoided by choosing a + separator character that is not in the data set of the CSV files. The following is an example of the element for domain name records where the is set as required with isRequired="true". ... @@ -518,21 +523,21 @@ ... The following is example of the "domain-YYYYMMDD.csv" file with one record matching the definition. 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 + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z The following is an example of the element for domain name records. ... @@ -580,25 +585,26 @@ Identifier of the client (registrar) that sponsors the object with type="eppcom:clIDType" and isRequired="true". Identifier of the registrar, defined in Section 5.4, of the client that created the object with type="eppcom:clIDType". Identifier of the client that created the object with type="eppcom:clIDType". Identifier of the registrar, defined in Section 5.4, - of the client that updated the object with type="eppcom:clIDType". - - Identifier of the client that updated the object with + of the client that last updated the object with type="eppcom:clIDType". + Identifier of the client that last updated the object + with type="eppcom:clIDType". + Identifier of the registrar, defined in Section 5.4, of the client that requested the transfer with type="eppcom:clIDType" and isRequired="true". Identifier of the client that requested the transfer with type="eppcom:clIDType". Identifier of the registrar, defined in Section 5.4, of the client that should take or took action with type="eppcom:clIDType" and isRequired="true". @@ -838,23 +844,23 @@ o An OPTIONAL element that contains the date and time of the most recent domain-name-object modification. This element MUST NOT be present if the domain name object has never been modified. o An OPTIONAL element that contains the public key information associated with Domain Name System security (DNSSEC) extensions for the domain name as specified in [RFC5910]. o An OPTIONAL element that contains the date and time of - the most recent domain object successful transfer. This element - MUST NOT be present if the domain name object has never been - transferred. + the most recent domain name object successful transfer. This + element MUST NOT be present if the domain name object has never + been transferred. o An OPTIONAL element that contains the following child elements related to the last transfer request of the domain name object. This element MUST NOT be present if a transfer request for the domain name has never been created. * A element that contains the state of the most recent transfer request. * A element that contains the identifier of the registrar @@ -875,40 +881,40 @@ required or completed response. For a PENDING request, the value identifies the date and time by which a response is required before an automated response action will be taken by 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: + Example of a domain name object: ... xn--exampl-gva.example Dexample1-TEST pt-BR example.example jd1234 sh8013 sh8013 ns1.example.com ns1.example1.example RegistrarX RegistrarX 1999-04-03T22:00:00.0Z - 2015-04-03T22:00:00.0Z + 2025-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: @@ -979,60 +985,62 @@ "domain" element: Registry Object IDentifier (ROID) for the domain name object with isRequired="true". 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". + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with + type="positiveInteger" and "isRequired"="true". The following "rdeCsv" fields, defined in section CSV common field 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. + of the client that created the domain name 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. + of the client that last updated the domain name object. Identifier of the client that last updated the domain name object. UTF8 encoded domain name for the field element. IDN Table Identifier used for the IDN domain name object that MUST match a field element in the "idnLanguage" CSV files, as defined in Section 5.5.2. Registrant contact identifier for the domain name object. Created date and time of the domain name object. Date and time of the last update to the domain name - object. + object. This field MUST NOT be set if the domain name object has + never been modified. Expiration date and time for the domain name object. Date and time of the last transfer for the domain - name object. + name object. This field MUST NOT be set if the domain name object + has never been transferred. Example of a "domain" element. ... ... @@ -1058,30 +1066,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.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 + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z 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 + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z xn--bc123-3ve.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 + 2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z xn--bc321-3ve.example,Dxnabc321-TEST,LANG-1,xn--bc123-3ve.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 + registrarX,clientY,2009-12-03T09:05:00.0Z,2025-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" CSV File Definition (Section 5.1.2.1.1), MUST be used in the "domainContacts" element: @@ -1158,22 +1166,22 @@ type="domain:statusValueType" and isRequired="true". 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. + Domain name object status description + which is free form text describing the rationale for the status. Language of the field. Example of a "domainStatuses" element. ... ... @@ -1267,21 +1275,21 @@ domain2.example,Hns1_domain2_test-TEST domain2.example,Hns2_domain2_test-TEST xn--bc123-3ve.example,Hns1_example_test-TEST xn--bc123-3ve.example,Hns2_example_test-TEST xn--bc321-3ve.example,Hns1_example_test-TEST xn--bc321-3ve.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 + fields and CSV file references used for supporting the domain host 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: Domain name using the delegated host with host and isRequired="true". The following "rdeCsv" fields, defined in section Host CSV model @@ -1385,22 +1393,22 @@ Indicates a child's preference for the number of seconds after signature generation when the parent's signature on the DS information provided by the child will expire with type="secDNS:maxSigLifeType" defined in [RFC5910]. The following "domain" fields, defined for the "domain" CSV File Definition (Section 5.1.2.1.1), MUST be used in the "dnssec" element: - Domain name of the domain object associated with - the DNSSEC record and isRequired="true". + Domain name of the domain name object associated + with the DNSSEC record and isRequired="true". Example of a "dnssec" element with the DS Data Interface of [RFC5910]: ... @@ -1416,22 +1424,23 @@ ... ... Example of the corresponding dnssec-ds-YYYYMMDD.csv file. The file contains two DS records for domain1.example. - domain1.example,604800,12345,3,1,49FD46E6C4B45C55D4AC - domain1.example,604800,12346,3,1,38EC35D5B3A34B44C39B + domain1.example,604800,30730,8,2,91C9B176EB////F1C46F6A55 + domain1.example,604800,61882,8,2,9F8FEAC94B////1272AF09F3 + Example of a "dnssec" element with the Key Data Interface of [RFC5910]: ... @@ -1446,22 +1455,22 @@ ... ... Example of the corresponding dnssec-key-YYYYMMDD.csv file. The file contains two key records for domain1.example. - domain1.example,604800,257,3,1,AQPJ////4Q== - domain1.example,604800,257,3,1,AQPJ////4QQQ + domain1.example,604800,257,3,8,AwEAAZD1+z////G1jqviK8c= + domain1.example,604800,257,3,8,AwEAAbntWP////vwDitt940= 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.6.2.2), MUST be used in the "domainTransfer" @@ -1492,22 +1501,22 @@ Identifier of the client that requested the transfer. Identifier of the client that should take or took action for transfer. The following "csvDomain" fields, defined for the "domain" CSV File Definition (Section 5.1.2.1.1), MUST be used in the "domainTransfer" element: - Domain name of the domain object involved in the - transfer with isRequired="true". + Domain name of the domain name object involved in + the transfer with isRequired="true". Example of a "domainTransfer" element. ... ... @@ -1529,21 +1538,21 @@ ... ... Example of the corresponding domainTransfer-YYYYMMDD.csv file. The file contains one domain transfer record with a pending status. domain1.example,pending,registrarX,clientY, 2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z, - 2016-04-03T22:00:00.0Z + 2025-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 section defines the supported domain name deletes CSV file definition. @@ -1735,42 +1744,45 @@ host object with isRequired="true". The following "rdeCsv" and "csvRegistrar" fields, MAY be used in the "host" element: 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". + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with + type="positiveInteger" and "isRequired"="true". Identifier of the registrar, defined in Section 5.4, - of the client that created the object. + of the client that created the host object. Identifier of the client that created the host object. Identifier of the registrar, defined in Section 5.4, - of the client that updated the object. + of the client that last updated the host object. Identifier of the client that last updated the host object. Date and time that the host object was created. Date and time that the host object was last - updated. + updated. This field MUST NOT be set if the domain name object has + never been modified. - Date and time that the host was last transferred. + Date and time that the host object was last + transferred. This field MUST NOT be set if the domain name object + has never been transferred. Example of a "host" element. ... ... @@ -1834,22 +1846,21 @@ 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.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". + free form text describing the rationale for the status. Language of the field. Example of a "hostStatuses" element. ... ... @@ -2249,47 +2260,49 @@ "contact" element: The Registry Object IDentifier (ROID) for the contact object with isRequired="true". 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". + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with + type="positiveInteger" and "isRequired"="true". The following "rdeCsv" fields, defined in section CSV common field 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. + of the client that created the contact 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. + of the client that last updated the contact object. Identifier of the client that last updated the contact object. Created date and time of the contact object. Date and time of the last update to the contact - object. + object. This field MUST NOT be set if the domain name object has + never been modified. Date and time of the last transfer for the contact - object. + object. This field MUST NOT be set if the domain name object has + never been transferred. Example of a "contact" element. ... ... @@ -2360,21 +2373,21 @@ 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". + isRequired="true" and parent="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.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. @@ -2428,65 +2441,66 @@ 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.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 + and isRequired="true". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in - section Section 4.6.3. + Section 4.6.3. Contains the 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.6.3. + "0" for the first line and incrementing for each line up to index + "2" for the third line. An OPTIONAL "isLoc" attribute is used to + indicate the localized or internationalized form as defined in + 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.6.3. + "isLoc" attribute is used to indicate the localized or + internationalized form as defined in 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.6.3. + attribute is used to indicate the localized or internationalized + form as defined in 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.6.3. + An OPTIONAL "isLoc" attribute is used to indicate the localized or + internationalized form as defined in 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.6.3. + is used to indicate the localized or internationalized form as + defined in Section 4.6.3. Contains the contact's postal code with - type="contact:pcType". An OPTIONAL "isLoc" attribute to used to + type="contact:pcType". An OPTIONAL "isLoc" attribute is used to indicate the localized or internationalized form as defined in - section Section 4.6.3. + 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". + object with isRequired="true" and parent="true". Example of a "contactPostal" element. ... ... @@ -2776,22 +2790,22 @@ The element contains the following child elements: o An element that contains the Registry-unique identifier of the registrar object. This has a superordinate relationship to a subordinate , or of domain, contact and host objects. o An element that contains the name of the registrar. - o An OPTIONAL element that contains the ID assigned by - ICANN. + o An OPTIONAL element that contains the Globally Unique + Registrar Identifier (GURID) assigned by ICANN. o An OPTIONAL element that contains the operational status of the registrar. Possible values are: ok, readonly and terminated. o One or two OPTIONAL elements that contain postal- address information. Two elements are provided so that address information can be provided in both internationalized and localized forms; a "type" attribute is used to identify the two forms. If an internationalized form (type="int") is provided, @@ -2836,31 +2850,30 @@ registrar WHOIS server listening on TCP port 43 as specified in [RFC3912]. * An OPTIONAL element that contains the name of the registrar WHOIS server listening on TCP port 80/443. o An OPTIONAL element that contains the date and time of registrar-object creation. o An OPTIONAL element that contains the date and time of - the most recent RDE registrar-object modification. This element - MUST NOT be present if the rdeRegistrar object has never been - modified. + the most recent registrar-object modification. This element MUST + NOT be present if the registrar-object has never been modified. - Example of object: + Example of a object: ... RegistrarX Registrar X - 123 + 8 ok 123 Example Dr. Suite 100 Dulles VA 20166-6503 US @@ -2934,23 +2947,23 @@ references used for the registrar object records. The following "csvRegistrar" field elements MUST be used in the "registrar" element: or A choice of: Contains the server-unique registrar identifier with type="eppcom:clIDType" and isRequired="true". - Contains the ID assigned by ICANN with - type="positiveInteger". The attribute "isRequired" MUST equal - "true". + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with + type="positiveInteger" and "isRequired"="true". Contains the name of the registrar with type="normalizedString" and isRequired="true". The following field elements MAY be used in the "registrar" element: Contains the status of the registrar with type="csvRegistrar:statusValueType". @@ -2963,21 +2976,22 @@ Contains the Whois URL of the registrar with type="anyURI". The following "rdeCsv" fields, defined in section CSV common field 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. + object. This field MUST NOT be set if the domain name object has + never been modified. 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 @@ -3044,34 +3058,24 @@ registrar-YYYYMMDD.csv ... ... - Example of the registrar-YYYYMMDD.csv file. The file contains three - registrar records. + Example of the registrar-YYYYMMDD.csv file. The file contains one + registrar record. - registrarX,"Example Inc.",1234,ok,"123 Example Dr.", - "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, - +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.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.", + registrarX,"Example Inc.",8,ok,"123 Example Dr.", "Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234, +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 @@ -3083,21 +3087,22 @@ 5.4.2.2.1. "registrar" Deletes CSV File Definition The following "csvRegistrar" field elements MUST be used in the deletes "registrar" element: or A choice of: Contains the server-unique registrar identifier with type="eppcom:clIDType" and isRequired="true". - Contains the ID assigned by ICANN with + Contains the Globally Unique Registrar + Identifier (GURID) assigned by ICANN with type="positiveInteger". The attribute "isRequired" MUST equal "true". Example of a "registrar" element. ... ... @@ -3193,22 +3198,23 @@ 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". + used for field in the "domain" CSV File + Definition Section 5.1.2.1.1 files. The attribute "isRequired" + MUST equal "true". Example of a "idnLanguage" element. ... ... @@ -3328,30 +3334,33 @@ name used to generate the IDN variant. o A element that indicates the state of the NNDN: blocked, withheld or mirrored. * If an NNDN is considered undesirable for registration (i.e., unavailable for allocation to anyone), then the NNDN will be tagged as "blocked". * If an NNDN is considered a potential registration of a domain - object for a registrant, then the NNDN will be tagged as + name object for a registrant, then the NNDN will be tagged as "withheld". This status is only used when the NNDN is used for an IDN variant. * If an NNDN is considered a mirrored IDN variant of a domain - object, then the NNDN will be tagged as "mirrored". A + name object, then the NNDN will be tagged as "mirrored". A mirroringNS attribute is used to specify if the mirrored IDN - variant use the NS mirror mechanism. The default value of - mirroringNS is true. If another mechanism such as DNAME is - used, the value of mirroringNS attribute MUST be false. + variant uses the NS mirror mechanism, meaning that the + activated variant domain name (i.e., NNDN) is delegated in the + DNS using the same NS records as in the . The + default value of 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 an object: ... xn--exampl-gva.example pt-BR @@ -3514,22 +3523,22 @@ xn--bc456-3ve.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 - a certain point in time (watermark). + registry supports EPP. A maximum of one EPP Parameters Object MUST + exist at a certain point in time (watermark). The syntax and content of the children elements is as explained in section 2.4 of [RFC5730]. The children of the are as follows: o One or more elements that indicate the EPP versions supported by the registry. o One or more elements that indicate the identifiers of the text response languages supported by the registry's EPP server. @@ -3590,22 +3599,22 @@ 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 - . + o that defines the XPath (see, [W3C.REC-xpath-31-20170321]) + of the element referenced by . Example of object: ... ... 5.9. Header Object @@ -3784,32 +3793,22 @@ 3. Adding new escrowed objects using the and elements. 4. Providing the XML schemas to third parties that require them to validate the escrow deposits. 8. Data escrow agent extended verification process A Data Escrow Agent SHOULD perform an extended verification process - that starts by creating a dataset to be tested. - - o If a Full Deposit is to be tested, the Full Deposit is the - dataset. - - o If an Incremental Deposit is to be tested, the dataset is created - by using the Incremental Deposit plus the last previous Full - Deposit. - - o If a Differential Deposit is to be tested, the dataset is created - by using the Differential Deposit plus all the required deposits - leading to the last previous Full Deposit. + that starts by creating a dataset to be tested by following section + 5.2 in [I-D.ietf-regext-data-escrow]. The following are the minimum suggested tests on the dataset: o Validate the escrow deposits using the definition agreed with the registry. * In the case of the XML model, the contents of the escrow deposits MUST be validated using the XML schemas of the profile. @@ -3833,454 +3832,487 @@ one EPP Parameters Object MUST be present. o The watermark is not in the future. 9. Formal Syntax This standard is specified in XML Schema notation. The formal syntax presented here is a complete schema representation suitable for automated validation. - The BEGIN and END tags are not part of the schema; they are used to - note the beginning and ending of the schema for URI registration - purposes. + The and tags are not part of the schema; + they are used to note the beginning and ending of the schema for URI + registration purposes. 9.1. RDE CSV Schema - BEGIN + - - - - Registry Data Escrow Comma-Seperated Values (CSV) + Registry Data Escrow Comma-Separated Values (CSV) - - - + - - + + - - + + - - - - - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - + - - + - - - + - - END + 9.2. RDE Domain Object - BEGIN + - - Registry Data Escrow Domain provisioning schema - + substitutionGroup="rde:content" + abstract="true" /> - + type="eppcom:labelType" + minOccurs="0" /> + type="rdeIDN:idType" + minOccurs="0" /> + type="eppcom:labelType" + minOccurs="0" /> + type="domain:statusType" + maxOccurs="11" /> + type="eppcom:clIDType" + minOccurs="0" /> + minOccurs="0" + maxOccurs="unbounded" /> + type="domain:nsType" + minOccurs="0" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + + type="secDNS:dsOrKeyType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> - @@ -4367,44 +4411,44 @@ type="eppcom:trStatusType"/> + type="dateTime" + minOccurs="0" /> - - END + 9.3. CSV Domain Object - BEGIN + - @@ -4401,217 +4445,210 @@ - - Domain Name Comma-Separated Values (CSV) Object - - - - + - - - - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - END + 9.4. RDE Host Object - BEGIN + - - Registry Data Escrow Host provisioning schema - - - - + + - + type="host:statusType" + maxOccurs="7" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> - + - + - END + 9.5. CSV Host Object - BEGIN + - - - Host Comma-Separated Values (CSV) Object - - - + - - - - + - - - - - - - + - - - - - - - END + 9.6. RDE Contact Object - BEGIN + - - Registry Data Escrow contact provisioning schema - + substitutionGroup="rde:content" + abstract="true" /> - + type="contact:statusType" + maxOccurs="7" /> + type="contact:postalInfoType" + maxOccurs="2" /> + type="contact:e164Type" + minOccurs="0" /> + type="contact:e164Type" + minOccurs="0" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="rdeDnrdCommon:rrType" + minOccurs="0" /> + + type="dateTime" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="rdeContact:transferDataType" + minOccurs="0" /> + type="contact:discloseType" + minOccurs="0" /> - - - - - - + + + + + - - END + 9.7. CSV Contact Object - BEGIN + - - - Contact Comma-Separated Values (CSV) Object - - - + - - - - + - - - - - - - - - - - - - - - - - - - - + - - - + - - - - - - - - - - - - - - - + - - - - + - - - - - - - - - - - - - - - - - - END + 9.8. RDE Registrar Object - BEGIN + - - Registry Data Escrow registrar provisioning schema - + substitutionGroup="rde:content" + abstract="true" /> - - + type="positiveInteger" + minOccurs="0" /> + type="rdeRegistrar:statusType" + minOccurs="0" /> + minOccurs="0" + maxOccurs="2" /> + type="contact:e164Type" + minOccurs="0" /> + type="contact:e164Type" + minOccurs="0" /> + type="eppcom:minTokenType" + minOccurs="0" /> + type="anyURI" + minOccurs="0" /> + type="rdeRegistrar:whoisInfoType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> - @@ -5217,55 +5301,53 @@ - - - + minOccurs="0" + maxOccurs="3" /> + type="rdeRegistrar:pcType" + minOccurs="0" /> - @@ -5263,695 +5345,684 @@ - - - + type="eppcom:labelType" + minOccurs="0" /> + type="anyURI" + minOccurs="0" /> - - END + 9.9. CSV Registrar Object - BEGIN + - - - Registar Comma-Separated Values (CSV) Object - - - - + - - - - + - - - - - - - + - - - - - - - - + + - - - - END + 9.10. RDE IDN Table Reference Objects - BEGIN + - - Registry Data Escrow IDN provisioning schema - - - - - - - + + + - + - - + - - - END + 9.11. CSV IDN Language Object - BEGIN + - - - IDN Language Comma-Separated Values (CSV) Object - + - - - + - - - - + - END + 9.12. EPP Parameters Object - BEGIN + - - Registry Data Escrow EPP Parameters schema - - + substitutionGroup="rde:content" + abstract="true" /> - + type="language" + maxOccurs="unbounded" /> + type="anyURI" + maxOccurs="unbounded" /> - END + 9.13. NNDN Object - BEGIN + - - Registry Data Escrow NNDN provisioning schema - - - - + + - + type="eppcom:labelType" + minOccurs="0" /> + type="rdeIDN:idType" + minOccurs="0" /> + type="eppcom:labelType" + minOccurs="0" /> + type="dateTime" + minOccurs="0" /> - - + type="boolean" + default="true" /> - - END + 9.14. CSV NNDN Object - BEGIN + - - - NNDN (NNDN's not domain name) (CSV) Object - - - - + - - - + - - - + - - - - - - - - - - END + 9.15. Policy Object - - BEGIN + - Registry Data Escrow Policy schema - - - - - + + - END + 9.16. Header Object - BEGIN + - - Data Escrow Deposit Header schema - - - - - - - - - - - + + + + - - - - + + + - - END + 9.17. DNRD Common Objects - BEGIN + - - Data Escrow Deposit Common Objects schema - - + - - END + 10. Internationalization Considerations Data Escrow deposits are represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED. 11. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas - conforming to a registry mechanism described in [RFC3688]. Fourteen - URI assignments have been registered by the IANA. + conforming to a registry mechanism described in [RFC3688]. The + following URI assignments is requested of IANA. Registration request for the RDE CSV namespace: URI: urn:ietf:params:xml:ns:rdeCsv-1.0 - Registrant Contact: IESG + Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE CSV XML schema: URI: urn:ietf:params:xml:schema:rdeCsv-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.1 of this document. + See Section 9.1 of this document. Registration request for the RDE domain namespace: URI: urn:ietf:params:xml:ns:rdeDomain-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -5959,21 +6030,21 @@ Registration request for the RDE domain XML schema: URI: urn:ietf:params:xml:schema:rdeDomain-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.2 of this document. + See Section 9.2 of this document. Registration request for the CSV domain namespace: URI: urn:ietf:params:xml:ns:csvDomain-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -5981,21 +6052,21 @@ Registration request for the CSV domain XML schema: URI: urn:ietf:params:xml:schema:csvDomain-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.3 of this document. + See Section 9.3 of this document. Registration request for the RDE host namespace: URI: urn:ietf:params:xml:ns:rdeHost-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6003,21 +6074,21 @@ Registration request for the RDE host XML schema: URI: urn:ietf:params:xml:schema:rdeHost-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.4 of this document. + See Section 9.4 of this document. Registration request for the CSV host namespace: URI: urn:ietf:params:xml:ns:csvHost-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6019,27 +6090,26 @@ Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV host XML schema: URI: urn:ietf:params:xml:schema:csvHost-1.0 - Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.5 of this document. + See Section 9.5 of this document. Registration request for the RDE contact namespace: URI: urn:ietf:params:xml:ns:rdeContact-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6047,21 +6117,21 @@ Registration request for the RDE contact XML schema: URI: urn:ietf:params:xml:schema:rdeContact-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.6 of this document. + See Section 9.6 of this document. Registration request for the CSV contact namespace: URI: urn:ietf:params:xml:ns:csvContact-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6065,24 +6135,25 @@ Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the CSV contact XML schema: URI: urn:ietf:params:xml:schema:csvContact-1.0 Registrant Contact: IESG + Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.7 of this document. + See Section 9.7 of this document. Registration request for the RDE registrar namespace: URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6090,21 +6161,21 @@ Registration request for the RDE registrar XML schema: URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.8 of this document. + See Section 9.8 of this document. Registration request for the CSV registrar namespace: URI: urn:ietf:params:xml:ns:csvRegistrar-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6112,21 +6183,21 @@ Registration request for the CSV registrar XML schema: URI: urn:ietf:params:xml:schema:csvRegistrar-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.9 of this document. + See Section 9.9 of this document. Registration request for the RDE IDN namespace: URI: urn:ietf:params:xml:ns:rdeIDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6134,21 +6205,21 @@ Registration request for the RDE IDN XML schema: URI: urn:ietf:params:xml:schema:rdeIDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.10 of this document. + See Section 9.10 of this document. Registration request for the CSV IDN namespace: URI: urn:ietf:params:xml:ns:csvIDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6156,42 +6227,42 @@ Registration request for the CSV IDN XML schema: URI: urn:ietf:params:xml:schema:csvIDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.11 of this document. + See Section 9.11 of this document. Registration request for the RDE EPP parameters namespace: URI: urn:ietf:params:xml:ns:rdeEppParams-1.0 - Registrant Contact: IESG + Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE EPP parameters XML schema: URI: urn:ietf:params:xml:schema:rdeEppParams-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.12 of this document. + See Section 9.12 of this document. Registration request for the RDE NNDN namespace: URI: urn:ietf:params:xml:ns:rdeNNDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6199,21 +6270,21 @@ Registration request for the RDE NNDN XML schema: URI: urn:ietf:params:xml:schema:rdeNNDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.13 of this document. + See Section 9.13 of this document. Registration request for the CSV NNDN namespace: URI: urn:ietf:params:xml:ns:csvNNDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6221,21 +6292,21 @@ Registration request for the CSV NNDN XML schema: URI: urn:ietf:params:xml:schema:csvNNDN-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.14 of this document. + See Section 9.14 of this document. Registration request for the RDE Policy namespace: URI: urn:ietf:params:xml:ns:rdePolicy-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6243,21 +6314,21 @@ Registration request for the RDE Policy XML schema: URI: urn:ietf:params:xml:ns:rdePolicy-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.15 of this document. + See Section 9.15 of this document. Registration request for the RDE Header namespace: URI: urn:ietf:params:xml:ns:rdeHeader-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6259,27 +6330,26 @@ Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RDE Header XML schema: URI: urn:ietf:params:xml:ns:rdeHeader-1.0 - Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.16 of this document. + See Section 9.16 of this document. Registration request for the RDE Common Objects namespace: URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. @@ -6287,21 +6357,21 @@ Registration request for the RDE Common Objects XML schema: URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0 Registrant Contact: IESG Note to RFC Editor: Please remove the email address from the RFC after IANA records it. - See section Section 9.17 of this document. + See Section 9.17 of this document. 12. Implementation Status Note to RFC Editor: Please remove this section and the reference to RFC 7942 [RFC7942] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is @@ -6334,21 +6404,21 @@ specification. ICANN receives on a weekly basis per gTLD, from more than 1,200 gTLD registries, a Bulk Registration Data Access file that also complies with this specification. In addition, ICANN is aware of Registry Service Provider transitions using data files that conform to this specification. Level of maturity: production. Coverage: all aspects of this specification are implemented. - Version compatibility: versions 03 - 08 are known to be implemented. + Version compatibility: versions 03 - 09 are known to be implemented. Contact: gustavo.lozano@icann.org URL: https://www.icann.org/resources/pages/registries/registries- agreements-en 13. Security Considerations This specification does not define the security mechanisms to be used in the transmission of the data escrow deposits, since it only @@ -6359,55 +6429,65 @@ Depending on local policies, some elements, or, most likely, the whole deposit will be considered confidential. As such, the parties SHOULD take all the necessary precautions such as encrypting the data at rest and in transit to avoid inadvertent disclosure of private data. Regardless of the precautions taken by the parties regarding data at rest and in transit, authentication credentials MUST NOT be escrowed. Authentication of the parties passing data escrow deposit files is also of the utmost importance. The escrow agent MUST properly - authenticate the identity of the registry before accepting data - escrow deposits. In a similar manner, the registry MUST authenticate - the identity of the escrow agent before submitting any data. + authenticate the registry's identity before accepting data escrow + deposits. The registry MUST authenticate the escrow agent's identity + before submitting any data, and the data escrow agent MUST + authenticate the identity of the party receiving the data escrow + deposits for the purposes deemed appropriate. Additionally, the registry and the escrow agent MUST use integrity checking mechanisms to ensure the data transmitted is what the source - intended. Validation of the contents by the escrow agent is - RECOMMENDED to ensure not only that the file was transmitted - correctly from the registry, but also that the contents are - "meaningful". + intended. Validation of the contents by the parties is RECOMMENDED + to ensure that the file was transmitted correctly from the registry + or escrow agent and that the contents are "meaningful". + + A few elements in this specification contain URLs, the use of HTTP + over TLS (Transport Layer Security), [RFC2818] is RECOMMENDED on the + URLs. + + The various data structures in the document include a few places that + have internal redundancy, and if the values become inconsistent there + can be harmful consequences, such as different entities using + different fields as their reference. Note: if Transport Layer Security (TLS) is used when providing an - escrow services, the recommendations in [RFC7525] MUST be - implemented. + escrow services, the recommendations in [BCP195] MUST be implemented. 14. Privacy Considerations This specification defines a format that may be used to escrow personal data. The process of data escrow is governed by a legal document agreed by the parties, and such legal document must ensure that privacy-sensitive and/or personal data receives the required protection. 15. Acknowledgments Parts of this document are based on EPP [RFC5730] and related RFCs by Scott Hollenbeck. Special suggestions that have been incorporated into this document were provided by Edward Lewis, Jaap Akkerhuis, Lawrence Conroy, Marc Groeneweg, Michael Young, Chris Wright, Patrick Mevzek, Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer, Warren Kumari, Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew Sullivan, Hiro Hotta, Christopher Browne, Daniel Kalchev, David Conrad, James - Mitchell, Francisco Obispo, Bhadresh Modi and Alexander Mayrhofer. + Mitchell, Francisco Obispo, Bhadresh Modi, Alexander Mayrhofer and + Benjamin Kaduk. Shoji Noguchi and Francisco Arias participated as co-authors until version 05 providing invaluable support for this document. 16. Change History [[RFC Editor: Please remove this section.]] 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 to - dnrd-objects-mapping-00 @@ -6748,21 +6828,21 @@ 1. draft-ietf-regext-data-escrow (version 04) is now referenced from the I-D repository. 2. The example in idnLanguage CSV file definition updated to use the sep attribute. 3. The reference in the example in hostAddresses CSV file definition was updated. - 4. Moved [RFC0791] and [RFC4291] to the Normative References + 4. Moved [RFC0791] and [RFC5952] to the Normative References section. 16.18. Changes REGEXT 05 to REGEXT 06 1. Changes based on the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/ nA8eTYIrXJ44_6ullQlRLW6T74s 16.19. Changes REGEXT 06 to REGEXT 07 @@ -6783,20 +6863,50 @@ 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 +16.22. Changes REGEXT 09 to REGEXT 10 + + 1. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + tmoKLAV6jhh2zp4JczjeWdr_jJE + + 2. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/m7gyDTjHuRqIQCuKMHF- + OLSS99k + + 3. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/ + regext/3Acx5KHfeUdxZbx6A7zgoZHxIto + + 4. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/ + regext/3Acx5KHfeUdxZbx6A7zgoZHxIto + + 5. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/ + regext/7JiP2fzOr8KCnzI2rwoP-_KlxZY + + 6. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/dbuyW5YTYj4VcFHUQYC- + D8OMv_g + + 7. Changes based on the feedback provided here: + https://mailarchive.ietf.org/arch/msg/regext/ + ExUZenwC81ZQe9x24-8IKT_FWm8 + 17. Example of a Full Deposit using the XML model Example of a Full Deposit using the XML model: jd1234 sh8013 sh8013 ns1.example.com ns1.example1.example RegistrarX RegistrarX 1999-04-03T22:00:00.0Z - 2015-04-03T22:00:00.0Z + 2025-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 + 2025-04-03T22:00:00.0Z ns1.example1.example Hns1_example_test-TEST 192.0.2.2 192.0.2.29 @@ -6946,21 +7057,21 @@ RegistrarX Registrar X - 123 + 8 ok 123 Example Dr. Suite 100 Dulles VA 20166-6503 @@ -8076,22 +8185,29 @@ 21. References + 21.1. Normative References + [BCP195] 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, . + [I-D.ietf-regext-data-escrow] Lozano, G., "Registry Data Escrow Specification", draft- ietf-regext-data-escrow-10 (work in progress), June 2020. [ISO-3166-1] 3166, I. S., "Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes", ISO Standard 3166, November 2006. [ITU-E164] @@ -8110,24 +8226,20 @@ [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)", RFC 3915, DOI 10.17487/RFC3915, September 2004, . - [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing - Architecture", RFC 4291, DOI 10.17487/RFC4291, February - 2006, . - [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) @@ -8142,20 +8254,30 @@ Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [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, . + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + + [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, + . + [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- @@ -8172,60 +8294,58 @@ 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, . + [W3C.REC-xpath-31-20170321] + Robie, J., Dyck, M., and J. Spiegel, "XML Path Language + (XPath) 3.1", March 2017, + . + 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, . + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + [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, . [variantTLDsReport] Internet Corporation for Assigned Names and Numbers (ICANN), "A Study of Issues Related to the Management of IDN Variant TLDs", February 2012,