draft-ietf-regext-dnrd-objects-mapping-08.txt   draft-ietf-regext-dnrd-objects-mapping-09.txt 
Network Working Group G. Lozano Network Working Group G. Lozano
Internet-Draft ICANN Internet-Draft ICANN
Intended status: Standards Track J. Gould Intended status: Standards Track J. Gould
Expires: December 5, 2020 C. Thippeswamy Expires: February 13, 2021 C. Thippeswamy
VeriSign VeriSign
Jun 3, 2020 Aug 12, 2020
Domain Name Registration Data (DNRD) Objects Mapping Domain Name Registration Data (DNRD) Objects Mapping
draft-ietf-regext-dnrd-objects-mapping-08 draft-ietf-regext-dnrd-objects-mapping-09
Abstract Abstract
This document specifies the format, contents and semantics of Domain This document specifies the format, contents and semantics of Domain
Name Registration Data (DNRD) Escrow deposits for a Domain Name Name Registration Data (DNRD) Escrow deposits for a Domain Name
Registry. Registry.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 5, 2020. This Internet-Draft will expire on February 13, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Conventions Used in This Document . . . . . . . . . . . . . . 6 3.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 6 4. Conventions Used in This Document . . . . . . . . . . . . . . 7
4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 7 4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 7
4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 7 4.4. Checksum . . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 7 4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 8
4.6. Conventions applicable to the CSV Model . . . . . . . . . 7 4.6. Conventions applicable to the CSV Model . . . . . . . . . 8
5. Object Description . . . . . . . . . . . . . . . . . . . . . 15 5. Object Description . . . . . . . . . . . . . . . . . . . . . 16
5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 15 5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 16
5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 34 5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 44 5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 45
5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 62 5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 63
5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 70 5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 71
5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 74 5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 75
5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 79 5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 80
5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 81 5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 82
5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 81 5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 82
5.10. DNRD Common Objects Collection . . . . . . . . . . . . . 84 5.10. DNRD Common Objects Collection . . . . . . . . . . . . . 85
6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 84 6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 85
7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
8. Data escrow agent extended verification process . . . . . . . 85 8. Data escrow agent extended verification process . . . . . . . 86
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 86 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 87
9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 87 9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 88
9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 96 9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 97
9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 98 9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 99
9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 102 9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 103
9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 104 9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 105
9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 106 9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 107
9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 108 9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 109
9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 114 9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 115
9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 117 9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 118
9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 120 9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 121
9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 121 9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 122
9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 123 9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 124
9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 124 9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 125
9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 126 9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 127
9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 128 9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 129
9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 128 9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 129
9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 130 9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 131
10. Internationalization Considerations . . . . . . . . . . . . . 130 10. Internationalization Considerations . . . . . . . . . . . . . 131
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 131
12. Implementation Status . . . . . . . . . . . . . . . . . . . . 138 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 139
12.1. Implementation in the gTLD space . . . . . . . . . . . . 139 12.1. Implementation in the gTLD space . . . . . . . . . . . . 140
13. Security Considerations . . . . . . . . . . . . . . . . . . . 139 13. Security Considerations . . . . . . . . . . . . . . . . . . . 140
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 140 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 141
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 140 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 141
16. Change History . . . . . . . . . . . . . . . . . . . . . . . 141 16. Change History . . . . . . . . . . . . . . . . . . . . . . . 142
16.1. Changes from draft-arias-noguchi-registry-data-escrow-02 16.1. Changes from draft-arias-noguchi-registry-data-escrow-02
to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 141 to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 142
16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 141 16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 142
16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 141 16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 142
16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 142 16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 143
16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 142 16.5. Changes from 03 to 04 . . . . . . . . . . . . . . . . . 143
16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 143 16.6. Changes from 04 to 05 . . . . . . . . . . . . . . . . . 144
16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 144 16.7. Changes from 05 to 06 . . . . . . . . . . . . . . . . . 145
16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 144 16.8. Changes from 06 to 07 . . . . . . . . . . . . . . . . . 145
16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 145 16.9. Changes from 07 to 08 . . . . . . . . . . . . . . . . . 146
16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 145 16.10. Changes from 08 to 09 . . . . . . . . . . . . . . . . . 146
16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 145 16.11. Changes from 09 to 10 . . . . . . . . . . . . . . . . . 146
16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 145 16.12. Changes from 10 to REGEXT 00 . . . . . . . . . . . . . . 146
16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 145 16.13. Changes REGEXT 00 to REGEXT 01 . . . . . . . . . . . . . 146
16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 145 16.14. Changes REGEXT 01 to REGEXT 02 . . . . . . . . . . . . . 146
16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 147 16.15. Changes REGEXT 02 to REGEXT 03 . . . . . . . . . . . . . 148
16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 147 16.16. Changes REGEXT 03 to REGEXT 04 . . . . . . . . . . . . . 148
16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 148 16.17. Changes REGEXT 04 to REGEXT 05 . . . . . . . . . . . . . 149
16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 148 16.18. Changes REGEXT 05 to REGEXT 06 . . . . . . . . . . . . . 149
16.19. Changes REGEXT 06 to REGEXT 07 . . . . . . . . . . . . . 148 16.19. Changes REGEXT 06 to REGEXT 07 . . . . . . . . . . . . . 149
16.20. Changes REGEXT 07 to REGEXT 08 . . . . . . . . . . . . . 148 16.20. Changes REGEXT 07 to REGEXT 08 . . . . . . . . . . . . . 149
17. Example of a Full Deposit using the XML model . . . . . . . . 149 16.21. Changes REGEXT 08 to REGEXT 09 . . . . . . . . . . . . . 150
18. Example of Differential Deposit using the XML model . . . . . 154 17. Example of a Full Deposit using the XML model . . . . . . . . 150
19. Example of a Full Deposit using the CSV model . . . . . . . . 156 18. Example of Differential Deposit using the XML model . . . . . 155
20. Example of Differential Deposit using the CSV model . . . . . 165 19. Example of a Full Deposit using the CSV model . . . . . . . . 157
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 175 20. Example of Differential Deposit using the CSV model . . . . . 166
21.1. Normative References . . . . . . . . . . . . . . . . . . 175 21. References . . . . . . . . . . . . . . . . . . . . . . . . . 176
21.2. Informative References . . . . . . . . . . . . . . . . . 177 21.1. Normative References . . . . . . . . . . . . . . . . . . 177
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 178 21.2. Informative References . . . . . . . . . . . . . . . . . 179
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 180
1. Introduction 1. Introduction
Registry Data Escrow is the process by which a registry periodically Registry Data Escrow is the process by which a registry periodically
submits data deposits to a third-party called an escrow agent. These submits data deposits to a third-party called an escrow agent. These
deposits comprise the minimum data needed by a third-party to resume deposits comprise the minimum data needed by a third-party to resume
operations if the registry cannot function and is unable or unwilling operations if the registry cannot function and is unable or unwilling
to facilitate an orderly transfer of service. For example, for a to facilitate an orderly transfer of service. For example, for a
domain name registry or registrar, the data to be deposited would domain name registry or registrar, the data to be deposited would
include all the objects related to registered domain names, e.g., include all the objects related to registered domain names, e.g.,
skipping to change at page 4, line 41 skipping to change at page 4, line 41
o Contact: Individual or organization social information provisioned o Contact: Individual or organization social information provisioned
in a Domain Name Registry using the EPP contact mapping [RFC5733]. in a Domain Name Registry using the EPP contact mapping [RFC5733].
The attributes defined in the EPP contact mapping [RFC5733] are The attributes defined in the EPP contact mapping [RFC5733] are
fully supported by this document. fully supported by this document.
o Registrar: The organization that sponsors objects like domains, o Registrar: The organization that sponsors objects like domains,
hosts, and contacts in a Domain Name Registry. hosts, and contacts in a Domain Name Registry.
o NNDN (NNDN's not domain name): Domain Name Registries may maintain o NNDN (NNDN's not domain name): Domain Name Registries may maintain
domain names without their being persisted as domain objects in domain names without being persisted as domain objects in the
the registry system, for example, a list of reserved names not registry system, for example, a list of reserved names not
available for registration. The NNDN is a lightweight domain-like available for registration. The NNDN is a lightweight domain-like
object that is used to escrow domain names not maintained as object that is used to escrow domain names not maintained as
domain name objects. domain name objects.
This document defines the following pseudo-objects: This document defines the following pseudo-objects:
o IDN Table Reference: Internationalized Domain Names (IDN) included o IDN Table Reference: Internationalized Domain Names (IDN) included
in the Domain Object Data Escrow include references to the IDN in the Domain Object Data Escrow include references to the IDN
Table and Policy used in IDN registration. Table and Policy used in IDN registration.
skipping to change at page 5, line 30 skipping to change at page 5, line 30
This document defines two different models that can be used to This document defines two different models that can be used to
deposit data escrow objects: XML and CSV. deposit data escrow objects: XML and CSV.
The data escrow deposit MAY contain a mix of both models but an The data escrow deposit MAY contain a mix of both models but an
object MUST be escrowed only in one model. object MUST be escrowed only in one model.
This document does not suggest the use of a particular model, and This document does not suggest the use of a particular model, and
both are equivalent. A Domain Name Registry may choose the model both are equivalent. A Domain Name Registry may choose the model
that is more appropriate for the peculiarities of its systems. For that is more appropriate for the peculiarities of its systems. For
example, a registry may use the CSV-export functionality of the RDBMS example, a registry may use the CSV-export functionality of the
for escrow; therefore, the CSV model may be more appropriate. Relational Database Management System (RDBMS) for escrow; therefore,
Another registry may use the code developed for EPP to implement the CSV model may be more appropriate. Another registry may use the
escrow. code developed for EPP to implement escrow.
2.1. XML Model 2.1. XML Model
XML: The XML model includes all the deposit information (meta-data XML: The XML model includes all the deposit information (meta-data
and data) in an XML document. The definition of the XML format is and data) in an XML document. The definition of the XML format is
fully defined in the XML schemas. As a convention, the objects fully defined in the XML schemas. As a convention, the objects
represented using the XML model are referenced using RDE and an XML represented using the XML model are referenced using RDE and an XML
namespace that is prefixed with "rde". For example, the Domain Name namespace that is prefixed with "rde". For example, the Domain Name
object represented using the XML model can be referred to as the RDE object represented using the XML model can be referred to as the RDE
Domain Name with the XML namespace including rdeDomain Domain Name with the XML namespace including rdeDomain
skipping to change at page 6, line 15 skipping to change at page 6, line 15
namespace including csvDomain (urn:ietf:params:xml:ns:csvDomain-1.0). namespace including csvDomain (urn:ietf:params:xml:ns:csvDomain-1.0).
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
REGISTRY. In the context of this draft the definition will be 3.1. Glossary
overloaded (from the definition in the base protocol) to indicate an
organization providing Registry Services for a REGISTRY-CLASS DOMAIN
NAME.
REGISTRY-CLASS DOMAIN NAME (RCDN): Refers to a top-level domain (TLD) In the following section, the most common terms are briefly
or any other domain name at any level in the DNS tree for which a explained:
Registry (either directly or through an affiliate company) provides
Registry Services for other organizations or individuals. For
example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.
REGISTRY SERVICES. Services offered by the Registry critical to the o Allocated: a status of some label with respect to a zone, whereby
following tasks: the provisioning of domain names on receipt of the label is associated administratively to some entity that has
requests and data from registrars; responding to registrar queries requested the label. This term (and its cognates "allocation" and
for status information relating to the DNS servers for the RCDN; "to allocate") may represent the first step on the way to
dissemination of RCDN zone files; operation of the Registry DNS delegation in the DNS.
servers; responding to queries for contact and other information
concerning DNS registrations in the RCDN; and any other products or
services that only a Registry is capable of providing, by reason of
its designation as the Registry. Typical examples of Registry
Services are DNS resolution for the RCDN, WHOIS and EPP.
ALLOCATED. A status of some label with respect to a zone, whereby o Comma-Separated Values (CSV), see [RFC4180].
the label is associated administratively to some entity that has
requested the label. This term (and its cognates "allocation" and o Domain name: see definition of Domain name in [RFC8499].
"to allocate") may represent the first step on the way to delegation
in the DNS. o Extensible Provisioning Protocol (EPP), see definition of the
Extensible Provisioning Protocol in [RFC8499].
o Fully-Qualified Domain Name (FQDN), see definition of FQDN in
[RFC8499].
o Internationalized Domain Name (IDN), see definition of
Internationalized Domain Name in [RFC8499].
o Label: see definition of Label in [RFC8499].
o Registrant: see definition of Registrant in [RFC8499].
o Registrar: see definition of Registrar in [RFC8499].
o Registry: see definition of Registry in [RFC8499].
o Registry-class domain name (RCDN): refers to a top-level domain
(TLD) or any other domain name at any level in the DNS tree for
which a Registry (either directly or through an affiliate company)
provides Registry Services for other organizations or individuals.
For example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.
o Registry Data Escrow (RDE): registry data escrow is the process by
which a registry periodically submits data deposits to a third-
party called an escrow agent. These deposits comprise the minimum
data needed by a third-party to resume operations if the registry
cannot function and is unable or unwilling to facilitate an
orderly transfer of service.
o Registry services: services offered by the Registry critical to
the following tasks: the provisioning of domain names on receipt
of requests and data from registrars; responding to registrar
queries for status information relating to the DNS servers for the
RCDN; dissemination of RCDN zone files; operation of the Registry
DNS servers; responding to queries for contact and other
information concerning DNS registrations in the RCDN; and any
other products or services that only a Registry is capable of
providing, by reason of its designation as the Registry. Typical
examples of Registry Services are DNS resolution for the RCDN,
WHOIS and EPP.
o SRS: Shared Registration System, see also
[ICANN-GTLD-AGB-20120604].
o Top-Level Domain Name (TLD), see definition of Top-Level Domain in
[RFC8499].
o UTC: Coordinated Universal Time, as maintained by the Bureau
International des Poids et Mesures (BIPM); see also [RFC3339].
4. Conventions Used in This Document 4. Conventions Used in This Document
4.1. Date and Time 4.1. Date and Time
Numerous fields indicate "dates", such as the creation and expiry Numerous fields indicate "dates", such as the creation and expiry
dates for domain names. These fields SHALL contain timestamps dates for domain names. These fields SHALL contain timestamps
indicating the date and time in UTC as specified in [RFC3339], with indicating the date and time in UTC as specified in [RFC3339], with
no offset from the zero meridian. no offset from the zero meridian.
skipping to change at page 7, line 16 skipping to change at page 8, line 4
Country identifiers SHALL be represented using two character Country identifiers SHALL be represented using two character
identifiers as specified in [ISO-3166-1]. identifiers as specified in [ISO-3166-1].
4.3. Telephone numbers 4.3. Telephone numbers
Telephone numbers (both voice and facsimile) SHALL be formatted based Telephone numbers (both voice and facsimile) SHALL be formatted based
on structures defined in [ITU-E164]. Telephone numbers described in on structures defined in [ITU-E164]. Telephone numbers described in
this specification are character strings that MUST begin with a plus this specification are character strings that MUST begin with a plus
sign ("+", ASCII value 0x002B), followed by a country code defined in sign ("+", ASCII value 0x002B), followed by a country code defined in
[ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by [ITU-E164], followed by a dot (".", ASCII value 0x002E), followed by
a sequence of digits representing the telephone number. a sequence of digits representing the telephone number.
4.4. Checksum 4.4. Checksum
The checksum of the CSV data escrow files MUST use CRC32, which is A checksum MAY be used to verify the integrity of the CSV files, for
the algorithm used in the ISO 3309 standard and in section 8.1.1.6.2 example, if another layer (i.e., encryption of an archive containing
of ITU-T recommendation V.42. the deposit files) does not provide integrity. By default the CRC32
algorithm (see, 8.1.1.6.2 of [V42]) is used. A stronger algorithm,
such as SHA-256 (see, [RFC6234]) MAY be specified for enhanced
security if required.
4.5. IP addresses 4.5. IP addresses
The syntax of IP addresses MUST conform to the text representation of The syntax of IP addresses MUST conform to the text representation of
either Internet Protocol Version 4 [RFC0791] or Internet Protocol either Internet Protocol Version 4 [RFC0791] or Internet Protocol
Version 6 [RFC4291]. Version 6 [RFC4291].
4.6. Conventions applicable to the CSV Model 4.6. Conventions applicable to the CSV Model
4.6.1. CSV Parent Child Relationship 4.6.1. CSV Parent Child Relationship
skipping to change at page 9, line 45 skipping to change at page 10, line 34
name="domainStatuses"> <csvDomain:fName> field SHOULD set the name="domainStatuses"> <csvDomain:fName> field SHOULD set the
"parent" attribute to "true" to identify it as the parent domain "parent" attribute to "true" to identify it as the parent domain
name of the domain status. name of the domain status.
<rdeCsv:files> A list of one or more CSV files using the <rdeCsv:files> A list of one or more CSV files using the
<rdeCsv:file> child element. The <rdeCsv:file> child element <rdeCsv:file> child element. The <rdeCsv:file> child element
defines a reference to the CSV file name and has the following defines a reference to the CSV file name and has the following
optional attributes: optional attributes:
compression If the CSV file is compressed, the "compression" compression If the CSV file is compressed, the "compression"
attribute defines the compression format like "gzip" or "zip". attribute defines the compression format. For example, setting
this attribute to "gzip" signals that the CSV file is
compressed using the GZIP file format (see, [RFC1952]). The
supported compression formats are negotiated out-of-band.
encoding Defines the encoding of the CSV file with the default encoding Defines the encoding of the CSV file with the default
encoding of "UTF-8". encoding of "UTF-8".
cksum Defines the checksum of the CSV file using CRC32, as cksum Defines the checksum of the CSV file, as described in
defined in Section 4.4. This attribute is used to validate Section 4.4, using the algorithm defined by the "cksumAlg"
that the full CSV file exists and has not been tampered with. attribute. If the "cksumAlg" attribute is not present, the
checksum is calculated using "CRC32".
cksumAlg Defines the checksum algorithm used to calculate the
"cksum" attribute, with the default value of "CRC32". If this
attribute is present, the "cksum" attribute MUST also be
present. The supported checksum algorithms are negotiated out-
of-band.
The <rdeCsv:csv> element requires a "name" attribute that defines the The <rdeCsv:csv> element requires a "name" attribute that defines the
purpose of the CSV file with values like "domain", "host", "contact". purpose of the CSV file with values like "domain", "host", "contact".
The supported "name" attribute values are defined for each object The supported "name" attribute values are defined for each object
type. The OPTIONAL "sep" attribute defines the CSV separator type. The OPTIONAL "sep" attribute defines the CSV separator
character with the default separator character of ",". character with the default separator character of ",".
The following is an example of the <csvDomain:contents> <rdeCsv:csv> The following is an example of the <csvDomain:contents> <rdeCsv:csv>
element for domain name records where the <rdeCsv:fRegistrant> is set element for domain name records where the <rdeCsv:fRegistrant> is set
as required with isRequired="true". as required with isRequired="true".
skipping to change at page 16, line 17 skipping to change at page 17, line 17
There are two elements used in the data escrow of the domain name There are two elements used in the data escrow of the domain name
objects for the XML model including the <rdeDomain:domain>, under the objects for the XML model including the <rdeDomain:domain>, under the
<rde:contents> element, and the <rdeDomain:delete> element, under the <rde:contents> element, and the <rdeDomain:delete> element, under the
<rde:deletes> element. <rde:deletes> element.
5.1.1.1. <rdeDomain:domain> object 5.1.1.1. <rdeDomain:domain> object
The domain element is based on the EPP domain <info> response for an The domain element is based on the EPP domain <info> response for an
authorized client (see Section 3.1.2. of [RFC5731]) with additional authorized client (see Section 3.1.2. of [RFC5731]) with additional
data from an EPP <transfer> Query Response, see Section 3.1.3. of data from an EPP <transfer> Query Response, see Section 3.1.3. of
[RFC5731], RGP status from [RFC3915], and data from the EPP [RFC5731], Registry Grace Period (RGP) status from [RFC3915], and
<secDns:create> command, see Section 5.2.1. of [RFC5910]. data from the EPP <secDns:create> command, see Section 5.2.1. of
[RFC5910].
A <domain> element substitutes for the <abstractDomain> abstract A <domain> element substitutes for the <abstractDomain> abstract
element to define a concrete definition of a domain. The element to define a concrete definition of a domain. The
<abstractDomain> element can be replaced by other domain definitions <abstractDomain> element can be replaced by other domain definitions
using the XML schema substitution groups feature. using the XML schema substitution groups feature.
The <domain> element contains the following child elements: The <domain> element contains the following child elements:
o A <name> element that contains the fully qualified name of the o A <name> element that contains the fully-qualified name of the
domain name object. For IDNs the A-Label is used (see [RFC5891], domain name object. For IDNs the A-Label is used (see [RFC5891],
Section 4.4). Section 4.4).
o A <roid> element that contains the repository object identifier o A <roid> element that contains the repository object identifier
assigned to the domain name object when it was created. assigned to the domain name object when it was created.
o An OPTIONAL <uName> element that contains the fully qualified o An OPTIONAL <uName> element that contains the fully-qualified
domain name in Unicode character set. It MUST be provided if domain name in Unicode character set. It MUST be provided if
available. available.
o An OPTIONAL <idnTableId> element that references the IDN o An OPTIONAL <idnTableId> element that references the IDN
Table used for the IDN. This corresponds to the "id" attribute of Table used for the IDN. This corresponds to the "id" attribute of
the <idnTableRef> element. This element MUST be present if the the <idnTableRef> element. This element MUST be present if the
domain name is an IDN. domain name is an IDN.
o An OPTIONAL <originalName> element is used to indicate that the o An OPTIONAL <originalName> element is used to indicate that the
domain name is an IDN variant. This element contains the domain domain name is an IDN variant. This element contains the domain
skipping to change at page 17, line 15 skipping to change at page 18, line 16
[RFC3915]. [RFC3915].
o An OPTIONAL <registrant> element that contains the identifier for o An OPTIONAL <registrant> element that contains the identifier for
the human or organizational social information object associated the human or organizational social information object associated
as the holder of the domain name object. as the holder of the domain name object.
o Zero or more OPTIONAL <contact> elements that contain identifiers o Zero or more OPTIONAL <contact> elements that contain identifiers
for the human or organizational social information objects for the human or organizational social information objects
associated with the domain name object. associated with the domain name object.
o An OPTIONAL <ns> element that contains the fully qualified names o An OPTIONAL <ns> element that contains the fully-qualified names
of the delegated host objects or host attributes (name servers) of the delegated host objects or host attributes (name servers)
associated with the domain name object. See Section 1.1 of associated with the domain name object. See Section 1.1 of
[RFC5731] for a description of the elements used to specify host [RFC5731] for a description of the elements used to specify host
objects or host attributes. objects or host attributes.
o A <clID> element that contains the identifier of the sponsoring o A <clID> element that contains the identifier of the sponsoring
registrar. registrar.
o An OPTIONAL <crRr> element that contains the identifier of the o An OPTIONAL <crRr> element that contains the identifier of the
registrar that created the domain name object. An OPTIONAL client registrar that created the domain name object. An OPTIONAL client
skipping to change at page 19, line 30 skipping to change at page 20, line 30
</rdeDomain:ns> </rdeDomain:ns>
<rdeDomain:clID>RegistrarX</rdeDomain:clID> <rdeDomain:clID>RegistrarX</rdeDomain:clID>
<rdeDomain:crRr client="jdoe">RegistrarX</rdeDomain:crRr> <rdeDomain:crRr client="jdoe">RegistrarX</rdeDomain:crRr>
<rdeDomain:crDate>1999-04-03T22:00:00.0Z</rdeDomain:crDate> <rdeDomain:crDate>1999-04-03T22:00:00.0Z</rdeDomain:crDate>
<rdeDomain:exDate>2015-04-03T22:00:00.0Z</rdeDomain:exDate> <rdeDomain:exDate>2015-04-03T22:00:00.0Z</rdeDomain:exDate>
</rdeDomain:domain> </rdeDomain:domain>
... ...
5.1.1.2. <rdeDomain:delete> object 5.1.1.2. <rdeDomain:delete> object
The <rdeDomain:delete> element contains the fully qualified domain The <rdeDomain:delete> element contains the fully-qualified domain
name that was deleted and purged. name that was deleted and purged.
Example of <rdeDomain:delete> object: Example of <rdeDomain:delete> object:
... ...
<rde:deletes> <rde:deletes>
... ...
<rdeDomain:delete> <rdeDomain:delete>
<rdeDomain:name>foo.example</rdeDomain:name> <rdeDomain:name>foo.example</rdeDomain:name>
<rdeDomain:name>bar.example</rdeDomain:name> <rdeDomain:name>bar.example</rdeDomain:name>
skipping to change at page 20, line 45 skipping to change at page 21, line 45
The following "csvDomain" field elements MUST be used in the "domain" The following "csvDomain" field elements MUST be used in the "domain"
<rdeCsv:csv> <rdeCsv:fields> element: <rdeCsv:csv> <rdeCsv:fields> element:
<csvDomain:fName> Domain name field with type="eppcom:labelType" and <csvDomain:fName> Domain name field with type="eppcom:labelType" and
isRequired="true". isRequired="true".
The following "csvDomain" field elements MAY be used in the "domain" The following "csvDomain" field elements MAY be used in the "domain"
<rdeCsv:csv> <rdeCsv:fields> element: <rdeCsv:csv> <rdeCsv:fields> element:
<csvDomain:fOriginalName> Fully qualified name of the original IDN <csvDomain:fOriginalName> Fully-qualified name of the original IDN
domain name object related to the variant domain name object with domain name object related to the variant domain name object with
type="eppcom:labelType". type="eppcom:labelType".
The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the
"domain" <rdeCsv:csv> <rdeCsv:fields> element: "domain" <rdeCsv:csv> <rdeCsv:fields> element:
<rdeCsv:fRoid> Registry Object IDentifier (ROID) for the domain name <rdeCsv:fRoid> Registry Object IDentifier (ROID) for the domain name
object with isRequired="true". object with isRequired="true".
<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of: <rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of:
skipping to change at page 24, line 37 skipping to change at page 25, line 37
The following "csvDomain" fields, defined for the "domain" CSV File The following "csvDomain" fields, defined for the "domain" CSV File
Definition (Section 5.1.2.1.1), MUST be used in the "domainStatuses" Definition (Section 5.1.2.1.1), MUST be used in the "domainStatuses"
<rdeCsv:csv> <rdeCsv:fields> element: <rdeCsv:csv> <rdeCsv:fields> element:
<csvDomain:fName> Domain name of status with isRequired="true". <csvDomain:fName> Domain name of status with isRequired="true".
<csvDomain:fStatus> The status of the domain name with <csvDomain:fStatus> The status of the domain name with
type="domain:statusValueType" and isRequired="true". type="domain:statusValueType" and isRequired="true".
<csvDomain:fRgpStatus> The Registry Grace Period (RGP) status, as a <csvDomain:fRgpStatus> The RGP status, as a sub-status of the
sub-status of the <csvDomain:fStatus> "pendingDelete" status <csvDomain:fStatus> "pendingDelete" status value, with
value, with type="rgp:statusValueType" as defined in [RFC3915]. type="rgp:statusValueType" as defined in [RFC3915].
The following "rdeCsv" fields, defined in section CSV common field The following "rdeCsv" fields, defined in section CSV common field
elements (Section 4.6.2.2), MAY be used in the "domainStatuses" elements (Section 4.6.2.2), MAY be used in the "domainStatuses"
<rdeCsv:csv> <rdeCsv:fields> element: <rdeCsv:csv> <rdeCsv:fields> element:
<rdeCsv:fStatusDescription> Domain object status description which <rdeCsv:fStatusDescription> Domain object status description which
is free form text describing the rationale for the status. is free form text describing the rationale for the status.
<rdeCsv:fLang> Language of the <rdeCsv:fStatusDescription> field. <rdeCsv:fLang> Language of the <rdeCsv:fStatusDescription> field.
skipping to change at page 35, line 24 skipping to change at page 36, line 24
<rdeHost:abstractHost> element can be replaced by other host <rdeHost:abstractHost> element can be replaced by other host
definitions using the XML schema substitution groups feature. definitions using the XML schema substitution groups feature.
5.2.1.1. <rdeHost:host> element 5.2.1.1. <rdeHost:host> element
The RDE host object is based on the EPP host <info> response for an The RDE host object is based on the EPP host <info> response for an
authorized client (Section 3.1.2. of [RFC5732]). authorized client (Section 3.1.2. of [RFC5732]).
The OPTIONAL <host> element contains the following child elements: The OPTIONAL <host> element contains the following child elements:
o A <name> element that contains the fully qualified name of the o A <name> element that contains the fully-qualified name of the
host object. host object.
o A <roid> element that contains the repository object identifier o A <roid> element that contains the repository object identifier
assigned to the host object when the object was created. assigned to the host object when the object was created.
o One or more <status> elements that describe the status of the host o One or more <status> elements that describe the status of the host
object. object.
o Zero or more <addr> elements that contain the IP addresses o Zero or more <addr> elements that contain the IP addresses
associated with the host object. associated with the host object.
skipping to change at page 36, line 24 skipping to change at page 37, line 24
Example of <host> object: Example of <host> object:
... ...
<rdeHost:host> <rdeHost:host>
<rdeHost:name>ns1.example1.example</rdeHost:name> <rdeHost:name>ns1.example1.example</rdeHost:name>
<rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid> <rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid>
<rdeHost:status s="ok"/> <rdeHost:status s="ok"/>
<rdeHost:status s="linked"/> <rdeHost:status s="linked"/>
<rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr> <rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr>
<rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr> <rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr>
<rdeHost:addr ip="v6">1080:0:0:0:8:800:200C:417A</rdeHost:addr> <rdeHost:addr ip="v6">2001:DB8:1::1</rdeHost:addr>
<rdeHost:clID>RegistrarX</rdeHost:clID> <rdeHost:clID>RegistrarX</rdeHost:clID>
<rdeHost:crRr>RegistrarX</rdeHost:crRr> <rdeHost:crRr>RegistrarX</rdeHost:crRr>
<rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate> <rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate>
<rdeHost:upRr>RegistrarX</rdeHost:upRr> <rdeHost:upRr>RegistrarX</rdeHost:upRr>
<rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate> <rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate>
</rdeHost:host> </rdeHost:host>
... ...
5.2.1.2. <rdeHost:delete> object 5.2.1.2. <rdeHost:delete> object
The <rdeHost:delete> element contains the fully qualified domain name The <rdeHost:delete> element contains the fully-qualified domain name
of a host that was deleted. The <rdeHost:delete> element also of a host that was deleted. The <rdeHost:delete> element also
supports host removal based on roid to support SRS systems in which supports host removal based on roid to support SRS systems in which
different hosts with the same fully qualified domain name are active different hosts with the same fully-qualified domain name are active
at the same time. at the same time.
Example of <rdeHost:delete> object: Example of <rdeHost:delete> object:
... ...
<rde:deletes> <rde:deletes>
... ...
<rdeHost:delete> <rdeHost:delete>
<rdeHost:name>ns1.example.example</rdeHost:name> <rdeHost:name>ns1.example.example</rdeHost:name>
</rdeHost:delete> </rdeHost:delete>
skipping to change at page 74, line 39 skipping to change at page 75, line 39
A <rdeNNDN:NNDN> element substitutes for the <rdeNNDN:abstractNNDN> A <rdeNNDN:NNDN> element substitutes for the <rdeNNDN:abstractNNDN>
abstract element to define a concrete definition of an NNDN. The abstract element to define a concrete definition of an NNDN. The
<rdeNNDN:abstractDomain> element can be replaced by other NNDN <rdeNNDN:abstractDomain> element can be replaced by other NNDN
definitions using the XML schema substitution groups feature. definitions using the XML schema substitution groups feature.
5.6.1.1. <rdeNNDN:NNDN> object 5.6.1.1. <rdeNNDN:NNDN> object
The <rdeNNDN:NNDN> element contains the following child elements: The <rdeNNDN:NNDN> element contains the following child elements:
o An <aName> element that contains the fully qualified name of the o An <aName> element that contains the fully-qualified qualified
NNDN. For IDNs the A-Label is used (see [RFC5891], Section 4.4). name of the NNDN. For IDNs the A-Label is used (see [RFC5891],
Section 4.4).
o An OPTIONAL <uName> element that contains the fully qualified name o An OPTIONAL <uName> element that contains the fully-qualified name
of the NNDN in Unicode character set. It MUST be provided if of the NNDN in Unicode character set. It MUST be provided if
available. available.
o An OPTIONAL <idnTableId> element that references the IDN o An OPTIONAL <idnTableId> element that references the IDN
Table used for the NNDN. This corresponds to the "id" attribute Table used for the NNDN. This corresponds to the "id" attribute
of the <idnTableRef> element. This element MUST be present if the of the <idnTableRef> element. This element MUST be present if the
NNDN is an IDN. NNDN is an IDN.
o An OPTIONAL <originalName> element is used to indicate that the o An OPTIONAL <originalName> element is used to indicate that the
NNDN is used for an IDN variant. This element contains the domain NNDN is used for an IDN variant. This element contains the domain
skipping to change at page 76, line 44 skipping to change at page 77, line 44
NNDN CSV file definitions. NNDN CSV file definitions.
5.6.2.1.1. "NNDN" CSV File Definition 5.6.2.1.1. "NNDN" CSV File Definition
The "NNDN" CSV File Definition defines the fields and CSV file The "NNDN" CSV File Definition defines the fields and CSV file
references used for the NNDN object records. references used for the NNDN object records.
The following "csvNNDN" field elements MUST be used in the "NNDN" The following "csvNNDN" field elements MUST be used in the "NNDN"
<rdeCsv:csv> <rdeCsv:fields> element: <rdeCsv:csv> <rdeCsv:fields> element:
<csvNNDN:fAName> Fully qualified name of the NNDN with <csvNNDN:fAName> Fully-qualified name of the NNDN with
type="eppcom:labelType" and isRequired="true". For IDNs the type="eppcom:labelType" and isRequired="true". For IDNs the
A-Label is used (see [RFC5891], Section 4.4). A-Label is used (see [RFC5891], Section 4.4).
<csvNNDN:fNameState> State of the NNDN: blocked or withheld with <csvNNDN:fNameState> State of the NNDN: blocked or withheld with
type="rdeNNDN:nameState" and isRequired="true". See type="rdeNNDN:nameState" and isRequired="true". See
Section 5.6.1.1 for a description of the possible values for the Section 5.6.1.1 for a description of the possible values for the
<rdeNNDN:nameState> element. <rdeNNDN:nameState> element.
The following field elements MAY be used in the "NNDN" <rdeCsv:csv> The following field elements MAY be used in the "NNDN" <rdeCsv:csv>
<rdeCsv:fields> element: <rdeCsv:fields> element:
skipping to change at page 79, line 5 skipping to change at page 80, line 5
Differential or Incremental Deposit. The <csvNNDN:deletes> is split Differential or Incremental Deposit. The <csvNNDN:deletes> is split
into separate CSV file definitions using named <rdeCsv:csv> elements into separate CSV file definitions using named <rdeCsv:csv> elements
with the "name" attribute. The following section defines the with the "name" attribute. The following section defines the
supported NNDN deletes CSV file definition. supported NNDN deletes CSV file definition.
5.6.2.2.1. "NNDN" Deletes CSV File Definition 5.6.2.2.1. "NNDN" Deletes CSV File Definition
The following "NNDN" field elements MUST be used in the deletes The following "NNDN" field elements MUST be used in the deletes
"NNDN" <rdeCsv:csv> <rdeCsv:fields> element: "NNDN" <rdeCsv:csv> <rdeCsv:fields> element:
<csvNNDN:fAName> Fully qualified name of the NNDN with <csvNNDN:fAName> Fully-qualified name of the NNDN with
type="eppcom:labelType" and isRequired="true". type="eppcom:labelType" and isRequired="true".
Example of an "NNDN" <csvNNDN:deletes> <rdeCsv:csv> element. Example of an "NNDN" <csvNNDN:deletes> <rdeCsv:csv> element.
... ...
<csvNNDN:deletes> <csvNNDN:deletes>
... ...
<rdeCsv:csv name="NNDN"> <rdeCsv:csv name="NNDN">
<rdeCsv:fields> <rdeCsv:fields>
<csvNNDN:fAName/> <csvNNDN:fAName/>
skipping to change at page 82, line 5 skipping to change at page 83, line 5
5.9.1. <rdeHeader:header> object 5.9.1. <rdeHeader:header> object
The <rdeHeader:header> contains the following elements: The <rdeHeader:header> contains the following elements:
o A choice of one of the elements defined in the o A choice of one of the elements defined in the
"repositoryTypeGroup" group element that indicates the unique "repositoryTypeGroup" group element that indicates the unique
identifier for the repository being escrowed. Possible elements identifier for the repository being escrowed. Possible elements
are: are:
* A <rdeHeader:tld> element that defines TLD or the REGISTRY- * A <rdeHeader:tld> element that defines TLD or the RCDN being
CLASS DOMAIN NAME (RCDN) being escrowed in the case of a escrowed in the case of a Registry data escrow deposit. For
Registry data escrow deposit. For IDNs the A-Label is used IDNs the A-Label is used (see [RFC5891], Section 4.4).
(see [RFC5891], Section 4.4).
* A <rdeHeader:registrar> element that defines the Registrar ID * A <rdeHeader:registrar> element that defines the Registrar ID
corresponding to a Registrar data escrow deposit. In the case corresponding to a Registrar data escrow deposit. In the case
of an ICANN-accredited Registrar, the <rdeHeader:registrar> of an ICANN-accredited Registrar, the <rdeHeader:registrar>
element MUST be the IANA Registrar ID assigned by ICANN. element MUST be the IANA Registrar ID assigned by ICANN.
* A <rdeHeader:ppsp> element that defines the provider ID * A <rdeHeader:ppsp> element that defines the provider ID
corresponding to a Privacy and Proxy Services Provider data corresponding to a Privacy and Proxy Services Provider data
escrow deposit. In the case of an ICANN-accredited Privacy and escrow deposit. In the case of an ICANN-accredited Privacy and
Proxy Services Provider, the <rdeHeader:ppsp> element MUST be Proxy Services Provider, the <rdeHeader:ppsp> element MUST be
skipping to change at page 82, line 36 skipping to change at page 83, line 35
deposit: Differential, Full or Incremental. The <count> element deposit: Differential, Full or Incremental. The <count> element
supports the following attributes: supports the following attributes:
* A "uri" attribute reflects the XML namespace URI of the primary * A "uri" attribute reflects the XML namespace URI of the primary
objects for the XML Model and CSV Model. For example, the objects for the XML Model and CSV Model. For example, the
"uri" is set to "urn:ietf:params:xml:ns:rdeDomain-1.0" for "uri" is set to "urn:ietf:params:xml:ns:rdeDomain-1.0" for
domain name objects using the XML Model, and the "uri" is set domain name objects using the XML Model, and the "uri" is set
to "urn:ietf:params:xml:ns:csvDomain-1.0" for domain name to "urn:ietf:params:xml:ns:csvDomain-1.0" for domain name
objects using the CSV Model. objects using the CSV Model.
* An OPTIONAL "rcdn" attribute indicates the REGISTRY-CLASS * An OPTIONAL "rcdn" attribute indicates the RCDN of the objects
DOMAIN NAME (RCDN) of the objects included in the <count> included in the <count> element. For IDNs the A-Label is used
element. For IDNs the A-Label is used [RFC5891], Section 4.4. [RFC5891], Section 4.4. If the "rcdn" attribute is present,
If the "rcdn" attribute is present, the value of the <count> the value of the <count> element must include only objects
element must include only objects related to registrations in related to registrations in the same and lower levels. For
the same and lower levels. For example in a data escrow example in a data escrow deposit for the .EXAMPLE TLD, a value
deposit for the .EXAMPLE TLD, a value of "example" in the of "example" in the "rcdn" attribute within the <count> element
"rcdn" attribute within the <count> element indicates the indicates the number of objects in the TLD including objects in
number of objects in the TLD including objects in other RCDNs other RCDNs within the TLD, whereas a value of "com.example"
within the TLD, whereas a value of "com.example" indicates the indicates the number of elements for objects under
number of elements for objects under "com.example" and lower "com.example" and lower levels. Omitting the "rcdn" attribute
levels. Omitting the "rcdn" attribute indicates that the total indicates that the total includes all objects of the specified
includes all objects of the specified "uri" in the repository "uri" in the repository (e.g. the TLD, Registrar, or PPSP).
(e.g. the TLD, Registrar, or PPSP).
* An OPTIONAL "registrarId" attribute indicates the identifier of * An OPTIONAL "registrarId" attribute indicates the identifier of
the sponsoring Registrar of the objects included in the <count> the sponsoring Registrar of the objects included in the <count>
element. In the case of an ICANN-accredited Registrar, the element. In the case of an ICANN-accredited Registrar, the
value MUST be the IANA Registrar ID assigned by ICANN. value MUST be the IANA Registrar ID assigned by ICANN.
o An OPTIONAL <contentTag> element that contains a tag that defines o An OPTIONAL <contentTag> element that contains a tag that defines
the expected content in the deposit. The producer and consumer of the expected content in the deposit. The producer and consumer of
the deposits will coordinate the set of possible <contentTag> the deposits will coordinate the set of possible <contentTag>
element values. element values.
skipping to change at page 95, line 26 skipping to change at page 96, line 26
</complexType> </complexType>
<!-- File definition --> <!-- File definition -->
<complexType name="fileType"> <complexType name="fileType">
<simpleContent> <simpleContent>
<extension base="token"> <extension base="token">
<attribute name="compression" type="token"/> <attribute name="compression" type="token"/>
<attribute name="encoding" type="token" <attribute name="encoding" type="token"
default="UTF-8"/> default="UTF-8"/>
<attribute name="cksum" type="token"/> <attribute name="cksum" type="token"/>
<attribute name="cksumAlg" type="token"
default="CRC32"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
<!-- URL fields --> <!-- URL fields -->
<element name="fUrl" type="rdeCsv:anyURIType" <element name="fUrl" type="rdeCsv:anyURIType"
substitutionGroup="rdeCsv:field"/> substitutionGroup="rdeCsv:field"/>
<complexType name="anyURIType"> <complexType name="anyURIType">
<complexContent> <complexContent>
<extension base="rdeCsv:fieldOptionalType"> <extension base="rdeCsv:fieldOptionalType">
skipping to change at page 149, line 5 skipping to change at page 150, line 5
16.20. Changes REGEXT 07 to REGEXT 08 16.20. Changes REGEXT 07 to REGEXT 08
1. Changes based on the feedback provided here: 1. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/ https://mailarchive.ietf.org/arch/msg/regext/
UaMNvl1xh60ldjpqHHYc3TNsfhg UaMNvl1xh60ldjpqHHYc3TNsfhg
2. Changes based on the feedback provided here: 2. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/ https://mailarchive.ietf.org/arch/msg/regext/
B3QTxUCWUE4R_QharAQlA3041j0 B3QTxUCWUE4R_QharAQlA3041j0
16.21. Changes REGEXT 08 to REGEXT 09
1. Changes based on the feedback provided here:
https://mailarchive.ietf.org/arch/msg/regext/
EmKW32exlPgLbBUIbS8OjdYUJWc
17. Example of a Full Deposit using the XML model 17. Example of a Full Deposit using the XML model
Example of a Full Deposit using the XML model: Example of a Full Deposit using the XML model:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<rde:deposit type="FULL" id="20191017001" <rde:deposit type="FULL" id="20191017001"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1" xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
skipping to change at page 151, line 19 skipping to change at page 152, line 25
</rdeDomain:domain> </rdeDomain:domain>
<!-- Host: ns1.example.example --> <!-- Host: ns1.example.example -->
<rdeHost:host> <rdeHost:host>
<rdeHost:name>ns1.example1.example</rdeHost:name> <rdeHost:name>ns1.example1.example</rdeHost:name>
<rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid> <rdeHost:roid>Hns1_example_test-TEST</rdeHost:roid>
<rdeHost:status s="ok"/> <rdeHost:status s="ok"/>
<rdeHost:status s="linked"/> <rdeHost:status s="linked"/>
<rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr> <rdeHost:addr ip="v4">192.0.2.2</rdeHost:addr>
<rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr> <rdeHost:addr ip="v4">192.0.2.29</rdeHost:addr>
<rdeHost:addr ip="v6">1080:0:0:0:8:800:200C:417A <rdeHost:addr ip="v6">2001:DB8:1::1</rdeHost:addr>
</rdeHost:addr>
<rdeHost:clID>RegistrarX</rdeHost:clID> <rdeHost:clID>RegistrarX</rdeHost:clID>
<rdeHost:crRr>RegistrarX</rdeHost:crRr> <rdeHost:crRr>RegistrarX</rdeHost:crRr>
<rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate> <rdeHost:crDate>1999-05-08T12:10:00.0Z</rdeHost:crDate>
<rdeHost:upRr>RegistrarX</rdeHost:upRr> <rdeHost:upRr>RegistrarX</rdeHost:upRr>
<rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate> <rdeHost:upDate>2009-10-03T09:34:00.0Z</rdeHost:upDate>
</rdeHost:host> </rdeHost:host>
<!-- Contact: sh8013 --> <!-- Contact: sh8013 -->
<rdeContact:contact> <rdeContact:contact>
<rdeContact:id>sh8013</rdeContact:id> <rdeContact:id>sh8013</rdeContact:id>
skipping to change at page 177, line 20 skipping to change at page 178, line 28
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS)
Security Extensions Mapping for the Extensible Security Extensions Mapping for the Extensible
Provisioning Protocol (EPP)", RFC 5910, Provisioning Protocol (EPP)", RFC 5910,
DOI 10.17487/RFC5910, May 2010, DOI 10.17487/RFC5910, May 2010,
<https://www.rfc-editor.org/info/rfc5910>. <https://www.rfc-editor.org/info/rfc5910>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[V42] International Telecommunication Union, "V.42 : Error-
correcting procedures for DCEs using asynchronous-to-
synchronous conversion", March 2002,
<https://www.itu.int/rec/T-REC-V.42/en>.
[W3C.REC-xml-20081126] [W3C.REC-xml-20081126]
Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition) REC-xml-20081126", November 2008, Edition) REC-xml-20081126", November 2008,
<https://www.w3.org/TR/2008/REC-xml-20081126/>. <https://www.w3.org/TR/2008/REC-xml-20081126/>.
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition REC- "XML Schema Part 1: Structures Second Edition REC-
xmlschema-1-20041028", October 2004, xmlschema-1-20041028", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>. <https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
[W3C.REC-xmlschema-2-20041028] [W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition REC-xmlschema-2-20041028", October 2004, Second Edition REC-xmlschema-2-20041028", October 2004,
<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>. <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
21.2. Informative References 21.2. Informative References
[ICANN-GTLD-AGB-20120604]
ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June
2012, <http://newgtlds.icann.org/en/applicants/agb/
guidebook-full-04jun12-en.pdf>.
[ICANN-GTLD-RA-20170731] [ICANN-GTLD-RA-20170731]
ICANN, "Base Registry Agreement 2017-07-31", July 2017, ICANN, "Base Registry Agreement 2017-07-31", July 2017,
<https://newgtlds.icann.org/sites/default/files/ <https://newgtlds.icann.org/sites/default/files/
agreements/agreement-approved-31jul17-en.pdf>. agreements/agreement-approved-31jul17-en.pdf>.
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
RFC 1952, DOI 10.17487/RFC1952, May 1996,
<https://www.rfc-editor.org/info/rfc1952>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
Separated Values (CSV) Files", RFC 4180,
DOI 10.17487/RFC4180, October 2005,
<https://www.rfc-editor.org/info/rfc4180>.
[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,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
 End of changes. 41 change blocks. 
153 lines changed or deleted 242 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/