rfc9022.original		rfc9022.txt
	Network Working Group G. Lozano		Internet Engineering Task Force (IETF) G. Lozano
	Internet-Draft ICANN		Request for Comments: 9022 ICANN
	Intended status: Standards Track J. Gould		Category: Standards Track J. Gould
	Expires: June 19, 2021 C. Thippeswamy		ISSN: 2070-1721 C. Thippeswamy
	VeriSign		VeriSign
	Dec 16, 2020		May 2021
	Domain Name Registration Data (DNRD) Objects Mapping		Domain Name Registration Data (DNRD) Objects Mapping
	draft-ietf-regext-dnrd-objects-mapping-11
	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 is an Internet Standards Track document.
	provisions of BCP 78 and BCP 79.
	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		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Further information on
			Internet Standards is available in Section 2 of RFC 7841.
	This Internet-Draft will expire on June 19, 2021.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc9022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2021 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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
	2. Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Models
	2.1. XML Model . . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. XML Model
	2.2. CSV Model . . . . . . . . . . . . . . . . . . . . . . . . 6		2.2. CSV Model
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology
	3.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Glossary
	4. Conventions Used in This Document . . . . . . . . . . . . . . 7		4. Conventions Used in This Document
	4.1. Date and Time . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Date and Time
	4.2. Country names . . . . . . . . . . . . . . . . . . . . . . 8		4.2. Country Names
	4.3. Telephone numbers . . . . . . . . . . . . . . . . . . . . 8		4.3. Telephone Numbers
	4.4. CSV Integrity Check . . . . . . . . . . . . . . . . . . . 8		4.4. CSV Integrity Check
	4.5. IP addresses . . . . . . . . . . . . . . . . . . . . . . 8		4.5. IP Addresses
	4.6. Conventions applicable to the CSV Model . . . . . . . . . 8		4.6. Conventions Applicable to the CSV Model
	5. Object Description . . . . . . . . . . . . . . . . . . . . . 17		5. Object Description
	5.1. Domain Name Object . . . . . . . . . . . . . . . . . . . 17		5.1. Domain Name Object
	5.2. Host Object . . . . . . . . . . . . . . . . . . . . . . . 36		5.2. Host Object
	5.3. Contact Object . . . . . . . . . . . . . . . . . . . . . 46		5.3. Contact Object
	5.4. Registrar Object . . . . . . . . . . . . . . . . . . . . 64		5.4. Registrar Object
	5.5. IDN Table Reference Object . . . . . . . . . . . . . . . 72		5.5. IDN Table Reference Object
	5.6. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 75		5.6. NNDN Object
	5.7. EPP Parameters Object . . . . . . . . . . . . . . . . . . 80		5.7. EPP Parameters Object
	5.8. Policy Object . . . . . . . . . . . . . . . . . . . . . . 82		5.8. Policy Object
	5.9. Header Object . . . . . . . . . . . . . . . . . . . . . . 82		5.9. Header Object
	5.10. DNRD Common Objects Collection . . . . . . . . . . . . . 85		5.10. DNRD Common Objects Collection
	6. RDE IDN Variants handling . . . . . . . . . . . . . . . . . . 85		6. RDE IDN Variants Handling
	7. Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . 86		7. Profile
	8. Data escrow agent extended verification process . . . . . . . 86		8. Data Escrow Agent Extended Verification Process
	9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 87		9. Formal Syntax
	9.1. RDE CSV Schema . . . . . . . . . . . . . . . . . . . . . 87		9.1. RDE CSV Schema
	9.2. RDE Domain Object . . . . . . . . . . . . . . . . . . . . 97		9.2. RDE Domain Object
	9.3. CSV Domain Object . . . . . . . . . . . . . . . . . . . . 100		9.3. CSV Domain Object
	9.4. RDE Host Object . . . . . . . . . . . . . . . . . . . . . 103		9.4. RDE Host Object
	9.5. CSV Host Object . . . . . . . . . . . . . . . . . . . . . 105		9.5. CSV Host Object
	9.6. RDE Contact Object . . . . . . . . . . . . . . . . . . . 107		9.6. RDE Contact Object
	9.7. CSV Contact Object . . . . . . . . . . . . . . . . . . . 110		9.7. CSV Contact Object
	9.8. RDE Registrar Object . . . . . . . . . . . . . . . . . . 116		9.8. RDE Registrar Object
	9.9. CSV Registrar Object . . . . . . . . . . . . . . . . . . 119		9.9. CSV Registrar Object
	9.10. RDE IDN Table Reference Objects . . . . . . . . . . . . . 122		9.10. RDE IDN Table Reference Objects
	9.11. CSV IDN Language Object . . . . . . . . . . . . . . . . . 123		9.11. CSV IDN Language Object
	9.12. EPP Parameters Object . . . . . . . . . . . . . . . . . . 124		9.12. EPP Parameters Object
	9.13. NNDN Object . . . . . . . . . . . . . . . . . . . . . . . 125		9.13. NNDN Object
	9.14. CSV NNDN Object . . . . . . . . . . . . . . . . . . . . . 127		9.14. CSV NNDN Object
	9.15. Policy Object . . . . . . . . . . . . . . . . . . . . . . 129		9.15. Policy Object
	9.16. Header Object . . . . . . . . . . . . . . . . . . . . . . 130		9.16. Header Object
	9.17. DNRD Common Objects . . . . . . . . . . . . . . . . . . . 132		9.17. DNRD Common Objects
	10. Internationalization Considerations . . . . . . . . . . . . . 132		10. Internationalization Considerations
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 132		11. IANA Considerations
	12. Implementation Status . . . . . . . . . . . . . . . . . . . . 140		12. Security Considerations
	12.1. Implementation in the gTLD space . . . . . . . . . . . . 141		13. Privacy Considerations
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 141		14. Example of a Full Deposit Using the XML Model
	14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 142		15. Example of a Differential Deposit Using the XML Model
	15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 142		16. Example of a Full Deposit Using the CSV Model
	16. Change History . . . . . . . . . . . . . . . . . . . . . . . 143		17. Example of a Differential Deposit Using the CSV Model
	16.1. Changes from draft-arias-noguchi-registry-data-escrow-02		18. References
	to -dnrd-objects-mapping-00 . . . . . . . . . . . . . . 143		18.1. Normative References
	16.2. Changes from 00 to 01 . . . . . . . . . . . . . . . . . 143		18.2. Informative References
	16.3. Changes from 01 to 02 . . . . . . . . . . . . . . . . . 144		Acknowledgments
	16.4. Changes from 02 to 03 . . . . . . . . . . . . . . . . . 144		Authors' Addresses
	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
	16.23. Changes REGEXT 10 to REGEXT 11 . . . . . . . . . . . . . 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 . . . . . 168
	21. References . . . . . . . . . . . . . . . . . . . . . . . . . 178
	21.1. Normative References . . . . . . . . . . . . . . . . . . 178
	21.2. Informative References . . . . . . . . . . . . . . . . . 181
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 182
	1. Introduction		1. Introduction
	Registry Data Escrow (RDE) is the process by which a registry		Registry Data Escrow (RDE) is the process by which a registry
	periodically submits data deposits to a third-party called an escrow		periodically submits data deposits to a third party called an escrow
	agent. These deposits comprise the minimum data needed by a third-		agent. These deposits comprise the minimum data needed by a third
	party to resume operations if the registry cannot function and is		party to resume operations if the registry cannot function and is
	unable or unwilling to facilitate an orderly transfer of service.		unable or unwilling to facilitate an orderly transfer of service.
	For example, for a domain name registry or registrar, the data to be		For example, for a domain name registry or registrar, the data to be
	deposited would include all the objects related to registered domain		deposited would include all the objects related to registered domain
	names, e.g., names, contacts, name servers, etc.		names, e.g., names, contacts, name servers, etc.
	The goal of data escrow is higher resiliency of registration		The goal of data escrow is higher resiliency of registration services
	services, for the benefit of Internet users. The beneficiaries of a		for the benefit of Internet users. The beneficiaries of a registry
	registry are not just those registering information there, but also		are not just those registering information there, but also the users
	the users of services relying on the registry data.		of services relying on the registry data.
	In the context of domain name registries, registration data escrow is		In the context of domain name registries, registration data escrow is
	a requirement for generic top-level domains (e.g., Specification 2 of		a requirement for generic top-level domains (e.g., Specification 2 of
	the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and		the ICANN Base Registry Agreement, see [ICANN-GTLD-RA-20170731]) and
	some country code top-level domain managers are also currently		some country code top-level domain managers are also currently
	escrowing data. There is also a similar requirement for ICANN-		escrowing data. There is also a similar requirement for ICANN-
	accredited domain registrars.		accredited domain registrars.
	This document defines the standard set of objects for a Domain Name		This document defines the standard set of objects for a domain name
	Registry that uses the Registry Data Escrow Specification described		registry that uses the Registry Data Escrow Specification described
	in [I-D.ietf-regext-data-escrow] for escrow. The set of objects		in [RFC8909] for escrow. The set of objects include:
	include:
	o Domain: Internet domain names that are typically provisioned in a		Domain: Internet domain names that are typically provisioned in a
	Domain Name Registry using the EPP domain name mapping [RFC5731].		domain name registry using the Extensible Provisioning Protocol
	The attributes defined in the EPP domain name mapping [RFC5731]		(EPP) domain name mapping [RFC5731]. The attributes defined in
	are fully supported by this document.		the EPP domain name mapping [RFC5731] are fully supported by this
			document.
	o Host: Internet host names that are typically provisioned in a		Host: Internet host names that are typically provisioned in a domain
	Domain Name Registry using the EPP host mapping [RFC5732]. The		name registry using the EPP host mapping [RFC5732]. The
	attributes defined in the EPP host mapping [RFC5732] are fully		attributes defined in the EPP host mapping [RFC5732] are fully
	supported by this document.		supported by this document.
	o Contact: Individual or organization social information provisioned		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,		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		NNDN (NNDN's not domain name): Domain Name Registries may maintain
	domain names without being persisted as domain objects in the		domain names without being persisted as domain objects in 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		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.
	o EPP parameters: Contains the EPP parameters supported by the		EPP parameters: Contains the EPP parameters supported by the
	Registry Operator.		registry operator.
	o Header: Used to specify counters of objects in the database at a		Header: Used to specify counters of objects in the database at a
	certain point in time (watermark).		certain point in time (Timeline Watermark).
	o Policy: Used to specify OPTIONAL elements from this specification		Policy: Used to specify OPTIONAL elements from this specification
	that are REQUIRED based on the business model of the registry.		that are REQUIRED based on the business model of the registry.
	Extensible Markup Language (XML) 1.0 as described in		Extensible Markup Language (XML) 1.0 as described in
	[W3C.REC-xml-20081126] and XML Schema notation 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		[W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are
	used in this specification.		used in this specification.
	2. Models		2. Models
	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 (comma-separated values).
	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		example, a registry may use the CSV-export functionality of the
	Relational Database Management System (RDBMS) for escrow; therefore,		Relational Database Management System (RDBMS) for escrow; therefore,
	the CSV model may be more appropriate. Another registry may use the		the CSV model may be more appropriate. Another registry may use the
	code developed for EPP to implement 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		The XML model includes all the deposit information (metadata and
	and data) in an XML document. The definition of the XML format is		data) in an XML document. The definition of the XML format is fully
	fully defined in the XML schemas. As a convention, the objects		defined in the XML schemas. As a convention, the objects represented
	represented using the XML model are referenced using RDE and an XML		using the XML model are referenced using RDE and an XML namespace
	namespace that is prefixed with "rde". For example, the Domain Name		that is prefixed with "rde". For example, the Domain Name object
	object represented using the XML model can be referred to as the RDE		represented using the XML model can be referred to as the RDE Domain
	Domain Name with the XML namespace including rdeDomain		Name with the XML namespace including rdeDomain
	(urn:ietf:params:xml:ns:rdeDomain-1.0).		(urn:ietf:params:xml:ns:rdeDomain-1.0).
	2.2. CSV Model		2.2. CSV Model
	CSV: The CSV model uses XML to define the data escrow format of the		The CSV model uses XML to define the data escrow format of the data
	data contained in referenced Comma-Separated Values (CSV) files. As		contained in referenced CSV files. As a convention, the objects
	a convention, the objects represented using the CSV model is		represented using the CSV model is referenced using CSV and an XML
	referenced using CSV and an XML namespace that is prefixed with		namespace that is prefixed with "csv". For example, the domain name
	"csv". For example, the Domain Name object represented using the CSV		object represented using the CSV model can be referred to as the CSV
	model can be referred to as the CSV Domain Name with the XML		Domain Name with the XML namespace including csvDomain
	namespace including csvDomain (urn:ietf:params:xml:ns:csvDomain-1.0).		(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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3.1. Glossary		3.1. Glossary
	In the following section, the most common terms are briefly		In the following section, the most common terms are briefly
	explained:		explained:
	o Allocated: a status of some label with respect to a zone, whereby		Allocated: A status of some label with respect to a zone, whereby
	the label is associated administratively to some entity that has		the label is associated administratively to some entity that has
	requested the label. This term (and its cognates "allocation" and		requested the label. This term (and its cognates "allocation" and
	"to allocate") may represent the first step on the way to		"to allocate") may represent the first step on the way to
	delegation in the DNS.		delegation in the DNS.
	o Comma-Separated Values (CSV), see [RFC4180].		Comma-Separated Values (CSV): See [RFC4180].
	o Domain name: see definition of Domain name in [RFC8499].		Domain Name: See the definition of Domain Name in Section 2 of
			[RFC8499].
	o Extensible Provisioning Protocol (EPP), see definition of the		Extensible Provisioning Protocol (EPP): See the definition of the
	Extensible Provisioning Protocol in [RFC8499].		Extensible Provisioning Protocol in Section 9 of [RFC8499].
	o Fully-Qualified Domain Name (FQDN), see definition of FQDN in		Fully-Qualified Domain Name (FQDN): See the definition of FQDN in
	[RFC8499].		Section 2 of [RFC8499].
	o Internationalized Domain Name (IDN), see definition of		Internationalized Domain Name (IDN): See the definition of
	Internationalized Domain Name in [RFC8499].		Internationalized Domain Name in Section 2 of [RFC8499].
	o Label: see definition of Label in [RFC8499].		Label See the definition of Label in Section 2 of [RFC8499].
	o Registrant: see definition of Registrant in [RFC8499].		Registrant: See the definition of Registrant in Section 9 of
			[RFC8499].
	o Registrar: see definition of Registrar in [RFC8499].		Registrar: See the definition of Registrar in Section 9 of
			[RFC8499].
	o Registry: see definition of Registry in [RFC8499].		Registry: See the definition of Registry in Section 9 of [RFC8499].
	o Registry-class domain name (RCDN): refers to a top-level domain		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		(TLD) or any other domain name at any level in the DNS tree for
	which a Registry (either directly or through an affiliate company)		which a registry (either directly or through an affiliate company)
	provides Registry Services for other organizations or individuals.		provides Registry Services for other organizations or individuals.
	For example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.		For example: .COM, .ORG, .BIZ, .CO.JP, .B.BR.
	o Registry Data Escrow (RDE): registry data escrow is the process by		Registry Data Escrow (RDE): Registry Data Escrow is the process by
	which a registry periodically submits data deposits to a third-		which a registry periodically submits data deposits to a third
	party called an escrow agent. These deposits comprise the minimum		party called an escrow agent. These deposits comprise the minimum
	data needed by a third-party to resume operations if the registry		data needed by a third party to resume operations if the registry
	cannot function and is unable or unwilling to facilitate an		cannot function and is unable or unwilling to facilitate an
	orderly transfer of service.		orderly transfer of service.
	o Registry services: services offered by the Registry critical to		Registry Services: Services offered by the registry critical to the
	the following tasks: the provisioning of domain names on receipt		following tasks: the provisioning of domain names on receipt of
	of requests and data from registrars; responding to registrar		requests and data from registrars; responding to registrar queries
	queries for status information relating to the DNS servers for the		for status information relating to the DNS servers for the RCDN;
	RCDN; dissemination of RCDN zone files; operation of the Registry		dissemination of RCDN zone files; operation of the registry DNS
	DNS servers; responding to queries for contact and other		servers; responding to queries for contact and other information
	information concerning DNS registrations in the RCDN; and any		concerning DNS registrations in the RCDN; and any other products
	other products or services that only a Registry is capable of		or services that only a registry is capable of providing, by
	providing, by reason of its designation as the Registry. Typical		reason of its designation as the registry. Typical examples of
	examples of Registry Services are DNS resolution for the RCDN,		Registry Services are DNS resolution for the RCDN, WHOIS, and EPP.
	WHOIS and EPP.
	o SRS: Shared Registration System, see also		SRS: Shared Registration System, see also [ICANN-GTLD-AGB-20120604].
	[ICANN-GTLD-AGB-20120604].
	o Top-Level Domain Name (TLD), see definition of Top-Level Domain in		Top-Level Domain Name (TLD): See the definition of Top-Level Domain
	[RFC8499].		in Section 2 of [RFC8499].
	o UTC: Coordinated Universal Time, as maintained by the Bureau		UTC: Coordinated Universal Time, as maintained by the Bureau
	International des Poids et Mesures (BIPM); see also [RFC3339].		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.
	4.2. Country names		4.2. Country Names
	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 0x2B), followed by a country code defined in		sign ("+", ASCII value 0x2B), followed by a country code defined in
	[ITU-E164], followed by a dot (".", ASCII value 0x2E), followed by a		[ITU-E164], followed by a dot (".", ASCII value 0x2E), followed by a
	sequence of digits representing the telephone number.		sequence of digits representing the telephone number.
	4.4. CSV Integrity Check		4.4. CSV Integrity Check
	A checksum MAY be used to verify the integrity of the CSV files, for		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		example, if another layer (i.e., encryption of an archive containing
	the deposit files) does not provide integrity. By default the CRC32		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,		algorithm (see Section 8.1.1.6.2 of [V42]) is used. A stronger
	such as SHA-256 (see, [RFC6234]) MAY be used for enhanced security if		algorithm, such as SHA-256 (see [RFC6234]) MAY be used for enhanced
	required.		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 [RFC5952].		Version 6 [RFC5952].
	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
	The CSV model represents a relational model, where the CSV files		The CSV model represents a relational model where the CSV files
	represent relational tables, the fields of the CSV files represent		represent relational tables, the fields of the CSV files represent
	columns of the tables, and each line of the CSV file represents a		columns of the tables, and each line of the CSV file represents a
	record. As in a relational model, the CSV files can have		record. As in a relational model, the CSV files can have
	relationships utilizing primary keys in the parent CSV file		relationships utilizing primary keys in the parent CSV file
	definitions and foreign keys in the child CSV file definitions for a		definitions and foreign keys in the child CSV file definitions for a
	1-to-many relationship. The primary keys are not explicitly defined,		one-to-many relationship. The primary keys are not explicitly
	but the foreign keys are using the boolean "parent" field attribute		defined, but the foreign keys are using the boolean "parent" field
	in the child CSV file. The relationships between the CSV files are		attribute in the child CSV file. The relationships between the CSV
	used to support a cascade replace or cascade delete of records		files are used to support a cascade replace or cascade delete of
	starting from the parent record in Differential and Incremental		records starting from the parent record in Differential and
	Deposits (see [I-D.ietf-regext-data-escrow]).		Incremental Deposits (see [RFC8909]).
	The following is an example of the CSV file definitions, using the		The following is an example of the CSV file definitions, using the
	element <rdeCsv:csv> (see Section 4.6.2.1), for a Sample object		element <rdeCsv:csv> (see Section 4.6.2.1), for a Sample object
	consisting of a parent "sample" CSV File Definition and a child		consisting of a parent "sample" CSV File Definition and a child
	"sampleStatuses" CSV File Definition. The primary key for the Sample		"sampleStatuses" CSV File Definition. The primary key for the Sample
	object is the field <csvSample:fName> that is used as the foreign key		object is the field <csvSample:fName> that is used as the foreign key
	in the "sampleStatuses" CSV File Definition by specifying the		in the "sampleStatuses" CSV File Definition by specifying the
	"parent=true" attribute. If a Sample record is updated or deleted in		"parent=true" attribute. If a Sample record is updated or deleted in
	a Differential or Incremental Deposit, it should cascade replace the		a Differential or Incremental Deposit, it should cascade replace the
	data using the records included in the child "sampleStatuses" CSV		data using the records included in the child "sampleStatuses" CSV
	skipping to change at page 10, line 5 ¶		skipping to change at line 397 ¶
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="EB9C558E">		cksum="EB9C558E">
	sampleStatuses-YYYYMMDD.csv		sampleStatuses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvSample:contents>		</csvSample:contents>
	4.6.2. CSV elements		4.6.2. CSV Elements
	4.6.2.1. <rdeCsv:csv> element		4.6.2.1. <rdeCsv:csv> Element
	To support the CSV model, an element is defined for each object that		To support the CSV model, an element is defined for each object that
	substitutes for the <rde:content> element and for the <rde:delete>		substitutes for the <rde:content> element and for the <rde:delete>
	element, that contains one or more <rdeCsv:csv> elements. For		element, that contains one or more <rdeCsv:csv> elements. For
	example, the Domain Name Object (Section 5.1) defines the		example, the 'Domain Name Object' (Section 5.1) defines the
	<csvDomain:contents> element, that substitutes for the <rde:content>		<csvDomain:contents> element, that substitutes for the <rde:content>
	element, and the <csvDomain:deletes> element, that substitutes for		element, and the <csvDomain:deletes> element, that substitutes for
	the <rde:delete> element. Both the <csvDomain:contents> element and		the <rde:delete> element. Both the <csvDomain:contents> element and
	the <csvDomain:deletes> elements contain one or more <rdeCsv:csv>		the <csvDomain:deletes> elements contain one or more <rdeCsv:csv>
	elements. The <rdeCsv:csv> element has the following child elements:		elements. The <rdeCsv:csv> element has the following child elements:
	<rdeCsv:fields> Ordered list of CSV fields used in the CSV files.		<rdeCsv:fields> Ordered list of CSV fields used in the CSV files.
	There are one or more child elements that substitute for the		There are one or more child elements that substitute for the
	<rdeCsv:field> abstract element. Each element defines the format		<rdeCsv:field> abstract element. Each element defines the format
	of the CSV field contained in the CSV files. The <rdeCsv:field>		of the CSV field contained in the CSV files. The <rdeCsv:field>
	elements support the "type" attribute that defines the XML simple		elements support the "type" attribute that defines the XML simple
	data type of the field element. The <rdeCsv:field> elements		data type of the field element. The <rdeCsv:field> elements
	support the "isRequired" attribute, with a default value of		support the "isRequired" attribute, which has a default value of
	"false", when set to "true" indicates that the field must be non-		"false". When set to "true", this indicates that the field must
	empty in the CSV files and when set to "false" indicates that the		be non-empty in the CSV files, and when set to "false", this
	field MAY be empty in the CSV files. The "isRequired" attribute		indicates that the field MAY be empty in the CSV files. The
	MAY be specifically set for the field elements within the XML		"isRequired" attribute MAY be specifically set for the field
	schema and MAY be overridden when specifying the fields under the		elements within the XML schema and MAY be overridden when
	<rdeCsv:fields> element. The <rdeCsv:field> element supports an		specifying the fields under the <rdeCsv:fields> element. The
	OPTIONAL "parent" attribute that identifies the field as a		<rdeCsv:field> element supports an OPTIONAL "parent" attribute
	reference to a parent object, as defined in CSV Parent Child		that identifies the field as a reference to a parent object, as
	Relationship (Section 4.6.1). For example, the <rdeCsv:csv		defined in the 'CSV Parent Child Relationship' (Section 4.6.1).
	name="domainStatuses"> <csvDomain:fName> field SHOULD set the		For example, the <rdeCsv:csv name="domainStatuses">
	"parent" attribute to "true" to identify it as the parent domain		<csvDomain:fName> field SHOULD set the "parent" attribute to
	name of the domain status.		"true" to identify it as the parent domain 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. For example, setting		attribute defines the compression format. For example, setting
	this attribute to "gzip" signals that the CSV file is		this attribute to "gzip" signals that the CSV file is
	compressed using the GZIP file format (see, [RFC1952]). The		compressed using the GZIP file format (see [RFC1952]). The
	supported compression formats are negotiated out-of-band.		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, as described in		cksum Defines the checksum of the CSV file, as described in
	Section 4.4, using the algorithm defined by the "cksumAlg"		Section 4.4, using the algorithm defined by the "cksumAlg"
	attribute. If the "cksumAlg" attribute is not present, the		attribute. If the "cksumAlg" attribute is not present, the
	checksum is calculated using "CRC32".		checksum is calculated using "CRC32".
	cksumAlg Defines the checksum algorithm used to calculate the		cksumAlg Defines the checksum algorithm used to calculate the
	"cksum" attribute, with the default value of "CRC32". If the		"cksum" attribute, with the default value of "CRC32". If the
	value "SHA256" is specified, the SHA-256 algorithm (see,		value "SHA256" is specified, the SHA-256 algorithm (see
	[RFC6234]) MUST be used to calculate the "cksum" attribute.		[RFC6234]) MUST be used to calculate the "cksum" attribute.
	Parties receiving and processing data escrow deposits MUST		Parties receiving and processing data escrow deposits MUST
	support CRC32 and SHA-256. If this attribute is present, the		support CRC32 and SHA-256. If this attribute is present, the
	"cksum" attribute MUST also be present. Additional checksum		"cksum" attribute MUST also be present. Additional checksum
	algorithms are negotiated out-of-band.		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 ",". The need for		character with the default separator character of ",". The need for
	quoting/escaping of the CSV data could be avoided by choosing a		quoting or escaping of the CSV data could be avoided by choosing a
	separator character that is not in the data set of the CSV files.		separator character that is not in the data set of the CSV files.
	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".
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domain" sep=",">		<rdeCsv:csv name="domain" sep=",">
	<rdeCsv:fields>		<rdeCsv:fields>
	skipping to change at page 12, line 37 ¶		skipping to change at line 500 ¶
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="75E2D01F">		cksum="75E2D01F">
	domain-YYYYMMDD.csv		domain-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	The following is example of the "domain-YYYYMMDD.csv" file with one		The following is an example of the domain-YYYYMMDD.csv file with one
	record matching the <rdeCsv:fields> definition.		record matching the <rdeCsv:fields> definition.
	domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,		domain1.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,
	clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,		clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
	2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z		2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
	The following is an example of the <csvDomain:deletes> <rdeCsv:csv>		The following is an example of the <csvDomain:deletes> <rdeCsv:csv>
	element for domain name records.		element for domain name records.
	<csvDomain:deletes>		<csvDomain:deletes>
	...		...
	<rdeCsv:csv name="domain">		<rdeCsv:csv name="domain">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName/>		<csvDomain:fName/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	skipping to change at page 13, line 23 ¶		skipping to change at line 526 ¶
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="6F2B988F">		cksum="6F2B988F">
	domain-delete-YYYYMMDD.csv		domain-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:deletes>		</csvDomain:deletes>
	The following is example of the "domain-delete-YYYYMMDD.csv" file		The following is example of the domain-delete-YYYYMMDD.csv file with
	with three records that matches the single <csvDomain:fName> field.		three records that matches the single <csvDomain:fName> field.
	domain1.example		domain1.example
	domain2.example		domain2.example
	domainN.example		domainN.example
	4.6.2.2. CSV common field elements		4.6.2.2. CSV Common Field Elements
	The <rdeCsv:fields> element defined in the <rdeCsv:csv> element		The <rdeCsv:fields> element defined in the '<rdeCsv:csv> Element'
	(Section 4.6.2.1) section has child elements that substitute for the		(Section 4.6.2.1) has child elements that substitute for the abstract
	abstract <rdeCsv:field> element. By convention <rdeCsv:field>		<rdeCsv:field> element. By convention, <rdeCsv:field> elements
	elements include an 'f' prefix to identify them as field definition		include an "f" prefix to identify them as field definition elements.
	elements. There are a set of common field elements that are used		There are a set of common field elements that are used across
	across multiple data escrow objects. The common field elements are		multiple data escrow objects. The common field elements are defined
	defined using the "urn:ietf:params:xml:ns:rdeCsv-1.0" namespace and		using the "urn:ietf:params:xml:ns:rdeCsv-1.0" namespace and using the
	using the "rdeCsv" sample namespace prefix. The CSV common field		"rdeCsv" sample namespace prefix. The CSV common field elements
	elements include:		include:
	<rdeCsv:fUName> UTF-8 encoded name field with		<rdeCsv:fUName> UTF-8 encoded name field with
	type="eppcom:labelType".		type="eppcom:labelType".
	<rdeCsv:fRoid> Repository Object IDentifier (ROID) field with		<rdeCsv:fRoid> Repository Object IDentifier (ROID) field with
	type="eppcom:roidType" and isRequired="true".		type="eppcom:roidType" and isRequired="true".
	<rdeCsv:fRegistrant> Registrant contact identifier with		<rdeCsv:fRegistrant> Registrant contact identifier with
	type="eppcom:clIDType".		type="eppcom:clIDType".
	<rdeCsv:fStatusDescription> The object status description, which is		<rdeCsv:fStatusDescription> The object status description, which is
	free form text describing the rationale for the status, with		free-form text describing the rationale for the status, with
	type="normalizedString".		type="normalizedString".
	<rdeCsv:fClID> Identifier of the client (registrar) that sponsors		<rdeCsv:fClID> Identifier of the client (registrar) that sponsors
	the object with type="eppcom:clIDType" and isRequired="true".		the object with type="eppcom:clIDType" and isRequired="true".
	<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,
	of the client that created the object with type="eppcom:clIDType".		of the client that created the object with type="eppcom:clIDType".
	<rdeCsv:fCrID> Identifier of the client that created the object with		<rdeCsv:fCrID> Identifier of the client that created the object with
	type="eppcom:clIDType".		type="eppcom:clIDType".
	skipping to change at page 15, line 12 ¶		skipping to change at line 609 ¶
	<rdeCsv:fTrDate> Date of last transfer with type="dateTime".		<rdeCsv:fTrDate> Date of last transfer with type="dateTime".
	<rdeCsv:fTrStatus> State of the most recent transfer request with		<rdeCsv:fTrStatus> State of the most recent transfer request with
	type="eppcom:trStatusType" and isRequired="true".		type="eppcom:trStatusType" and isRequired="true".
	<rdeCsv:fTokenType> General token field with type="token".		<rdeCsv:fTokenType> General token field with type="token".
	<rdeCsv:fLang> General language field with type="language".		<rdeCsv:fLang> General language field with type="language".
	<rdeCsv:fIdnTableId> IDN Table Identifier used for IDN domain names		<rdeCsv:fIdnTableId> IDN table identifier used for IDN domain names
	with type="token".		with type="token".
	<rdeCsv:fPositiveIntegerType> General positive integer field with		<rdeCsv:fPositiveIntegerType> General positive integer field with
	type="positiveInteger".		type="positiveInteger".
	<rdeCsv:fUrl> Contains the URL of an object like a registrar object		<rdeCsv:fUrl> Contains the URL of an object like a registrar object
	with type="anyURI".		with type="anyURI".
	<rdeCsv:fCustom> Custom field with name attribute that defines the		<rdeCsv:fCustom> Custom field with name attribute that defines the
	custom field name" with type="token".		custom field name with type="token".
	4.6.3. Internationalized and Localized Elements		4.6.3. Internationalized and Localized Elements
	Some elements MAY be provided in either internationalized form		Some elements MAY be provided in either internationalized form
	("int") or localized form ("loc"). Those elements use a field value		("int") or localized form ("loc"). Those elements use a field value
	or "isLoc" attribute to specify the form used. If an "isLoc"		or "isLoc" attribute to specify the form used. If an "isLoc"
	attribute is used, a value of "true" indicates the use of the		attribute is used, a value of "true" indicates the use of the
	localized form and a value of "false" indicates the use of the		localized form, and a value of "false" indicates the use of the
	internationalized form. This MAY override the form specified for a		internationalized form. This MAY override the form specified for a
	parent element. A value of "int" is used to indicate the		parent element. A value of "int" is used to indicate the
	internationalized form and a value of "loc" is used to indicate the		internationalized form, and a value of "loc" is used to indicate the
	localized form. When the internalized form ("int") is provided, the		localized form. When the internalized form ("int") is provided, the
	field value MUST be represented in a subset of UTF-8 that can be		field value MUST be represented in a subset of UTF-8 that can be
	represented in the 7-bit US-ASCII character set. When the localized		represented in the 7-bit US-ASCII character set. When the localized
	form ("loc") is provided, the field value MAY be represented in		form ("loc") is provided, the field value MAY be represented in
	unrestricted UTF-8.		unrestricted UTF-8.
	The field elements below of the "registrar" <rdeCsv:csv">		The field elements below of the "registrar" <rdeCsv:csv>
	<rdeCsv:fields> element specify the internationalized form with the		<rdeCsv:fields> element specify the internationalized form with the
	isLoc="false" attribute.		isLoc="false" attribute.
	...		...
	<csvRegistrar:contents>		<csvRegistrar:contents>
	...		...
	<rdeCsv:csv name="registrar" sep=",">		<rdeCsv:csv name="registrar" sep=",">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvRegistrar:fId/>		<csvRegistrar:fId/>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	skipping to change at page 17, line 46 ¶		skipping to change at line 724 ¶
	5. Object Description		5. Object Description
	This section describes the base objects supported by this		This section describes the base objects supported by this
	specification:		specification:
	5.1. Domain Name Object		5.1. Domain Name Object
	The domain name object is based on the EPP domain name mapping		The domain name object is based on the EPP domain name mapping
	specified in [RFC5731]. The domain name object supports both the XML		specified in [RFC5731]. The domain name object supports both the XML
	Model and the CSV Model, defined in the Models (Section 2) section.		model and the CSV model, defined in 'Models' (Section 2). The
	The elements used for both models are defined in the following		elements used for both models are defined in the following sections.
	sections.
	5.1.1. XML Model		5.1.1. XML Model
	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> element,
	<rde:contents> element, and the <rdeDomain:delete> element, under the		under the <rde:contents> element, and the <rdeDomain:delete> element,
	<rde:deletes> element.		under the <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], Registry Grace Period (RGP) status from [RFC3915], and		[RFC5731], Registry Grace Period (RGP) status from [RFC3915], and
	data from the EPP <secDns:create> command, see Section 5.2.1. of		data from the EPP <secDNS:create> command, see Section 5.2.1 of
	[RFC5910].		[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 create 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		* 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		* A <roid> element that contains the ROID assigned to the domain
	assigned to the domain name object when it was created.		name object when it was created.
	o An OPTIONAL <uName> element that contains the fully-qualified		* An OPTIONAL <uName> element that contains the FQDN in the Unicode
	domain name in Unicode character set. It MUST be provided if		character set. It MUST be provided if available.
	available.
	o An OPTIONAL <idnTableId> element that references the IDN		* An OPTIONAL <idnTableId> element that references the IDN table
	Table used for the IDN. This corresponds to the "id" attribute of		used for the IDN. This corresponds to the "id" attribute of the
	the <idnTableRef> element. This element MUST be present if the		<idnTableRef> element. This element MUST be present if the domain
	domain name is an IDN.		name is an IDN.
	o An OPTIONAL <originalName> element is used to indicate that the		* 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
	name used to generate the IDN variant.		name used to generate the IDN variant.
	o One or more <status> elements that contain the current status		* One or more <status> elements that contain the current status
	descriptors associated with the domain name.		descriptors associated with the domain name.
	o Zero or more OPTIONAL <rgpStatus> elements to represent		* Zero or more OPTIONAL <rgpStatus> elements to represent
	"pendingDelete" sub-statuses, including "redemptionPeriod",		"pendingDelete" sub-statuses, including "redemptionPeriod",
	"pendingRestore", and "pendingDelete", that a domain name can be		"pendingRestore", and "pendingDelete", that a domain name can be
	in as a result of grace period processing as specified in		in as a result of grace period processing as specified in
	[RFC3915].		[RFC3915].
	o An OPTIONAL <registrant> element that contains the identifier for		* An OPTIONAL <registrant> element that contains the identifier for
	the human or organizational social information object associated		the human or the organizational social information object
	as the holder of the domain name object.		associated with the holder of the domain name object.
	o Zero or more OPTIONAL <contact> elements that contain identifiers		* 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		* 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		* A <clID> element that contains the identifier of the sponsoring
	registrar.		registrar.
	o An OPTIONAL <crRr> element that contains the identifier of the		* 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
	attribute is used to specify the client that performed the		"client" attribute is used to specify the client that performed
	operation.		the operation.
	o An OPTIONAL <crDate> element that contains the date and time of		* An OPTIONAL <crDate> element that contains the date and time of
	the domain name object creation. This element MUST be present if		the domain name object creation. This element MUST be present if
	the domain name has been allocated.		the domain name has been allocated.
	o An OPTIONAL <exDate> element that contains the date and time		* An OPTIONAL <exDate> element that contains the date and time
	identifying the end (expiration) of the domain name object's		identifying the end (expiration) of the domain name object's
	registration period. This element MUST be present if the domain		registration period. This element MUST be present if the domain
	name has been allocated.		name has been allocated.
	o An OPTIONAL <upRr> element that contains the identifier of the		* An OPTIONAL <upRr> element that contains the identifier of the
	registrar that last updated the domain name object. This element		registrar that last updated the domain name object. This element
	MUST NOT be present if the domain has never been modified. An		MUST NOT be present if the domain has never been modified. An
	OPTIONAL client attribute is used to specify the client that		OPTIONAL "client" attribute is used to specify the client that
	performed the operation.		performed the operation.
	o An OPTIONAL <upDate> element that contains the date and time of		* An OPTIONAL <upDate> element that contains the date and time of
	the most recent domain-name-object modification. This element		the most recent modification of the domain name object. This
	MUST NOT be present if the domain name object has never been		element MUST NOT be present if the domain name object has never
	modified.		been modified.
	o An OPTIONAL <secDNS> element that contains the public key		* An OPTIONAL <secDNS> element that contains the public key
	information associated with Domain Name System security (DNSSEC)		information associated with Domain Name System security (DNSSEC)
	extensions for the domain name as specified in [RFC5910].		extensions for the domain name as specified in [RFC5910].
	o An OPTIONAL <trDate> element that contains the date and time of		* An OPTIONAL <trDate> element that contains the date and time of
	the most recent domain name object successful transfer. This		the most recent successful transfer of a domain name object. This
	element MUST NOT be present if the domain name object has never		element MUST NOT be present if the domain name object has never
	been transferred.		been transferred.
	o An OPTIONAL <trnData> element that contains the following child		* An OPTIONAL <trnData> element that contains the following child
	elements related to the last transfer request of the domain name		elements related to the last transfer request of the domain name
	object. This element MUST NOT be present if a transfer request		object. This element MUST NOT be present if a transfer request
	for the domain name has never been created.		for the domain name has never been created.
	* A <trStatus> element that contains the state of the most recent		- A <trStatus> element that contains the state of the most recent
	transfer request.		transfer request.
	* A <reRr> element that contains the identifier of the registrar		- A <reRr> element that contains the identifier of the registrar
	that requested the domain name object transfer. An OPTIONAL		that requested the domain name object transfer. An OPTIONAL
	client attribute is used to specify the client that performed		"client" attribute is used to specify the client that performed
	the operation.		the operation.
	* A <reDate> element that contains the date and time that the		- A <reDate> element that contains the date and time that the
	transfer was requested.		transfer was requested.
	* An <acRr> element that contains the identifier of the registrar		- An <acRr> element that contains the identifier of the registrar
	that should act upon a PENDING transfer request. For all other		that should act upon a pending transfer request. For all other
	status types, the value identifies the registrar that took the		status types, the value identifies the registrar that took the
	indicated action. An OPTIONAL client attribute is used to		indicated action. An OPTIONAL "client" attribute is used to
	specify the client that performed the operation.		specify the client that performed the operation.
	* An <acDate> element that contains the date and time of a		- An <acDate> element that contains the date and time of a
	required or completed response. For a PENDING request, the		required or completed response. For a pending request, the
	value identifies the date and time by which a response is		value identifies the date and time by which a response is
	required before an automated response action will be taken by		required before an automated response action will be taken by
	the registry. For all other status types, the value identifies		the registry. For all other status types, the value identifies
	the date and time when the request was completed.		the date and time when the request was completed.
	* An OPTIONAL <exDate> element that contains the end of the		- An OPTIONAL <exDate> element that contains the end of the
	domain name object's validity period (expiry date) if the		domain name object's validity period (expiry date) if the
	transfer caused or causes a change in the validity period.		transfer caused or causes a change in the validity period.
	Example of a domain name object:		The following is an example of a domain name object:
	...		...
	<rdeDomain:domain>		<rdeDomain:domain>
	<rdeDomain:name>xn--exampl-gva.example</rdeDomain:name>		<rdeDomain:name>xn--exampl-gva.example</rdeDomain:name>
	<rdeDomain:roid>Dexample1-TEST</rdeDomain:roid>		<rdeDomain:roid>Dexample1-TEST</rdeDomain:roid>
	<rdeDomain:idnTableId>pt-BR</rdeDomain:idnTableId>		<rdeDomain:idnTableId>pt-BR</rdeDomain:idnTableId>
	<rdeDomain:originalName>example.example</rdeDomain:originalName>		<rdeDomain:originalName>example.example</rdeDomain:originalName>
	<rdeDomain:status s="ok"/>		<rdeDomain:status s="ok"/>
	<rdeDomain:registrant>jd1234</rdeDomain:registrant>		<rdeDomain:registrant>jd1234</rdeDomain:registrant>
	<rdeDomain:contact type="admin">sh8013</rdeDomain:contact>		<rdeDomain:contact type="admin">sh8013</rdeDomain:contact>
	skipping to change at page 21, line 28 ¶		skipping to change at line 885 ¶
	<domain:hostObj>ns1.example.com</domain:hostObj>		<domain:hostObj>ns1.example.com</domain:hostObj>
	<domain:hostObj>ns1.example1.example</domain:hostObj>		<domain:hostObj>ns1.example1.example</domain:hostObj>
	</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>2025-04-03T22:00:00.0Z</rdeDomain:exDate>		<rdeDomain:exDate>2025-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 FQDN that was deleted and
	name that was deleted and purged.		purged.
	Example of <rdeDomain:delete> object:		The following is an example of an <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>
	</rdeDomain:delete>		</rdeDomain:delete>
	...		...
	</rde:deletes>		</rde:deletes>
	...		...
	5.1.2. CSV Model		5.1.2. CSV Model
	For the CSV Model of the domain name object, the <csvDomain:contents>		For the CSV model of the domain name object, the <csvDomain:contents>
	child element of the <rde:contents> element is used to hold the new		child element of the <rde:contents> element is used to hold the new
	or updated domain name objects for the deposit. The		or updated domain name objects for the deposit. The
	<csvDomain:deletes> child element of the <rde:deletes> element is		<csvDomain:deletes> child element of the <rde:deletes> element is
	used to hold the deleted or purged domain name objects for the		used to hold the deleted or purged domain name objects for the
	deposit. Both the <csvDomain:contents> and <csvDomain:deletes>		deposit. Both the <csvDomain:contents> and <csvDomain:deletes>
	elements contain one or more <rdeCsv:csv> elements with a set of		elements contain one or more <rdeCsv:csv> elements with a set of
	named CSV file definitions using the <rdeCsv:csv> "name" attribute.		named CSV file definitions using the <rdeCsv:csv> "name" attribute.
	Differential and Incremental Deposits are based on changes to the		Differential and Incremental Deposits are based on changes to the
	domain name objects. The updated domain name object data under the		domain name objects. The updated domain name object data under the
	<csvDomain:contents> element is a cascade replace down all of the		<csvDomain:contents> element is a cascade replace down all of the
	domain name CSV files starting with the parent "domain" CSV File		domain name CSV files starting with the parent '"domain" CSV File
	Definition (Section 5.1.2.1.1). The child CSV file definitions		Definition' (Section 5.1.2.1.1). The child CSV file definitions
	include a <csvDomain:fName parent="true"> field. All the child CSV		include a <csvDomain:fName parent="true"> field. All the child CSV
	file definition data for the domain name objects in the parent		file definition data for the domain name objects in the parent
	"domain" CSV File Definition (Section 5.1.2.1.1) MUST first be		'"domain" CSV File Definition' (Section 5.1.2.1.1) MUST first be
	deleted and then set using the data in the child CSV files. The		deleted and then set using the data in the child CSV files. The
	deleted domain name object data under the <csvDomain:deletes> element		deleted domain name object data under the <csvDomain:deletes> element
	is a cascade delete starting from the "domain" Deletes CSV File		is a cascade delete starting from the '"domain" Deletes CSV File
	Definition (Section 5.1.2.2.1).		Definition' (Section 5.1.2.2.1).
	5.1.2.1. <csvDomain:contents>		5.1.2.1. <csvDomain:contents>
	The <csvDomain:contents> is used to hold the new or updated domain		The <csvDomain:contents> is used to hold the new or updated domain
	name object information for the deposit. The <csvDomain:contents> is		name object information for the deposit. The <csvDomain:contents> is
	split into separate CSV file definitions using named <rdeCsv:csv>		split into separate CSV file definitions using named <rdeCsv:csv>
	elements with the "name" attribute. The following sections include		elements with the "name" attribute. The following sections include
	the supported domain name CSV file definitions:		the supported domain name CSV file definitions.
	5.1.2.1.1. "domain" CSV File Definition		5.1.2.1.1. "domain" CSV File Definition
	The "domain" CSV File Definition defines the fields and CSV file		The "domain" CSV File Definition defines the fields and CSV file
	references used for the parent domain name object records. All the		references used for the parent domain name object records. All the
	other domain name CSV file definitions are child CSV files based on		other domain name CSV file definitions are child CSV files based on
	the inclusion of the <csvDomain:fName parent="true"> field.		the inclusion of the <csvDomain:fName parent="true"> field.
	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> ROID for the domain name object with
	object with isRequired="true".		isRequired="true".
	<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of:		<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of the following:
	<rdeCsv:fClID> Identifier of the sponsoring client with		<rdeCsv:fClID> Identifier of the sponsoring client with
	isRequired="true".		isRequired="true".
	<csvRegistrar:fGurid> Contains the Globally Unique Registrar		<csvRegistrar:fGurid> Contains the Globally Unique Registrar
	Identifier (GURID) assigned by ICANN with		Identifier (GURID) assigned by ICANN with
	type="positiveInteger" and isRequired="true".		type="positiveInteger" and isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "domain" <rdeCsv:csv>		(Section 4.6.2.2), MAY be used in the "domain" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,
	of the client that created the domain name object.		of the client that created the domain name object.
	<rdeCsv:fCrID> Identifier of the client that created the domain name		<rdeCsv:fCrID> Identifier of the client that created the domain name
	object.		object.
	<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,
	of the client that last updated the domain name object.		of the client that last updated the domain name object.
	<rdeCsv:fUpID> Identifier of the client that last updated the domain		<rdeCsv:fUpID> Identifier of the client that last updated the domain
	name object.		name object.
	<rdeCsv:fUName> UTF8 encoded domain name for the <csvDomain:fName>		<rdeCsv:fUName> UTF-8 encoded domain name for the <csvDomain:fName>
	field element.		field element.
	<rdeCsv:fIdnTableId> IDN Table Identifier used for the IDN domain		<rdeCsv:fIdnTableId> IDN table identifier used for the IDN domain
	name object that MUST match a <rdeCsv:fIdnTableId> field element		name object that MUST match an <rdeCsv:fIdnTableId> field element
	in the "idnLanguage" CSV files, as defined in Section 5.5.2.		in the "idnLanguage" CSV files, as defined in Section 5.5.2.
	<rdeCsv:fRegistrant> Registrant contact identifier for the domain		<rdeCsv:fRegistrant> Registrant contact identifier for the domain
	name object.		name object.
	<rdeCsv:fCrDate> Created date and time of the domain name object.		<rdeCsv:fCrDate> Date and time of the domain name object creation.
	<rdeCsv:fUpDate> Date and time of the last update to the domain name		<rdeCsv:fUpDate> Date and time of the last update to the domain name
	object. This field MUST NOT be set if the domain name object has		object. This field MUST NOT be set if the domain name object has
	never been modified.		never been modified.
	<rdeCsv:fExDate> Expiration date and time for the domain name		<rdeCsv:fExDate> Expiration date and time for the domain name
	object.		object.
	<rdeCsv:fTrDate> Date and time of the last transfer for the domain		<rdeCsv:fTrDate> Date and time of the last transfer for the domain
	name object. This field MUST NOT be set if the domain name object		name object. This field MUST NOT be set if the domain name object
	has never been transferred.		has never been transferred.
	Example of a "domain" <csvDomain:contents> <rdeCsv:csv> element.		The following is an example of a "domain" <csvDomain:contents>
			<rdeCsv:csv> element.
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domain">		<rdeCsv:csv name="domain">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName/>		<csvDomain:fName/>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	<rdeCsv:fIdnTableId/>		<rdeCsv:fIdnTableId/>
	<csvDomain:fOriginalName/>		<csvDomain:fOriginalName/>
	skipping to change at page 25, line 5 ¶		skipping to change at line 1042 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="5E403BD6">		cksum="5E403BD6">
	domain-YYYYMMDD.csv		domain-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domain-YYYYMMDD.csv file. The file		The following is an example of the corresponding domain-YYYYMMDD.csv
	contains four records (two active ASCII domains, original IDN with		file. The file contains four records (two active ASCII domains,
	LANG-1 language rules, and variant IDN with LANG-1 language rules).		original IDN with LANG-1 language rules, and variant IDN with LANG-1
			language rules).
	domain1.example,Ddomain1-TEST,,,registrantid,registrarX,registrarX,		domain1.example,Ddomain1-TEST,,,registrantid,registrarX,registrarX,
	clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,		clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
	2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z		2009-12-03T09:05:00.0Z,2025-04-03T22:00:00.0Z
	domain2.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,		domain2.example,Ddomain2-TEST,,,registrantid,registrarX,registrarX,
	clientY,1999-04-03T22:00:00.0Z,registrarX,clientY,		clientY,1999-04-03T22:00:00.0Z,registrarX,clientY,
	2009-12-03T09:05:00.0Z,2025-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,		xn--bc123-3ve.example,Dxnabc123-TEST,LANG-1,,registrantid,registrarX,
	registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,		registrarX,clientY,2009-04-03T22:00:00.0Z,registrarX,clientY,
	2009-12-03T09:05:00.0Z,2025-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,		xn--bc321-3ve.example,Dxnabc321-TEST,LANG-1,xn--bc123-3ve.example,
	registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z,		registrantid,registrarX,registrarX,clientY,2009-04-03T22:00:00.0Z,
	registrarX,clientY,2009-12-03T09:05:00.0Z,2025-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		5.1.2.1.2. "domainContacts" CSV File Definition
	The "domainContacts" CSV File Definition defines the fields and CSV		The "domainContacts" CSV File Definition defines the fields and CSV
	file references used for the domain name object link records to		file references used for the domain name object link records to
	contact objects, as described in Contact Object (Section 5.3).		contact objects, as described in 'Contact Object' (Section 5.3).
	The following "csvDomain" field elements, defined for the "domain"		The following "csvDomain" field elements, defined for the '"domain"
	CSV File Definition (Section 5.1.2.1.1), MUST be used in the		CSV File Definition' (Section 5.1.2.1.1), MUST be used in the
	"domainContacts" <rdeCsv:csv> <rdeCsv:fields> element:		"domainContacts" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fName> The name of the domain object that is linked to		<csvDomain:fName> The name of the domain object that is linked to
	the contact object with isRequired="true".		the contact object with isRequired="true".
	<csvDomain:fContactType> The contact type for the contact object		<csvDomain:fContactType> The contact type for the contact object
	link with type="domain:contactAttrType" and isRequired="true".		link with type="domain:contactAttrType" and isRequired="true".
	The supported contact type values include "admin" for the		The supported contact type values include "admin" for the
	administration contact, "billing" for the billing contact, and		administration contact, "billing" for the billing contact, and
	"tech" for the technical contact.		"tech" for the technical contact.
	The following "csvContact" fields, defined for the "contact" CSV File		The following "csvContact" fields, defined for the '"contact" CSV
	Definition (Section 5.3.2.1.1), MUST be used in the "domainContacts"		File Definition' (Section 5.3.2.1.1), MUST be used in the
	<rdeCsv:csv> <rdeCsv:fields> element:		"domainContacts" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> The server-unique contact identifier with		<csvContact:fId> The server-unique contact identifier with
	isRequired="true".		isRequired="true".
	Example of a "domainContacts" <csvDomain:contents> <rdeCsv:csv>		The following is an example of a "domainContacts"
	element.		<csvDomain:contents> <rdeCsv:csv> element:
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domainContacts">		<rdeCsv:csv name="domainContacts">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<csvContact:fId/>		<csvContact:fId/>
	<csvDomain:fContactType/>		<csvDomain:fContactType/>
	</rdeCsv:fields>		</rdeCsv:fields>
	skipping to change at page 26, line 28 ¶		skipping to change at line 1109 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="6B976A6C">		cksum="6B976A6C">
	domainContacts-YYYYMMDD.csv		domainContacts-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domainContacts-YYYYMMDD.csv file. The		The following is an example of the corresponding domainContacts-
	file contains an admin, tech, and billing contact for the four domain		YYYYMMDD.csv file. The file contains an admin, tech, and billing
	names domain1.example, domain2.example, xn--bc123-3ve.example and		contact for the four domain names domain1.example, domain2.example,
	xn--bc321-3ve.example.		xn--bc123-3ve.example, and xn--bc321-3ve.example:
	domain1.example,domain1admin,admin		domain1.example,domain1admin,admin
	domain1.example,domain1tech,tech		domain1.example,domain1tech,tech
	domain1.example,domain1billing,billing		domain1.example,domain1billing,billing
	domain2.example,domain2admin,admin		domain2.example,domain2admin,admin
	domain2.example,domain2tech,tech		domain2.example,domain2tech,tech
	domain2.example,domain2billing,billing		domain2.example,domain2billing,billing
	xn--bc123-3ve.example,xnabc123admin,admin		xn--bc123-3ve.example,xnabc123admin,admin
	xn--bc123-3ve.example,xnabc123tech,tech		xn--bc123-3ve.example,xnabc123tech,tech
	xn--bc123-3ve.example,xnabc123billing,billing		xn--bc123-3ve.example,xnabc123billing,billing
	xn--bc321-3ve.example,xnabc123admin,admin		xn--bc321-3ve.example,xnabc123admin,admin
	xn--bc321-3ve.example,xnabc123tech,tech		xn--bc321-3ve.example,xnabc123tech,tech
	xn--bc321-3ve.example,xnabc123billing,billing		xn--bc321-3ve.example,xnabc123billing,billing
	5.1.2.1.3. "domainStatuses" CSV File Definition		5.1.2.1.3. "domainStatuses" CSV File Definition
	The "domainStatuses" CSV File Definition defines the fields and CSV		The "domainStatuses" CSV File Definition defines the fields and CSV
	file references used for the domain name object statuses.		file references used for the domain name object statuses.
	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 RGP status, as a sub-status of the		<csvDomain:fRgpStatus> The RGP status, as a sub-status of the
	<csvDomain:fStatus> "pendingDelete" status value, with		<csvDomain:fStatus> "pendingDelete" status 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 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "domainStatuses"		(Section 4.6.2.2), MAY be used in the "domainStatuses" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fStatusDescription> Domain name object status description		<rdeCsv:fStatusDescription> Domain name object status description,
	which is free form text describing the rationale for the status.		which 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.
	Example of a "domainStatuses" <csvDomain:contents> <rdeCsv:csv>		The following is an example of a "domainStatuses"
	element.		<csvDomain:contents> <rdeCsv:csv> element:
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domainStatuses">		<rdeCsv:csv name="domainStatuses">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<csvDomain:fStatus/>		<csvDomain:fStatus/>
	<rdeCsv:fStatusDescription/>		<rdeCsv:fStatusDescription/>
	<rdeCsv:fLang/>		<rdeCsv:fLang/>
	skipping to change at page 28, line 5 ¶		skipping to change at line 1179 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="98D139A3">		cksum="98D139A3">
	domainStatuses-YYYYMMDD.csv		domainStatuses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domainStatuses-YYYYMMDD.csv file. The		The following is an example of the corresponding domainStatuses-
	file contains the statuses for the four domain names domain1.example,		YYYYMMDD.csv file. The file contains the statuses for the four
	domain2.example, xn--bc123-3ve.example and xn--bc321-3ve.example.		domain names domain1.example, domain2.example, xn--bc123-3ve.example,
			and xn--bc321-3ve.example:
	domain1.example,clientUpdateProhibited,"Disallow update",		domain1.example,clientUpdateProhibited,"Disallow update",
	en,		en,
	domain1.example,clientDeleteProhibited,"Disallow delete",		domain1.example,clientDeleteProhibited,"Disallow delete",
	en,		en,
	domain2.example,ok,,,		domain2.example,ok,,,
	xn--bc123-3ve.example,ok,,,		xn--bc123-3ve.example,ok,,,
	xn--bc321-3ve.example,ok,,,		xn--bc321-3ve.example,ok,,,
	5.1.2.1.4. "domainNameServers" CSV File Definition		5.1.2.1.4. "domainNameServers" CSV File Definition
	The "domainNameServers" CSV File Definition defines the fields and		The "domainNameServers" CSV File Definition defines the fields and
	CSV file references used for the domain name delegated hosts (name		CSV file references used for the domain name delegated hosts (name
	servers). The "domainNameServers" CSV files define the relationship		servers). The "domainNameServers" CSV files define the relationship
	between a domain name object and a delegated host. The		between a domain name object and a delegated host. The
	"domainNameServers" CSV File is used to support the <domain:hostObj>		"domainNameServers" CSV File is used to support the <domain:hostObj>
	model, defined in [RFC5731].		model, defined in [RFC5731].
	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		Definition' (Section 5.1.2.1.1), MUST be used in the
	"domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:		"domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fName> Domain name using the delegated host with		<csvDomain:fName> Domain name using the delegated host with
	isRequired="true".		isRequired="true".
	The following "csvHost" and "rdeCsv" field elements MUST be used in		The following "csvHost" and "rdeCsv" field elements MUST be used in
	the "domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:		the "domainNameServers" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvHost:fName> or <rdeCsv:fRoid> A choice of:		<csvHost:fName> or <rdeCsv:fRoid> A choice of the following:
	<csvHost:fName> Host name field with type="eppcom:labelType" and		<csvHost:fName> Host name field with type="eppcom:labelType" and
	isRequired="true".		isRequired="true".
	<rdeCsv:fRoid> Host object Registry Object IDentifier (ROID)		<rdeCsv:fRoid> Host object ROID assigned to the host object with
	assigned to the host object with isRequired="true".		isRequired="true".
	Example of a "domainNameServers" <csvDomain:contents> <rdeCsv:csv>		The following is an example of a "domainNameServers"
	element.		<csvDomain:contents> <rdeCsv:csv> element:
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domainNameServers">		<rdeCsv:csv name="domainNameServers">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="8FE6E9E1">		cksum="8FE6E9E1">
	domainNameServers-YYYYMMDD.csv		domainNameServers-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domainNameServers-YYYYMMDD.csv file.		The following is an example of the corresponding domainNameServers-
	The file contains the delegated hosts (name servers) for the four		YYYYMMDD.csv file. The file contains the delegated hosts (name
	domain names domain1.example, domain2.example, xn--bc123-3ve.example		servers) for the four domain names domain1.example, domain2.example,
	and xn--bc321-3ve.example referenced via the <rdeCsv:fRoid> field		xn--bc123-3ve.example, and xn--bc321-3ve.example referenced via the
	element.		<rdeCsv:fRoid> field element:
	domain1.example,Hns1_domain1_test-TEST		domain1.example,Hns1_domain1_test-TEST
	domain1.example,Hns2_domain1_test-TEST		domain1.example,Hns2_domain1_test-TEST
	domain2.example,Hns1_domain2_test-TEST		domain2.example,Hns1_domain2_test-TEST
	domain2.example,Hns2_domain2_test-TEST		domain2.example,Hns2_domain2_test-TEST
	xn--bc123-3ve.example,Hns1_example_test-TEST		xn--bc123-3ve.example,Hns1_example_test-TEST
	xn--bc123-3ve.example,Hns2_example_test-TEST		xn--bc123-3ve.example,Hns2_example_test-TEST
	xn--bc321-3ve.example,Hns1_example_test-TEST		xn--bc321-3ve.example,Hns1_example_test-TEST
	xn--bc321-3ve.example,Hns2_example_test-TEST		xn--bc321-3ve.example,Hns2_example_test-TEST
	5.1.2.1.5. "domainNameServersAddresses" CSV File Definition		5.1.2.1.5. "domainNameServersAddresses" CSV File Definition
	The "domainNameServersAddresses" CSV File Definition defines the		The "domainNameServersAddresses" CSV File Definition defines the
	fields and CSV file references used for supporting the domain host		fields and CSV file references used for supporting the domain host
	attributes model.		attributes model.
	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		Definition' (Section 5.1.2.1.1), MUST be used in the
	"domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:		"domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fName> Domain name using the delegated host with host		<csvDomain:fName> Domain name using the delegated host with host
	<csvHost:fName> and isRequired="true".		<csvHost:fName> and isRequired="true".
	The following "rdeCsv" fields, defined in section Host CSV model		The following "rdeCsv" fields, defined in 'CSV Model'
	elements (Section 5.2.2), MUST be used in the		(Section 5.2.2), MUST be used in the "domainNameServersAddresses"
	"domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvHost:fName> Host name field with type="eppcom:labelType" and		<csvHost:fName> Host name field with type="eppcom:labelType" and
	isRequired="true".		isRequired="true".
	The following "csvHost" fields, defined in section Host CSV model		The following "csvHost" fields, defined in 'CSV Model'
	elements (Section 5.2.2), MAY be used in the		(Section 5.2.2), MAY be used in the "domainNameServersAddresses"
	"domainNameServersAddresses" <rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvHost:fAddr> IP addresses associated with the host object with		<csvHost:fAddr> IP addresses associated with the host object with
	type="host:addrStringType".		type="host:addrStringType".
	<csvHost:fAddrVersion> IP addresses version associated with the host		<csvHost:fAddrVersion> IP addresses version associated with the host
	object with type="host:ipType". "host:ipType" has the enumerated		object with type="host:ipType". "host:ipType" has the enumerated
	values of "v4" or "v6".		values of "v4" or "v6".
	Example of a "domainNameServersAddresses" <csvDomain:contents>		The following is an example of a "domainNameServersAddresses"
	<rdeCsv:csv> element.		<csvDomain:contents> <rdeCsv:csv> element:
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domainNameServersAddresses">		<rdeCsv:csv name="domainNameServersAddresses">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<csvHost:fName/>		<csvHost:fName/>
	<csvHost:fAddr/>		<csvHost:fAddr/>
	<csvHost:fAddrVersion/>		<csvHost:fAddrVersion/>
	skipping to change at page 31, line 5 ¶		skipping to change at line 1311 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="D3B77438">		cksum="D3B77438">
	domainNameServersAddresses-YYYYMMDD.csv		domainNameServersAddresses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domainNameServersAddresses-YYYYMMDD.csv		The following is an example of the corresponding
	file. The file contains the delegated hosts (name servers) for the		domainNameServersAddresses-YYYYMMDD.csv file. The file contains the
	four domain names domain1.example, domain2.example, xn--		delegated hosts (name servers) for the four domain names
	bc123-3ve.example and xn--bc321-3ve.example.		domain1.example, domain2.example, xn--bc123-3ve.example, and xn--
			bc321-3ve.example:
	domain1.example,ns1.domain1.example,192.0.2.1,v4		domain1.example,ns1.domain1.example,192.0.2.1,v4
	domain1.example,ns2.domain1.example,2001:DB8::1,v6		domain1.example,ns2.domain1.example,2001:DB8::1,v6
	domain2.example,ns1.example.net,,		domain2.example,ns1.example.net,,
	domain2.example,ns2.example.net,,		domain2.example,ns2.example.net,,
	xn--bc123-3ve.example,ns1.example.net,,		xn--bc123-3ve.example,ns1.example.net,,
	xn--bc123-3ve.example,ns2.example.net,,		xn--bc123-3ve.example,ns2.example.net,,
	xn--bc321-3ve.example,ns1.example.net,,		xn--bc321-3ve.example,ns1.example.net,,
	xn--bc321-3ve.example,ns2.example.net,,		xn--bc321-3ve.example,ns2.example.net,,
	5.1.2.1.6. "dnssec" CSV File Definition		5.1.2.1.6. "dnssec" CSV File Definition
	The "dnssec" CSV File Definition defines the fields and CSV file		The "dnssec" CSV File Definition defines the fields and CSV file
	references used for the domain name object DNSSEC records (DS or Key		references used for the domain name object DNSSEC records (Delegation
	Data).		Signer (DS) or key data).
	The following "csvDomain" field elements MUST be used in the "dnssec"		The following "csvDomain" field elements MUST be used in the "dnssec"
	<rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per		<rdeCsv:csv> <rdeCsv:fields> element when the DS Data Interface per
	[RFC5910] is used:		[RFC5910] is used:
	<csvDomain:fKeyTag> Contains the DS key tag value per [RFC5910] with		<csvDomain:fKeyTag> Contains the DS key tag value per [RFC5910] with
	type="unsignedShort" and isRequired="true".		type="unsignedShort" and isRequired="true".
	<csvDomain:fDsAlg> Contains the DS algorithm value per [RFC5910]		<csvDomain:fDsAlg> Contains the DS algorithm value per [RFC5910]
	with type="unsignedByte" and isRequired="true".		with type="unsignedByte" and isRequired="true".
	skipping to change at page 31, line 50 ¶		skipping to change at line 1357 ¶
	The following "csvDomain" field elements MUST be used in the "dnssec"		The following "csvDomain" field elements MUST be used in the "dnssec"
	<rdeCsv:csv> <rdeCsv:fields> element when the Key Data Interface per		<rdeCsv:csv> <rdeCsv:fields> element when the Key Data Interface per
	[RFC5910] is used and MAY be used in the "dnssec" <rdeCsv:csv>		[RFC5910] is used and MAY be used in the "dnssec" <rdeCsv:csv>
	<rdeCsv:fields> element when the DS Data Interface per [RFC5910] is		<rdeCsv:fields> element when the DS Data Interface per [RFC5910] is
	used:		used:
	<csvDomain:fFlags> Contains the flags field value per [RFC5910] with		<csvDomain:fFlags> Contains the flags field value per [RFC5910] with
	type="unsignedShort" and isRequired="true".		type="unsignedShort" and isRequired="true".
	<csvDomain:fProtocol> Contains the Key protocol value per [RFC5910]		<csvDomain:fProtocol> Contains the key protocol value per [RFC5910]
	with type="unsignedByte" and isRequired="true".		with type="unsignedByte" and isRequired="true".
	<csvDomain:fKeyAlg> Contains the Key algorithm value per [RFC5910]		<csvDomain:fKeyAlg> Contains the key algorithm value per [RFC5910]
	with type="unsignedByte" and isRequired="true".		with type="unsignedByte" and isRequired="true".
	<csvDomain:fPubKey> Contains the public key value per [RFC5910] with		<csvDomain:fPubKey> Contains the public key value per [RFC5910] with
	type="secDNS:keyType" and isRequired="true".		type="secDNS:keyType" and isRequired="true".
	The following "csvDomain" field elements MAY be used in the "dnssec"		The following "csvDomain" field elements MAY be used in the "dnssec"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fMaxSigLife> Indicates a child's preference for the		<csvDomain:fMaxSigLife> Indicates a child's preference for the
	number of seconds after signature generation when the parent's		number of seconds after signature generation when the parent's
	signature on the DS information provided by the child will expire		signature on the DS information provided by the child will expire
	with type="secDNS:maxSigLifeType" defined in [RFC5910].		with type="secDNS:maxSigLifeType" defined in [RFC5910].
	The following "domain" fields, defined for the "domain" CSV File		The following "domain" fields, defined for the '"domain" CSV File
	Definition (Section 5.1.2.1.1), MUST be used in the "dnssec"		Definition' (Section 5.1.2.1.1), MUST be used in the "dnssec"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fName> Domain name of the domain name object associated		<csvDomain:fName> Domain name of the domain name object associated
	with the DNSSEC record and isRequired="true".		with the DNSSEC record and isRequired="true".
	Example of a "dnssec" <csvDomain:contents> <rdeCsv:csv> element with		The following is an example of a "dnssec" <csvDomain:contents>
	the DS Data Interface of [RFC5910]:		<rdeCsv:csv> element with the DS Data Interface of [RFC5910]:
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="dnssec">		<rdeCsv:csv name="dnssec">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<csvDomain:fMaxSigLife/>		<csvDomain:fMaxSigLife/>
	<csvDomain:fKeyTag/>		<csvDomain:fKeyTag/>
	<csvDomain:fDsAlg/>		<csvDomain:fDsAlg/>
	<csvDomain:fDigestType/>		<csvDomain:fDigestType/>
	skipping to change at page 33, line 5 ¶		skipping to change at line 1406 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="10ED6C42">		cksum="10ED6C42">
	dnssec-ds-YYYYMMDD.csv		dnssec-ds-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding dnssec-ds-YYYYMMDD.csv file. The file		The following is an example of the corresponding dnssec-ds-
	contains two DS records for domain1.example.		YYYYMMDD.csv file. The file contains two DS records for
			domain1.example:
	domain1.example,604800,30730,8,2,91C9B176EB////F1C46F6A55		domain1.example,604800,30730,8,2,91C9B176EB////F1C46F6A55
	domain1.example,604800,61882,8,2,9F8FEAC94B////1272AF09F3		domain1.example,604800,61882,8,2,9F8FEAC94B////1272AF09F3
	Example of a "dnssec" <csvDomain:contents> <rdeCsv:csv> element with		The following is an example of a "dnssec" <csvDomain:contents>
	the Key Data Interface of [RFC5910]:		<rdeCsv:csv> element with the Key Data Interface of [RFC5910]:
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="dnssec">		<rdeCsv:csv name="dnssec">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<csvDomain:fMaxSigLife/>		<csvDomain:fMaxSigLife/>
	<csvDomain:fFlags/>		<csvDomain:fFlags/>
	<csvDomain:fProtocol/>		<csvDomain:fProtocol/>
	<csvDomain:fKeyAlg/>		<csvDomain:fKeyAlg/>
	skipping to change at page 33, line 36 ¶		skipping to change at line 1438 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="183C3F79">		cksum="183C3F79">
	dnssec-key-YYYYMMDD.csv		dnssec-key-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding dnssec-key-YYYYMMDD.csv file. The file		The following is an example of the corresponding dnssec-key-
	contains two key records for domain1.example.		YYYYMMDD.csv file. The file contains two key records for
			domain1.example:
	domain1.example,604800,257,3,8,AwEAAZD1+z////G1jqviK8c=		domain1.example,604800,257,3,8,AwEAAZD1+z////G1jqviK8c=
	domain1.example,604800,257,3,8,AwEAAbntWP////vwDitt940=		domain1.example,604800,257,3,8,AwEAAbntWP////vwDitt940=
	5.1.2.1.7. "domainTransfer" CSV File Definition		5.1.2.1.7. "domainTransfer" CSV File Definition
	The "domainTransfer" CSV File Definition defines the fields and CSV		The "domainTransfer" CSV File Definition defines the fields and CSV
	file references used for the domain name object pending and completed		file references used for the domain name object pending and completed
	transfer records. No additional field elements were added for use in		transfer records. No additional field elements were added for use in
	the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element.		the "domainTransfer" <rdeCsv:csv> <rdeCsv:fields> element.
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "domainTransfer"		(Section 4.6.2.2), MUST be used in the "domainTransfer" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fTrStatus> State of the most recent transfer request with		<rdeCsv:fTrStatus> State of the most recent transfer request with
	isRequired="true".		isRequired="true".
	<rdeCsv:fReRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fReRr> Identifier of the registrar, defined in Section 5.4,
	of the client that requested the transfer with isRequired="true".		of the client that requested the transfer with isRequired="true".
	<rdeCsv:fReDate> Date and time that the transfer was requested with		<rdeCsv:fReDate> Date and time that the transfer was requested with
	isRequired="true".		isRequired="true".
	<rdeCsv:fAcRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fAcRr> Identifier of the registrar, defined in Section 5.4,
	of the client that should take or took action with		of the client that should take or took action with
	isRequired="true".		isRequired="true".
	<rdeCsv:fAcDate> Date and time that the transfer action should be		<rdeCsv:fAcDate> Date and time that the transfer action should be
	taken or has been taken with isRequired="true".		taken or has been taken with isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "domainTransfer"		(Section 4.6.2.2), MAY be used in the "domainTransfer" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fExDate> Expiration date if the transfer command caused or		<rdeCsv:fExDate> Expiration date if the transfer command caused or
	causes a change in the validity period.		causes a change in the validity period.
	<rdeCsv:fReID> Identifier of the client that requested the transfer.		<rdeCsv:fReID> Identifier of the client that requested the transfer.
	<rdeCsv:fAcID> Identifier of the client that should take or took		<rdeCsv:fAcID> Identifier of the client that should take or took
	action for transfer.		action for transfer.
	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 "domainTransfer"		Definition' (Section 5.1.2.1.1), MUST be used in the "domainTransfer"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvDomain:fName> Domain name of the domain name object involved in		<csvDomain:fName> Domain name of the domain name object involved in
	the transfer with isRequired="true".		the transfer with isRequired="true".
	Example of a "domainTransfer" <csvDomain:contents> <rdeCsv:csv>		The following is an example of a "domainTransfer"
	element.		<csvDomain:contents> <rdeCsv:csv> element:
	...		...
	<csvDomain:contents>		<csvDomain:contents>
	...		...
	<rdeCsv:csv name="domainTransfer">		<rdeCsv:csv name="domainTransfer">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName parent="true"/>		<csvDomain:fName parent="true"/>
	<rdeCsv:fTrStatus/>		<rdeCsv:fTrStatus/>
	<rdeCsv:fReRr/>		<rdeCsv:fReRr/>
	<rdeCsv:fReID/>		<rdeCsv:fReID/>
	skipping to change at page 35, line 34 ¶		skipping to change at line 1520 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="2E5A9ACD">		cksum="2E5A9ACD">
	domainTransfer-YYYYMMDD.csv		domainTransfer-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:contents>		</csvDomain:contents>
	...		...
	Example of the corresponding domainTransfer-YYYYMMDD.csv file. The		The following is an example of the corresponding domainTransfer-
	file contains one domain transfer record with a pending status.		YYYYMMDD.csv file. The file contains one domain transfer record with
			a pending status:
	domain1.example,pending,registrarX,clientY,		domain1.example,pending,registrarX,clientY,
	2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z,		2011-03-08T19:38:00.0Z,registrarY,,2011-03-13T23:59:59.0Z,
	2025-04-03T22:00:00.0Z		2025-04-03T22:00:00.0Z
	5.1.2.2. <csvDomain:deletes>		5.1.2.2. <csvDomain:deletes>
	The <csvDomain:deletes> is used to hold the deleted domain name		The <csvDomain:deletes> is used to hold the deleted domain name
	objects in a Differential or Incremental Deposit. All the domain		objects in a Differential or Incremental Deposit. All the domain
	name object data is deleted as part of a cascade delete. The		name object data is deleted as part of a cascade delete. The
	skipping to change at page 36, line 13 ¶		skipping to change at line 1546 ¶
	definition.		definition.
	5.1.2.2.1. "domain" Deletes CSV File Definition		5.1.2.2.1. "domain" Deletes CSV File Definition
	The following "csvDomain" field elements MUST be used in the deletes		The following "csvDomain" field elements MUST be used in the deletes
	"domain" <rdeCsv:csv> <rdeCsv:fields> element:		"domain" <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".
	Example of a "domain" <csvDomain:deletes> <rdeCsv:csv> element:		The following is an example of a "domain" <csvDomain:deletes>
			<rdeCsv:csv> element:
	...		...
	<csvDomain:deletes>		<csvDomain:deletes>
	...		...
	<rdeCsv:csv name="domain">		<rdeCsv:csv name="domain">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvDomain:fName/>		<csvDomain:fName/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="A06D8194">		cksum="A06D8194">
	domain-delete-YYYYMMDD.csv		domain-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvDomain:deletes>		</csvDomain:deletes>
	...		...
	Example of the corresponding domain-delete-YYYYMMDD.csv file. The		The following is an example of the corresponding domain-delete-
	file contains two domain name records.		YYYYMMDD.csv file. The file contains two domain name records:
	domain1.example		domain1.example
	domain2.example		domain2.example
	5.2. Host Object		5.2. Host Object
	The host object is based on the EPP host name mapping in [RFC5732].		The host object is based on the EPP host name mapping in [RFC5732].
	The host object supports both the XML Model and the CSV Model,		The host object supports both the XML model and the CSV model,
	defined in Models (Section 2) section. The elements used for both		defined in 'Models' (Section 2). The elements used for both models
	models are defined in the following sections. Both the		are defined in the following sections. Both the <csvHost:contents>
	<csvHost:contents> and <csvHost:deletes> elements contain one or more		and <csvHost:deletes> elements contain one or more <rdeCsv:csv>
	<rdeCsv:csv> elements with a set of named CSV file definitions using		elements with a set of named CSV file definitions using the
	the <rdeCsv:csv> "name" attribute.		<rdeCsv:csv> "name" attribute.
	5.2.1. XML Model		5.2.1. XML Model
	There are two elements used in the data escrow of the host objects		There are two elements used in the data escrow of the host objects
	for the XML model including the <rdeHost:host>, under the		for the XML model including the <rdeHost:host> element, under the
	<rdeHost:contents> element, and the <rdeHost:delete> element, under		<rdeHost:contents> element, and the <rdeHost:delete> element, under
	the <rde:deletes> element.		the <rde:deletes> element.
	A <rdeHost:host> element substitutes for the <rdeHost:abstractHost>		An <rdeHost:host> element substitutes for the <rdeHost:abstractHost>
	abstract element to define a concrete definition of a host. The		abstract element to create a concrete definition of a host. The
	<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		* 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		* A <roid> element that contains the ROID assigned to the host
	assigned to the host object when the object was created.		object when the object was created.
	o One or more <status> elements that describe the status of the host		* 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		* Zero or more <addr> elements that contain the IP addresses
	associated with the host object.		associated with the host object.
	o A <clID> element that contains the identifier of the sponsoring		* A <clID> element that contains the identifier of the sponsoring
	registrar.		registrar.
	o An OPTIONAL <crRr> element that contains the identifier of the		* An OPTIONAL <crRr> element that contains the identifier of the
	registrar that created the host object. An OPTIONAL client		registrar that created the host object. An OPTIONAL "client"
	attribute is used to specify the client that performed the		attribute is used to specify the client that performed the
	operation.		operation.
	o An OPTIONAL <crDate> element that contains the date and time of		* An OPTIONAL <crDate> element that contains the date and time of
	host-object creation.		host object creation.
	o An OPTIONAL <upRr> element that contains the identifier of the		* An OPTIONAL <upRr> element that contains the identifier of the
	registrar that last updated the host object. This element MUST		registrar that last updated the host object. This element MUST
	NOT be present if the host object has never been modified. An		NOT be present if the host object has never been modified. An
	OPTIONAL client attribute is used to specify the client that		OPTIONAL "client" attribute is used to specify the client that
	performed the operation.		performed the operation.
	o An OPTIONAL <upDate> element that contains the date and time of		* An OPTIONAL <upDate> element that contains the date and time of
	the most recent host-object modification. This element MUST NOT		the most recent host object modification. This element MUST NOT
	be present if the host object has never been modified.		be present if the host object has never been modified.
	o An OPTIONAL <trDate> element that contains the date and time of		* An OPTIONAL <trDate> element that contains the date and time of
	the most recent host object successful transfer. This element		the most recent host object successful transfer. This element
	MUST NOT be present if the domain name object has never been		MUST NOT be present if the domain name object has never been
	transfered.		transferred.
	Example of <host> object:		The following is an example of a <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">2001:DB8:1::1</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 FQDN of a host that was
	of a host that was deleted. The <rdeHost:delete> element also		deleted. The <rdeHost:delete> element also supports host removal
	supports host removal based on roid to support SRS systems in which		based on ROID to support SRS systems in which different hosts with
	different hosts with the same fully-qualified domain name are active		the same FQDN are active at the same time.
	at the same time.
	Example of <rdeHost:delete> object:		The following is an example of an <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>
	...		...
	</rde:deletes>		</rde:deletes>
	...		...
	5.2.2. CSV Model		5.2.2. CSV Model
	For the CSV Model of the host object, the <csvHost:contents> child		For the CSV model of the host object, the <csvHost:contents> child
	element of the <rde:contents> element is used to hold the new or		element of the <rde:contents> element is used to hold the new or
	updated host objects for the deposit. The <csvHost:deletes> child		updated host objects for the deposit. The <csvHost:deletes> child
	element of the <rde:deletes> element is used to hold the deleted or		element of the <rde:deletes> element is used to hold the deleted or
	purged host objects for the deposit.		purged host objects for the deposit.
	Differential and Incremental Deposits are based on changes to the		Differential and Incremental Deposits are based on changes to the
	host objects. The updated host object data under the		host objects. The updated host object data under the
	<csvHost:contents> element is a cascade replace down all of the host		<csvHost:contents> element is a cascade replace down all of the host
	CSV files starting with the parent "host" CSV File Definition		CSV files starting with the parent '"host" CSV File Definition'
	(Section 5.2.2.1.1). The child CSV file definitions include a		(Section 5.2.2.1.1). The child CSV file definitions include an
	<rdeCsv:fRoid parent="true"> field. All the child CSV file		<rdeCsv:fRoid parent="true"> field. All the child CSV file
	definition data for the host objects in the parent "host" CSV File		definition data for the host objects in the parent '"host" CSV File
	Definition (Section 5.2.2.1.1) MUST first be deleted and then set		Definition' (Section 5.2.2.1.1) MUST first be deleted and then set
	using the data in the child CSV files. The deleted host object data		using the data in the child CSV files. The deleted host object data
	under the <csvHost:deletes> element is a cascade delete starting from		under the <csvHost:deletes> element is a cascade delete starting from
	the "host" Deletes CSV File Definition (Section 5.2.2.2.1).		the '"host" Deletes CSV File Definition' (Section 5.2.2.2.1).
	5.2.2.1. <csvHost:contents>		5.2.2.1. <csvHost:contents>
	The <csvHost:contents> is used to hold the new or updated host object		The <csvHost:contents> is used to hold the new or updated host object
	information for the deposit. The <csvHost:contents> is split into		information for the deposit. The <csvHost:contents> is split into
	separate CSV file definitions using named <rdeCsv:csv> elements with		separate CSV file definitions using named <rdeCsv:csv> elements with
	the "name" attribute. The following sections include the supported		the "name" attribute. The following sections include the supported
	host CSV file definitions.		host CSV file definitions.
	5.2.2.1.1. "host" CSV File Definition		5.2.2.1.1. "host" CSV File Definition
	The "host" CSV File Definition defines the fields and CSV file		The "host" CSV File Definition defines the fields and CSV file
	references used for the host object records.		references used for the host object records.
	The following "csvHost" field elements MUST be used in the "host"		The following "csvHost" field elements MUST be used in the "host"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvHost:fName> Host name field with type="eppcom:labelType" and		<csvHost:fName> Host name field with type="eppcom:labelType" and
	isRequired="true".		isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv>		(Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fRoid> Repository Object IDentifier (ROID) assigned to the		<rdeCsv:fRoid> ROID assigned to the host object with
	host object with isRequired="true".		isRequired="true".
	The following "rdeCsv" and "csvRegistrar" fields, MAY be used in the		The following "rdeCsv" and "csvRegistrar" fields MAY be used in the
	"host" <rdeCsv:csv> <rdeCsv:fields> element:		"host" <rdeCsv:csv> <rdeCsv:fields> element:
	<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of:		<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of the following:
	<rdeCsv:fClID> Identifier of the sponsoring client with		<rdeCsv:fClID> Identifier of the sponsoring client with
	isRequired="true".		isRequired="true".
	<csvRegistrar:fGurid> Contains the Globally Unique Registrar		<csvRegistrar:fGurid> Contains the GURID assigned by ICANN with
	Identifier (GURID) assigned by ICANN with
	type="positiveInteger" and isRequired="true".		type="positiveInteger" and isRequired="true".
	<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,
	of the client that created the host object.		of the client that created the host object.
	<rdeCsv:fCrID> Identifier of the client that created the host		<rdeCsv:fCrID> Identifier of the client that created the host
	object.		object.
	<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,
	of the client that last updated the host object.		of the client that last updated the host object.
	skipping to change at page 41, line 5 ¶		skipping to change at line 1757 ¶
	<rdeCsv:fCrDate> Date and time that the host object was created.		<rdeCsv:fCrDate> Date and time that the host object was created.
	<rdeCsv:fUpDate> Date and time that the host object was last		<rdeCsv:fUpDate> Date and time that the host object was last
	updated. This field MUST NOT be set if the domain name object has		updated. This field MUST NOT be set if the domain name object has
	never been modified.		never been modified.
	<rdeCsv:fTrDate> Date and time that the host object was last		<rdeCsv:fTrDate> Date and time that the host object was last
	transferred. This field MUST NOT be set if the domain name object		transferred. This field MUST NOT be set if the domain name object
	has never been transferred.		has never been transferred.
	Example of a "host" <csvHost:contents> <rdeCsv:csv> element.		The following is an example of a "host" <csvHost:contents>
			<rdeCsv:csv> element:
	...		...
	<csvHost:contents>		<csvHost:contents>
	...		...
	<rdeCsv:csv name="host">		<rdeCsv:csv name="host">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvHost:fName/>		<csvHost:fName/>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	<rdeCsv:fClID/>		<rdeCsv:fClID/>
	<rdeCsv:fCrRr/>		<rdeCsv:fCrRr/>
	skipping to change at page 42, line 5 ¶		skipping to change at line 1787 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="6F1E58E5">		cksum="6F1E58E5">
	host-YYYYMMDD.csv		host-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvHost:contents>		</csvHost:contents>
	...		...
	Example of the corresponding host-YYYYMMDD.csv file. The file		The following is an example of the corresponding host-YYYYMMDD.csv
	contains six host records with four being internal hosts and two		file. The file contains six host records with four being internal
	being external hosts.		hosts and two being external hosts:
	ns1.domain1.example,Hns1_example_test-TEST,registrarX,registrarX,		ns1.domain1.example,Hns1_example_test-TEST,registrarX,registrarX,
	clientY,1999-05-08T12:10:00.0Z,registrarX,		clientY,1999-05-08T12:10:00.0Z,registrarX,
	clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z		clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
	ns2.domain1.example,Hns2_domain1_test-TEST,registrarX,registrarX,		ns2.domain1.example,Hns2_domain1_test-TEST,registrarX,registrarX,
	clientY,1999-05-08T12:10:00.0Z,registrarX,		clientY,1999-05-08T12:10:00.0Z,registrarX,
	clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z		clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
	ns1.domain2.example,Hns1_domain2_test-TEST,registrarX,registrarX,		ns1.domain2.example,Hns1_domain2_test-TEST,registrarX,registrarX,
	clientY,1999-05-08T12:10:00.0Z,registrarX,		clientY,1999-05-08T12:10:00.0Z,registrarX,
	clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z		clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
	skipping to change at page 42, line 33 ¶		skipping to change at line 1815 ¶
	clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z		clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
	ns2.example.net,Hns2_example_test-TEST,registrarX,registrarX,		ns2.example.net,Hns2_example_test-TEST,registrarX,registrarX,
	clientY,1999-05-08T12:10:00.0Z,registrarX,		clientY,1999-05-08T12:10:00.0Z,registrarX,
	clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z		clientY,2009-10-03T09:34:00.0Z,2007-01-08T09:19:00.0Z
	5.2.2.1.2. "hostStatuses" CSV File Definition		5.2.2.1.2. "hostStatuses" CSV File Definition
	The "hostStatuses" CSV File Definition defines the fields and CSV		The "hostStatuses" CSV File Definition defines the fields and CSV
	file references used for the host object statuses.		file references used for the host object statuses.
	The following "csvHost" fields, defined for the "host" CSV File		The following "csvHost" fields, defined for the '"host" CSV File
	Definition (Section 5.2.2.1.1), MUST be used in the "hostStatuses"		Definition' (Section 5.2.2.1.1), MUST be used in the "hostStatuses"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvHost:fStatus> The status of the host with		<csvHost:fStatus> The status of the host with
	type="host:statusValueType" and isRequired="true".		type="host:statusValueType" and isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "hostStatuses"		(Section 4.6.2.2), MUST be used in the "hostStatuses" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fRoid> Host object Registry Object IDentifier (ROID)		<rdeCsv:fRoid> Host object ROID assigned to the host object with
	assigned to the host object with isRequired="true".		isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "hostStatuses"		(Section 4.6.2.2), MAY be used in the "hostStatuses" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fStatusDescription> Host object status description which is		<rdeCsv:fStatusDescription> Host object status description, which is
	free form text describing the rationale for the status.		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.
	Example of a "hostStatuses" <csvHost:contents> <rdeCsv:csv> element.		The following is an example of a "hostStatuses" <csvHost:contents>
			<rdeCsv:csv> element:
	...		...
	<csvHost:contents>		<csvHost:contents>
	...		...
	<rdeCsv:csv name="hostStatuses">		<rdeCsv:csv name="hostStatuses">
	<rdeCsv:fields>		<rdeCsv:fields>
	<rdeCsv:fRoid parent="true"/>		<rdeCsv:fRoid parent="true"/>
	<csvHost:fStatus/>		<csvHost:fStatus/>
	<rdeCsv:fStatusDescription/>		<rdeCsv:fStatusDescription/>
	<rdeCsv:fLang/>		<rdeCsv:fLang/>
	skipping to change at page 43, line 30 ¶		skipping to change at line 1862 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="0DAE0583">		cksum="0DAE0583">
	hostStatuses-YYYYMMDD.csv		hostStatuses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvHost:contents>		</csvHost:contents>
	...		...
	Example of the corresponding hostStatuses-YYYYMMDD.csv file. The		The following is an example of the corresponding hostStatuses-
	file contains the statuses for the six host names		YYYYMMDD.csv file. The file contains the statuses for the six host
	ns1.domain1.example, ns2.domain1.example, ns1.domain2.example,		names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example,
	ns2.domain2.example, ns1.example.net and ns2.example.net.		ns2.domain2.example, ns1.example.net, and ns2.example.net:
	Hns1_domain1_test-TEST,ok,,		Hns1_domain1_test-TEST,ok,,
	Hns2_domain1_test-TEST,ok,,		Hns2_domain1_test-TEST,ok,,
	Hns1_domain2_test-TEST,ok,,		Hns1_domain2_test-TEST,ok,,
	Hns2_domain2_test-TEST,ok,,		Hns2_domain2_test-TEST,ok,,
	Hns1_example_test-TEST,ok,,		Hns1_example_test-TEST,ok,,
	Hns2_example_test-TEST,ok,,		Hns2_example_test-TEST,ok,,
	5.2.2.1.3. "hostAddresses" CSV File Definition		5.2.2.1.3. "hostAddresses" CSV File Definition
	skipping to change at page 44, line 10 ¶		skipping to change at line 1891 ¶
	<csvHost:fAddr> IP addresses associated with the host object with		<csvHost:fAddr> IP addresses associated with the host object with
	type="host:addrStringType". The attribute "isRequired" MUST equal		type="host:addrStringType". The attribute "isRequired" MUST equal
	"true".		"true".
	<csvHost:fAddrVersion> IP addresses version associated with the host		<csvHost:fAddrVersion> IP addresses version associated with the host
	object with type="host:ipType". "host:ipType" has the enumerated		object with type="host:ipType". "host:ipType" has the enumerated
	values of "v4" or "v6". The attribute "isRequired" MUST equal		values of "v4" or "v6". The attribute "isRequired" MUST equal
	"true".		"true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "hostAddresses"		(Section 4.6.2.2), MUST be used in the "hostAddresses" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fRoid> Host object Registry Object IDentifier (ROID)		<rdeCsv:fRoid> Host object ROID assigned to the host object with
	assigned to the host object with isRequired="true".		isRequired="true".
	Example of a "hostAddresses" <csvHost:contents> <rdeCsv:csv> element.		The following is an example of a "hostAddresses" <csvHost:contents>
			<rdeCsv:csv> element:
	...		...
	<csvHost:contents>		<csvHost:contents>
	...		...
	<rdeCsv:csv name="hostAddresses">		<rdeCsv:csv name="hostAddresses">
	<rdeCsv:fields>		<rdeCsv:fields>
	<rdeCsv:fRoid parent="true"/>		<rdeCsv:fRoid parent="true"/>
	<csvHost:fAddr isRequired="true"/>		<csvHost:fAddr isRequired="true"/>
	<csvHost:fAddrVersion isRequired="true"/>		<csvHost:fAddrVersion isRequired="true"/>
	</rdeCsv:fields>		</rdeCsv:fields>
	skipping to change at page 44, line 39 ¶		skipping to change at line 1921 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="28B194B0">		cksum="28B194B0">
	hostAddresses-YYYYMMDD.csv		hostAddresses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvHost:contents>		</csvHost:contents>
	...		...
	Example of the corresponding hostAddresses-YYYYMMDD.csv file. The		The following is an example of the corresponding hostAddresses-
	file contains the IP addresses for the host names		YYYYMMDD.csv file. The file contains the IP addresses for the host
	ns1.domain1.example, ns2.domain1.example, ns1.domain2.example and		names ns1.domain1.example, ns2.domain1.example, ns1.domain2.example,
	ns2.domain2.example.		and ns2.domain2.example:
	Hns1_domain1_test-TEST,192.0.2.1,v4		Hns1_domain1_test-TEST,192.0.2.1,v4
	Hns2_domain1_test-TEST,2001:DB8::1,v6		Hns2_domain1_test-TEST,2001:DB8::1,v6
	Hns1_domain2_test-TEST,192.0.2.2,v4		Hns1_domain2_test-TEST,192.0.2.2,v4
	Hns2_domain2_test-TEST,2001:DB8::2,v6		Hns2_domain2_test-TEST,2001:DB8::2,v6
	5.2.2.2. <csvHost:deletes>		5.2.2.2. <csvHost:deletes>
	The <csvHost:deletes> is used to hold the deleted host objects in a		The <csvHost:deletes> is used to hold the deleted host objects in a
	Differential or Incremental Deposit. All the host object data is		Differential or Incremental Deposit. All the host object data is
	deleted as part of a cascade delete. The <csvHost:deletes> is split		deleted as part of a cascade delete. The <csvHost: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 host deletes CSV file definition.		supported host deletes CSV file definition.
	5.2.2.2.1. "host" Deletes CSV File Definition		5.2.2.2.1. "host" Deletes CSV File Definition
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv>		(Section 4.6.2.2), MUST be used in the "host" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fRoid> Repository Object IDentifier (ROID) assigned to the		<rdeCsv:fRoid> ROID assigned to the host object with
	host object with isRequired="true".		isRequired="true".
	Example of a "host" <csvHost:deletes> <rdeCsv:csv> element.		The following is an example of a "host" <csvHost:deletes>
			<rdeCsv:csv> element:
	...		...
	<csvHost:deletes>		<csvHost:deletes>
	...		...
	<rdeCsv:csv name="host">		<rdeCsv:csv name="host">
	<rdeCsv:fields>		<rdeCsv:fields>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="777F5F0E">		cksum="777F5F0E">
	host-delete-YYYYMMDD.csv		host-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvHost:deletes>		</csvHost:deletes>
	...		...
	Example of the host-delete-YYYYMMDD.csv file. The file contains four		The following is an example of the host-delete-YYYYMMDD.csv file.
	host records.		The file contains four host records:
	Hns1_domain1_test-TEST		Hns1_domain1_test-TEST
	Hns2_domain1_test-TEST		Hns2_domain1_test-TEST
	Hns1_domain2_test-TEST		Hns1_domain2_test-TEST
	Hns2_domain2_test-TEST		Hns2_domain2_test-TEST
	5.3. Contact Object		5.3. Contact Object
	The contact object is based on the EPP contact name mapping in		The contact object is based on the EPP contact name mapping in
	[RFC5733]. The contact object supports both the XML Model and the		[RFC5733]. The contact object supports both the XML model and the
	CSV Model, defined in Models (Section 2) section. The elements used		CSV model, defined in 'Models' (Section 2). The elements used for
	for both models are defined in the following sections.		both models are defined in the following sections.
	5.3.1. XML Model		5.3.1. XML Model
	There are two elements used in the data escrow of the contact objects		There are two elements used in the data escrow of the contact objects
	for the XML model including the <rdeContact:contact>, under the		for the XML model including the <rdeContact:contact> element, under
	<rdeContact:contents> element, and the <rdeContact:delete> element,		the <rdeContact:contents> element, and the <rdeContact:delete>
	under the <rde:deletes> element.		element, under the <rde:deletes> element.
	A <contact> element substitutes for the <abstractContact> abstract		A <contact> element substitutes for the <abstractContact> abstract
	element to define a concrete definition of a contact. The		element to create a concrete definition of a contact. The
	<abstractContact> element can be replaced by other contact		<abstractContact> element can be replaced by other contact
	definitions using the XML schema substitution groups feature.		definitions using the XML schema substitution groups feature.
	5.3.1.1. <rdeContact:contact> object		5.3.1.1. <rdeContact:contact> Object
	The contact object is based on the EPP contact <info> response for an		The contact object is based on the EPP contact <info> response for an
	authorized client (Section 3.1.2. of [RFC5733]) with some additions		authorized client (Section 3.1.2 of [RFC5733]) with some additions
	including the data from an EPP <transfer> Query Response, see		including the data from an EPP <transfer> query response, see
	Section 3.1.3. of [RFC5733].		Section 3.1.3 of [RFC5733].
	The OPTIONAL <contact> element contains the following child elements:		The OPTIONAL <contact> element contains the following child elements:
	o A <id> element that contains the server-unique identifier of the		* A <id> element that contains the server-unique identifier of the
	contact object		contact object.
	o A <roid> element that contains the Repository Object IDentifier		* A <roid> element that contains the ROID assigned to the contact
	assigned to the contact object when the object was created.		object when the object was created.
	o One or more <status> elements that describe the status of the		* One or more <status> elements that describe the status of the
	contact object.		contact object.
	o One or two <postalInfo> elements that contain postal-address		* One or two <postalInfo> elements that contain postal-address
	information. Two elements are provided so that address		information. Two elements are provided so that address
	information can be provided in both internationalized and		information can be provided in both internationalized and
	localized forms; a "type" attribute is used to identify the two		localized forms; a "type" attribute is used to identify the two
	forms. If an internationalized form (type="int") is provided,		forms. If an internationalized form (type="int") is provided,
	element content MUST be represented in a subset of UTF-8 that can		element content MUST be represented in a subset of UTF-8 that can
	be represented in the 7-bit US-ASCII character set. If a		be represented in the 7-bit US-ASCII character set. If a
	localized form (type="loc") is provided, element content MAY be		localized form (type="loc") is provided, element content MAY be
	represented in unrestricted UTF-8. The <postalInfo> element		represented in unrestricted UTF-8. The <postalInfo> element
	contains the following child elements:		contains the following child elements:
	* A <name> element that contains the name of the individual or		- A <name> element that contains the name of the individual or
	role represented by the contact.		role represented by the contact.
	* An OPTIONAL <org> element that contains the name of the		- An OPTIONAL <org> element that contains the name of the
	organization with which the contact is affiliated.		organization with which the contact is affiliated.
	* An <addr> element that contains address information associated		- An <addr> element that contains address information associated
	with the contact. An <addr> element contains the following		with the contact. An <addr> element contains the following
	child elements:		child elements:
	+ One, two, or three OPTIONAL <street> elements that contain		o One, two, or three OPTIONAL <street> elements that contain
	the contact's street address.		the contact's street address.
	+ A <city> element that contains the contact's city.		o A <city> element that contains the contact's city.
	+ An OPTIONAL <sp> element that contains the contact's state		o An OPTIONAL <sp> element that contains the contact's state
	or province.		or province.
	+ An OPTIONAL <pc> element that contains the contact's postal		o An OPTIONAL <pc> element that contains the contact's postal
	code.		code.
	+ A <cc> element that contains the contact's two-letter		o A <cc> element that contains the contact's two-letter
	country code.		country code.
	o An OPTIONAL <voice> element that contains the contact's voice		* An OPTIONAL <voice> element that contains the contact's voice
	telephone number.		telephone number.
	o An OPTIONAL <fax> element that contains the contact's facsimile		* An OPTIONAL <fax> element that contains the contact's facsimile
	telephone number.		telephone number.
	o An <email> element that contains the contact's email address.		* An <email> element that contains the contact's email address.
	o A <clID> element that contains the identifier of the sponsoring		* A <clID> element that contains the identifier of the sponsoring
	registrar.		registrar.
	o An OPTIONAL <crRr> element that contains the identifier of the		* An OPTIONAL <crRr> element that contains the identifier of the
	registrar that created the contact object. An OPTIONAL client		registrar that created the contact object. An OPTIONAL "client"
	attribute is used to specify the client that performed the		attribute is used to specify the client that performed the
	operation.		operation.
	o An OPTIONAL <crDate> element that contains the date and time of		* An OPTIONAL <crDate> element that contains the date and time of
	contact-object creation.		contact object creation.
	o An OPTIONAL <upRr> element that contains the identifier of the		* An OPTIONAL <upRr> element that contains the identifier of the
	registrar that last updated the contact object. This element MUST		registrar that last updated the contact object. This element MUST
	NOT be present if the contact has never been modified. An		NOT be present if the contact has never been modified. An
	OPTIONAL client attribute is used to specify the client that		OPTIONAL "client" attribute is used to specify the client that
	performed the operation.		performed the operation.
	o An OPTIONAL <upDate> element that contains the date and time of		* An OPTIONAL <upDate> element that contains the date and time of
	the most recent contact-object modification. This element MUST		the most recent contact object modification. This element MUST
	NOT be present if the contact object has never been modified.		NOT be present if the contact object has never been modified.
	o An OPTIONAL <trDate> element that contains the date and time of		* An OPTIONAL <trDate> element that contains the date and time of
	the most recent contact object successful transfer. This element		the most recent contact object successful transfer. This element
	MUST NOT be present if the contact object has never been		MUST NOT be present if the contact object has never been
	transferred.		transferred.
	o An OPTIONAL <trnData> element that contains the following child		* An OPTIONAL <trnData> element that contains the following child
	elements related to the last transfer request of the contact		elements related to the last transfer request of the contact
	object:		object:
	* A <trStatus> element that contains the state of the most recent		- A <trStatus> element that contains the state of the most recent
	transfer request.		transfer request.
	* A <reRr> element that contains the identifier of the registrar		- An <reRr> element that contains the identifier of the registrar
	that requested the domain name object transfer. An OPTIONAL		that requested the domain name object transfer. An OPTIONAL
	client attribute is used to specify the client that performed		"client" attribute is used to specify the client that performed
	the operation.		the operation.
	* An <acRr> element that contains the identifier of the registrar		- An <acRr> element that contains the identifier of the registrar
	that should act upon a PENDING transfer request. For all other		that should act upon a pending transfer request. For all other
	status types, the value identifies the registrar that took the		status types, the value identifies the registrar that took the
	indicated action. An OPTIONAL client attribute is used to		indicated action. An OPTIONAL "client" attribute is used to
	specify the client that performed the operation.		specify the client that performed the operation.
	* A <reDate> element that contains the date and time that the		- An <reDate> element that contains the date and time that the
	transfer was requested.		transfer was requested.
	* An <acDate> element that contains the date and time of a		- An <acDate> element that contains the date and time of a
	required or completed response. For a PENDING request, the		required or completed response. For a pending request, the
	value identifies the date and time by which a response is		value identifies the date and time by which a response is
	required before an automated response action will be taken by		required before an automated response action will be taken by
	the registry. For all other status types, the value identifies		the registry. For all other status types, the value identifies
	the date and time when the request was completed.		the date and time when the request was completed.
	o An OPTIONAL <disclose> element that identifies elements that		* An OPTIONAL <disclose> element that identifies elements that
	requiring exceptional server-operator handling to allow or		requiring exceptional server-operator handling to allow or
	restrict disclosure to third parties. See Section 2.9 of		restrict disclosure to third parties. See Section 2.9 of
	[RFC5733] for a description of the child elements contained within		[RFC5733] for a description of the child elements contained within
	the <disclose> element.		the <disclose> element.
	Example <contact> object:		The following is an example of a <contact> object:
	...		...
	<rdeContact:contact>		<rdeContact:contact>
	<rdeContact:id>sh8013</rdeContact:id>		<rdeContact:id>sh8013</rdeContact:id>
	<rdeContact:roid>Csh8013-TEST</rdeContact:roid>		<rdeContact:roid>Csh8013-TEST</rdeContact:roid>
	<rdeContact:status s="linked"/>		<rdeContact:status s="linked"/>
	<rdeContact:status s="clientDeleteProhibited"/>		<rdeContact:status s="clientDeleteProhibited"/>
	<rdeContact:postalInfo type="int">		<rdeContact:postalInfo type="int">
	<contact:name>John Doe</contact:name>		<contact:name>John Doe</contact:name>
	<contact:org>Example Inc.</contact:org>		<contact:org>Example Inc.</contact:org>
	skipping to change at page 49, line 48 ¶		skipping to change at line 2161 ¶
	<rdeContact:acRr client="rmiles">RegistrarX</rdeContact:acRr>		<rdeContact:acRr client="rmiles">RegistrarX</rdeContact:acRr>
	<rdeContact:acDate>2011-03-13T23:59:59.0Z</rdeContact:acDate>		<rdeContact:acDate>2011-03-13T23:59:59.0Z</rdeContact:acDate>
	</rdeContact:trnData>		</rdeContact:trnData>
	<rdeContact:disclose flag="0">		<rdeContact:disclose flag="0">
	<contact:voice/>		<contact:voice/>
	<contact:email/>		<contact:email/>
	</rdeContact:disclose>		</rdeContact:disclose>
	</rdeContact:contact>		</rdeContact:contact>
	...		...
	5.3.1.2. <rdeContact:delete> object		5.3.1.2. <rdeContact:delete> Object
	The <rdeContact:delete> element contains the id of a contact that was		The <rdeContact:delete> element contains the id of a contact that was
	deleted.		deleted.
	Example of <rdeContact:delete> object:		The following is an example of an <rdeContact:delete> object:
	...		...
	<rde:deletes>		<rde:deletes>
	...		...
	<rdeContact:delete>		<rdeContact:delete>
	<rdeContact:id>sh8013-TEST</rdeContact:id>		<rdeContact:id>sh8013-TEST</rdeContact:id>
	<rdeContact:id>co8013-TEST</rdeContact:id>		<rdeContact:id>co8013-TEST</rdeContact:id>
	</rdeContact:delete>		</rdeContact:delete>
	...		...
	</rde:deletes>		</rde:deletes>
	...		...
	5.3.2. CSV Model		5.3.2. CSV Model
	For the CSV Model of the contact object, the <csvContact:contents>		For the CSV model of the contact object, the <csvContact:contents>
	child element of the <rde:contents> element is used to hold the new		child element of the <rde:contents> element is used to hold the new
	or updated contacts objects for the deposit. The		or updated contacts objects for the deposit. The
	<csvContact:deletes> child element of the <rde:deletes> element is		<csvContact:deletes> child element of the <rde:deletes> element is
	used to hold the deleted or purged contact objects for the deposit.		used to hold the deleted or purged contact objects for the deposit.
	Both the <csvContact:contents> and <csvContact:deletes> elements		Both the <csvContact:contents> and <csvContact:deletes> elements
	contain one or more <rdeCsv:csv> elements with a set of named CSV		contain one or more <rdeCsv:csv> elements with a set of named CSV
	file definitions using the <rdeCsv:csv> "name" attribute.		file definitions using the <rdeCsv:csv> "name" attribute.
	Differential and Incremental Deposits are based on changes to the		Differential and Incremental Deposits are based on changes to the
	contact objects. The updated contact object data under the		contact objects. The updated contact object data under the
	<csvContact:contents> element is a cascade replace down all of the		<csvContact:contents> element is a cascade replace down all of the
	contact CSV files starting with the parent "contact" CSV File		contact CSV files starting with the parent '"contact" CSV File
	Definition (Section 5.3.2.1.1). The child CSV file definitions		Definition' (Section 5.3.2.1.1). The child CSV file definitions
	include a <csvContact:fId parent="true"> field. All the child CSV		include a <csvContact:fId parent="true"> field. All the child CSV
	file definition data for the contact objects in the parent "contact"		file definition data for the contact objects in the parent '"contact"
	CSV File Definition (Section 5.3.2.1.1) MUST first be deleted and		CSV File Definition' (Section 5.3.2.1.1) MUST first be deleted and
	then set using the data in the child CSV files. The deleted contact		then set using the data in the child CSV files. The deleted contact
	object data under the <csvContact:deletes> element is a cascade		object data under the <csvContact:deletes> element is a cascade
	delete starting from the "contact" Deletes CSV File Definition		delete starting from the '"contact" Deletes CSV File Definition'
	(Section 5.3.2.2.1).		(Section 5.3.2.2.1).
	5.3.2.1. <csvContact:contents>		5.3.2.1. <csvContact:contents>
	The <csvContact:contents> is used to hold the new or updated contact		The <csvContact:contents> is used to hold the new or updated contact
	object information for the deposit. The <csvContact:contents> is		object information for the deposit. The <csvContact:contents> is
	split into separate CSV file definitions using named <rdeCsv:csv>		split into separate CSV file definitions using named <rdeCsv:csv>
	elements with the "name" attribute. The following sections include		elements with the "name" attribute. The following sections include
	the supported contact CSV file definitions.		the supported contact CSV file definitions.
	skipping to change at page 51, line 34 ¶		skipping to change at line 2240 ¶
	<csvContact:fVoiceExt> Contains the contact's voice telephone number		<csvContact:fVoiceExt> Contains the contact's voice telephone number
	extension with type="token".		extension with type="token".
	<csvContact:fFax> Contains the contact's facsimile telephone number		<csvContact:fFax> Contains the contact's facsimile telephone number
	with type="contact:e164StringType".		with type="contact:e164StringType".
	<csvContact:fFaxExt> Contains the contact's facsimile telephone		<csvContact:fFaxExt> Contains the contact's facsimile telephone
	number extension with type="token".		number extension with type="token".
	The following "rdeCsv" and "csvRegistrar" fields, MUST be used in the		The following "rdeCsv" and "csvRegistrar" fields MUST be used in the
	"contact" <rdeCsv:csv> <rdeCsv:fields> element:		"contact" <rdeCsv:csv> <rdeCsv:fields> element:
	<rdeCsv:fRoid> The Registry Object IDentifier (ROID) for the contact		<rdeCsv:fRoid> The ROID for the contact object with
	object with isRequired="true".		isRequired="true".
	<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of:		<rdeCsv:fClID> or <csvRegistrar:fGurid> A choice of the following:
	<rdeCsv:fClID> Identifier of the sponsoring client with		<rdeCsv:fClID> Identifier of the sponsoring client with
	isRequired="true".		isRequired="true".
	<csvRegistrar:fGurid> Contains the Globally Unique Registrar		<csvRegistrar:fGurid> Contains the GURID assigned by ICANN with
	Identifier (GURID) assigned by ICANN with
	type="positiveInteger" and isRequired="true".		type="positiveInteger" and isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "contact" <rdeCsv:csv>		(Section 4.6.2.2), MAY be used in the "contact" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fCrRr> Identifier of the registrar, defined in Section 5.4,
	of the client that created the contact object.		of the client that created the contact object.
	<rdeCsv:fCrID> Identifier of the client that created the contact		<rdeCsv:fCrID> Identifier of the client that created the contact
	object.		object.
	<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fUpRr> Identifier of the registrar, defined in Section 5.4,
	of the client that last updated the contact object.		of the client that last updated the contact object.
	<rdeCsv:fUpID> Identifier of the client that last updated the		<rdeCsv:fUpID> Identifier of the client that last updated the
	contact object.		contact object.
	<rdeCsv:fCrDate> Created date and time of the contact object.		<rdeCsv:fCrDate> Date and time of the contact object creation.
	<rdeCsv:fUpDate> Date and time of the last update to the contact		<rdeCsv:fUpDate> Date and time of the last update to the contact
	object. This field MUST NOT be set if the domain name object has		object. This field MUST NOT be set if the domain name object has
	never been modified.		never been modified.
	<rdeCsv:fTrDate> Date and time of the last transfer for the contact		<rdeCsv:fTrDate> Date and time of the last transfer for the contact
	object. This field MUST NOT be set if the domain name object has		object. This field MUST NOT be set if the domain name object has
	never been transferred.		never been transferred.
	Example of a "contact" <csvContact:contacts> <rdeCsv:csv> element.		The following is an example of a "contact" <csvContact:contacts>
			<rdeCsv:csv> element:
	...		...
	<csvContact:contents>		<csvContact:contents>
	...		...
	<rdeCsv:csv name="contact">		<rdeCsv:csv name="contact">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId/>		<csvContact:fId/>
	<rdeCsv:fRoid/>		<rdeCsv:fRoid/>
	<csvContact:fVoice/>		<csvContact:fVoice/>
	<csvContact:fVoiceExt/>		<csvContact:fVoiceExt/>
	skipping to change at page 54, line 5 ¶		skipping to change at line 2314 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="8587AA49">		cksum="8587AA49">
	contact-YYYYMMDD.csv		contact-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:contents>		</csvContact:contents>
	...		...
	Example of the contact-YYYYMMDD.csv file. The file contains nine		The following is an example of the contact-YYYYMMDD.csv file. The
	object contact records.		file contains nine object contact records:
	domain1admin,Cdomain1admin-TEST,+1.7035555555,1234,		domain1admin,Cdomain1admin-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	domain1tech,Cdomain1tech-TEST,+1.7035555555,1234,		domain1tech,Cdomain1tech-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	domain1billing,Cdomain1billing-TEST,+1.7035555555,1234,		domain1billing,Cdomain1billing-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	domain2admin,Cdomain2admin-TEST,+1.7035555555,1234,		domain2admin,Cdomain2admin-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	domain2tech,Cdomain2tech-TEST,+1.7035555555,1234,		domain2tech,Cdomain2tech-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	domain2billing,Cdomain2billing-TEST,+1.7035555555,1234,		domain2billing,Cdomain2billing-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	xnabc123admin,Cxnabc123admin-TEST,+1.7035555555,1234,		xnabc123admin,Cxnabc123admin-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	xnabc123tech,Cxnabc123tech-TEST,+1.7035555555,1234,		xnabc123tech,Cxnabc123tech-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	xnabc123billing,Cxnabc123billing-TEST,+1.7035555555,1234,		xnabc123billing,Cxnabc123billing-TEST,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,registrarX,registarX,		+1.7035555556,,jdoe@example.example,registrarX,registrarX,
	clientY,2009-09-13T08:01:00.0Z,registarX,clientY,		clientY,2009-09-13T08:01:00.0Z,registrarX,clientY,
	2009-11-26T09:10:00.0Z		2009-11-26T09:10:00.0Z
	5.3.2.1.2. "contactStatuses" CSV File Definition		5.3.2.1.2. "contactStatuses" CSV File Definition
	The "contactStatuses" CSV File Definition defines the fields and CSV		The "contactStatuses" CSV File Definition defines the fields and CSV
	file references used for the contact object statuses.		file references used for the contact object statuses.
	The following "csvContact" field elements, defined for the "contact"		The following "csvContact" field elements, defined in the '"contact"
	CSV File Definition (Section 5.3.2.1.1), MUST be used in the		CSV File Definition' (Section 5.3.2.1.1), MUST be used in the
	"contactStatuses" <rdeCsv:csv> <rdeCsv:fields> element:		"contactStatuses" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> Server-unique contact identifier of status with		<csvContact:fId> Server-unique contact identifier of status with
	isRequired="true" and parent="true".		isRequired="true" and parent="true".
	<csvContact:fStatus> The status of the contact with		<csvContact:fStatus> The status of the contact with
	type="contact:statusValueType" and isRequired="true".		type="contact:statusValueType" and isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "contactStatuses"		(Section 4.6.2.2), MAY be used in the "contactStatuses" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fStatusDescription> The contact object status description		<rdeCsv:fStatusDescription> The contact object status description,
	which is free form text describing the rationale for the status.		which 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.
	Example of a "contactStatuses" <csvContact:contents> <rdeCsv:csv>		The following is an example of a "contactStatuses"
	element.		<csvContact:contents> <rdeCsv:csv> element:
	...		...
	<csvContact:contents>		<csvContact:contents>
	...		...
	<rdeCsv:csv name="contactStatuses">		<rdeCsv:csv name="contactStatuses">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId parent="true"/>		<csvContact:fId parent="true"/>
	<csvContact:fStatus/>		<csvContact:fStatus/>
	<rdeCsv:fStatusDescription/>		<rdeCsv:fStatusDescription/>
	<rdeCsv:fLang/>		<rdeCsv:fLang/>
	skipping to change at page 56, line 5 ¶		skipping to change at line 2402 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="137E13EC">		cksum="137E13EC">
	contactStatuses-YYYYMMDD.csv		contactStatuses-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:contents>		</csvContact:contents>
	...		...
	Example of the corresponding contactStatuses-YYYYMMDD.csv file. The		The following is an example of the corresponding contactStatuses-
	file contains the statuses for the nine contact identifiers.		YYYYMMDD.csv file. The file contains the statuses for the nine
			contact identifiers:
	domain1admin,ok,,		domain1admin,ok,,
	domain1tech,ok,,		domain1tech,ok,,
	domain1billing,ok,,		domain1billing,ok,,
	domain2admin,ok,,		domain2admin,ok,,
	domain2tech,ok,,		domain2tech,ok,,
	domain2billing,ok,,		domain2billing,ok,,
	xnabc123admin,ok,,		xnabc123admin,ok,,
	xnabc123tech,ok,,		xnabc123tech,ok,,
	xnabc123billing,ok,,		xnabc123billing,ok,,
	5.3.2.1.3. "contactPostal" CSV File Definition		5.3.2.1.3. "contactPostal" CSV File Definition
	The "contactPostal" CSV File Definition defines the fields and CSV		The "contactPostal" CSV File Definition defines the fields and CSV
	file references used for the contact postal info object records.		file references used for the contact postal info object records.
	The following "csvContact" field elements MUST be used in the		The following "csvContact" field elements MUST be used in the
	"contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:		"contactPostal" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fPostalType> Contains the form of the postal-address		<csvContact:fPostalType> Contains the form of the postal address
	information with type="contact:postalLineType" and		information with type="contact:postalLineType" and
	isRequired="true". This field specifies the form ("int" or		isRequired="true". This field specifies the form ("int" or
	"loc"), as defined in Section 4.6.3, of the <csvContact:fName>,		"loc"), as defined in Section 4.6.3, of the <csvContact:fName>,
	<csvContact:fOrg>, <csvContact:fStreet>, <csvContact:fCity>,		<csvContact:fOrg>, <csvContact:fStreet>, <csvContact:fCity>,
	<csvContact:fSp>, <csvContact:fPc>, <csvContact:fCc> fields.		<csvContact:fSp>, <csvContact:fPc>, and <csvContact:fCc> fields.
	<csvContact:fName> Contains the contact's name of the individual or		<csvContact:fName> Contains the contact's name of the individual or
	role represented by the contact with type="contact:postalLineType"		role represented by the contact with type="contact:postalLineType"
	and isRequired="true". An OPTIONAL "isLoc" attribute is used to		and isRequired="true". An OPTIONAL "isLoc" attribute is used to
	indicate the localized or internationalized form as defined in		indicate the localized or internationalized form as defined in
	Section 4.6.3.		Section 4.6.3.
	<csvContact:fStreet> Contains the contact's street address line with		<csvContact:fStreet> Contains the contact's street address line with
	type="contact:fPostalLineType". An index attribute is required to		type="contact:fPostalLineType". An "index" attribute is required
	indicate which street address line the field represents with index		to indicate which street address line the field represents with
	"0" for the first line and incrementing for each line up to index		index="0" for the first line and incrementing for each line up to
	"2" for the third line. An OPTIONAL "isLoc" attribute is used to		index="2" for the third line. An OPTIONAL "isLoc" attribute is
	indicate the localized or internationalized form as defined in		used to indicate the localized or internationalized form as
	Section 4.6.3.		defined in Section 4.6.3.
	<csvContact:fCity> Contains the contact's city with		<csvContact:fCity> Contains the contact's city with
	type="contact:postalLineType" and isRequired="true". An OPTIONAL		type="contact:postalLineType" and isRequired="true". An OPTIONAL
	"isLoc" attribute is used to indicate the localized or		"isLoc" attribute is used to indicate the localized or
	internationalized form as defined in Section 4.6.3.		internationalized form as defined in Section 4.6.3.
	<csvContact:fCc> Contains the contact's country code with		<csvContact:fCc> Contains the contact's country code with
	type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc"		type="contact:ccType" and isRequired="true". An OPTIONAL "isLoc"
	attribute is used to indicate the localized or internationalized		attribute is used to indicate the localized or internationalized
	form as defined in Section 4.6.3.		form as defined in Section 4.6.3.
	skipping to change at page 57, line 28 ¶		skipping to change at line 2473 ¶
	<csvContact:fSp> Contains the contact's state or province with		<csvContact:fSp> Contains the contact's state or province with
	type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute		type="contact:optPostalLineType". An OPTIONAL "isLoc" attribute
	is used to indicate the localized or internationalized form as		is used to indicate the localized or internationalized form as
	defined in Section 4.6.3.		defined in Section 4.6.3.
	<csvContact:fPc> Contains the contact's postal code with		<csvContact:fPc> Contains the contact's postal code with
	type="contact:pcType". An OPTIONAL "isLoc" attribute is used to		type="contact:pcType". An OPTIONAL "isLoc" attribute is used to
	indicate the localized or internationalized form as defined in		indicate the localized or internationalized form as defined in
	Section 4.6.3.		Section 4.6.3.
	The following "csvContact" fields, defined for the "contact" CSV File		The following "csvContact" fields, defined in the '"contact" CSV File
	Definition (Section 5.3.2.1.1), MUST be used in the "contactPostal"		Definition' (Section 5.3.2.1.1), MUST be used in the "contactPostal"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> Server-unique contact identifier for the contact		<csvContact:fId> Server-unique contact identifier for the contact
	object with isRequired="true" and parent="true".		object with isRequired="true" and parent="true".
	Example of a "contactPostal" <csvContact:contents> <rdeCsv:csv>		The following is an example of a "contactPostal"
	element.		<csvContact:contents> <rdeCsv:csv> element:
	...		...
	<csvContact:contents>		<csvContact:contents>
	...		...
	<rdeCsv:csv name="contactPostal">		<rdeCsv:csv name="contactPostal">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId parent="true"/>		<csvContact:fId parent="true"/>
	<csvContact:fPostalType/>		<csvContact:fPostalType/>
	<csvContact:fName/>		<csvContact:fName/>
	<csvContact:fOrg/>		<csvContact:fOrg/>
	skipping to change at page 59, line 5 ¶		skipping to change at line 2511 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="1456A89C">		cksum="1456A89C">
	contactPostal-YYYYMMDD.csv		contactPostal-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:contents>		</csvContact:contents>
	...		...
	Example of the contactPostal-YYYYMMDD.csv file. The file contains		The following is an example of the contactPostal-YYYYMMDD.csv file.
	nine contact postal records.		The file contains nine contact postal records:
	domain1admin,int,"John Doe","Example Inc.",		domain1admin,int,"John Doe","Example Inc.",
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	domain1tech,int,"John Doe","Example Inc.",		domain1tech,int,"John Doe","Example Inc.",
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	domain1billing,int,"John Doe","Example Inc.",		domain1billing,int,"John Doe","Example Inc.",
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	domain2admin,int,"John Doe","Example Inc.",		domain2admin,int,"John Doe","Example Inc.",
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	domain2tech,int,"John Doe","Example Inc.",		domain2tech,int,"John Doe","Example Inc.",
	skipping to change at page 59, line 33 ¶		skipping to change at line 2539 ¶
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	xnabc123billing,int,"John Doe","Example Inc.",		xnabc123billing,int,"John Doe","Example Inc.",
	"123 Example Dr.","Suite 100",,Reston,VA,20190,US		"123 Example Dr.","Suite 100",,Reston,VA,20190,US
	5.3.2.1.4. "contactTransfer" CSV File Definition		5.3.2.1.4. "contactTransfer" CSV File Definition
	The "contactTransfer" CSV File Definition defines the fields and CSV		The "contactTransfer" CSV File Definition defines the fields and CSV
	file references used for the contact object pending and completed		file references used for the contact object pending and completed
	transfer records. No additional field elements were added for use in		transfer records. No additional field elements were added for use in
	the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element. The		the "contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element. The
	following "rdeCsv" fields, defined in section CSV common field		following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MUST be used in the "contactTransfer"		(Section 4.6.2.2), MUST be used in the "contactTransfer" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fTrStatus> State of the most recent transfer request with		<rdeCsv:fTrStatus> State of the most recent transfer request with
	isRequired="true".		isRequired="true".
	<rdeCsv:fReRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fReRr> Identifier of the registrar, defined in Section 5.4,
	of the client that requested the transfer with isRequired="true".		of the client that requested the transfer with isRequired="true".
	<rdeCsv:fReDate> Date and time that the transfer was requested with		<rdeCsv:fReDate> Date and time that the transfer was requested with
	isRequired="true".		isRequired="true".
	<rdeCsv:fAcRr> Identifier of the registrar, defined in Section 5.4,		<rdeCsv:fAcRr> Identifier of the registrar, defined in Section 5.4,
	of the client that should take or took action with		of the client that should take or took action with
	isRequired="true".		isRequired="true".
	<rdeCsv:fAcDate> Date and time that the transfer action should be		<rdeCsv:fAcDate> Date and time that the transfer action should be
	taken or has been taken with isRequired="true".		taken or has been taken with isRequired="true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "contactTransfer"		(Section 4.6.2.2), MAY be used in the "contactTransfer" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fReID> Identifier of the client that requested the transfer.		<rdeCsv:fReID> Identifier of the client that requested the transfer.
	<rdeCsv:fAcID> Identifier of the client that should take or took		<rdeCsv:fAcID> Identifier of the client that should take or took
	action for transfer.		action for transfer.
	The following "csvContact" fields, defined for the "contact" CSV File		The following "csvContact" fields, defined for the '"contact" CSV
	Definition (Section 5.3.2.1.1), MUST be used in the "contactTransfer"		File Definition' (Section 5.3.2.1.1), MUST be used in the
	<rdeCsv:csv> <rdeCsv:fields> element:		"contactTransfer" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> Server-unique contact identifier for the contact		<csvContact:fId> Server-unique contact identifier for the contact
	object with isRequired="true".		object with isRequired="true".
	Example of a "contactTransfer" <csvContact:contents> <rdeCsv:csv>		The following is an example of a "contactTransfer"
	element.		<csvContact:contents> <rdeCsv:csv> element:
	...		...
	<csvContact:contents>		<csvContact:contents>
	...		...
	<rdeCsv:csv name="contactTransfer">		<rdeCsv:csv name="contactTransfer">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId parent="true"/>		<csvContact:fId parent="true"/>
	<rdeCsv:fTrStatus/>		<rdeCsv:fTrStatus/>
	<rdeCsv:fReRr/>		<rdeCsv:fReRr/>
	<rdeCsv:fReID/>		<rdeCsv:fReID/>
	skipping to change at page 61, line 5 ¶		skipping to change at line 2603 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="788D308E">		cksum="788D308E">
	contactTransfer-YYYYMMDD.csv		contactTransfer-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:contents>		</csvContact:contents>
	...		...
	Example of the contactTransfer-YYYYMMDD.csv file. The file contains		The following is an example of the contactTransfer-YYYYMMDD.csv file.
	one contact transfer record in pending status.		The file contains one contact transfer record in pending status:
	xnabc123admin,clientApproved,registrarX,clientX,		xnabc123admin,clientApproved,registrarX,clientX,
	2011-04-08T19:38:00.0Z,registrarY,clientY,2011-04-09T20:38:00.0Z		2011-04-08T19:38:00.0Z,registrarY,clientY,2011-04-09T20:38:00.0Z
	5.3.2.1.5. "contactDisclose" CSV File Definition		5.3.2.1.5. "contactDisclose" CSV File Definition
	The "contactDisclose" CSV File Definition defines the fields and CSV		The "contactDisclose" CSV File Definition defines the fields and CSV
	file references used for the contact disclose object records.		file references used for the contact disclose object records.
	The following "csvContact" field elements MAY be used in the		The following "csvContact" field elements MAY be used in the
	skipping to change at page 62, line 11 ¶		skipping to change at line 2658 ¶
	<csvContact:fDiscloseVoice> Exceptional disclosure preference flag		<csvContact:fDiscloseVoice> Exceptional disclosure preference flag
	of the contact voice telephone number with type="boolean".		of the contact voice telephone number with type="boolean".
	<csvContact:fDiscloseFax> Exceptional disclosure preference flag of		<csvContact:fDiscloseFax> Exceptional disclosure preference flag of
	the contact facsimile telephone number with type="boolean".		the contact facsimile telephone number with type="boolean".
	<csvContact:fDiscloseEmail> Exceptional disclosure preference flag		<csvContact:fDiscloseEmail> Exceptional disclosure preference flag
	of the contact email address with type="boolean".		of the contact email address with type="boolean".
	The following "csvContact" fields, defined for the "contact" CSV File		The following "csvContact" fields, defined for the '"contact" CSV
	Definition (Section 5.3.2.1.1), MUST be used in the "contactDisclose"		File Definition' (Section 5.3.2.1.1), MUST be used in the
	<rdeCsv:csv> <rdeCsv:fields> element:		"contactDisclose" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> Server-unique contact identifier for the contact		<csvContact:fId> Server-unique contact identifier for the contact
	object with isRequired="true".		object with isRequired="true".
	Example of a "contactDisclose" <csvContact:contents> <rdeCsv:csv>		The following is an example of a "contactDisclose"
	element.		<csvContact:contents> <rdeCsv:csv> element:
	...		...
	<csvContact:contents>		<csvContact:contents>
	...		...
	<rdeCsv:csv name="contactDisclose">		<rdeCsv:csv name="contactDisclose">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId parent="true"/>		<csvContact:fId parent="true"/>
	<csvContact:fDiscloseFlag/>		<csvContact:fDiscloseFlag/>
	<csvContact:fDiscloseNameLoc/>		<csvContact:fDiscloseNameLoc/>
	<csvContact:fDiscloseNameInt/>		<csvContact:fDiscloseNameInt/>
	skipping to change at page 63, line 5 ¶		skipping to change at line 2696 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="1141EFD4">		cksum="1141EFD4">
	contactDisclose-YYYYMMDD.csv		contactDisclose-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:contents>		</csvContact:contents>
	...		...
	Example of the contactDisclose-YYYYMMDD.csv file. The file contains		The following is an example of the contactDisclose-YYYYMMDD.csv file.
	one disclosure records, disabling disclosure of voice, fax, and		The file contains one disclosure records, disabling disclosure of
	email.		voice, fax, and email:
	xnabc123admin,0,0,0,0,0,0,0,1,1,1		xnabc123admin,0,0,0,0,0,0,0,1,1,1
	5.3.2.2. <csvContact:deletes>		5.3.2.2. <csvContact:deletes>
	The <csvContact:deletes> is used to hold the deleted contact objects		The <csvContact:deletes> is used to hold the deleted contact objects
	in a Differential or Incremental Deposit. All the contact object		in a Differential or Incremental Deposit. All the contact object
	data is deleted as part of a cascade delete. The		data is deleted as part of a cascade delete. The
	<csvContact:deletes> is split into separate CSV file definitions		<csvContact:deletes> is split into separate CSV file definitions
	using named <rdeCsv:csv> elements with the "name" attribute. The		using named <rdeCsv:csv> elements with the "name" attribute. The
	skipping to change at page 63, line 29 ¶		skipping to change at line 2720 ¶
	definition.		definition.
	5.3.2.2.1. "contact" Deletes CSV File Definition		5.3.2.2.1. "contact" Deletes CSV File Definition
	The following "csvContact" field elements MUST be used in the deletes		The following "csvContact" field elements MUST be used in the deletes
	"contact" <rdeCsv:csv> <rdeCsv:fields> element:		"contact" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvContact:fId> Contains the server-unique contact identifier with		<csvContact:fId> Contains the server-unique contact identifier with
	type="eppcom:clIDType" and isRequired="true".		type="eppcom:clIDType" and isRequired="true".
	Example of a "contact" <csvContact:deletes> <rdeCsv:csv> element.		The following is an example of a "contact" <csvContact:deletes>
			<rdeCsv:csv> element:
	...		...
	<csvContact:deletes>		<csvContact:deletes>
	...		...
	<rdeCsv:csv name="contact">		<rdeCsv:csv name="contact">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvContact:fId/>		<csvContact:fId/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="0C4B70DC">		cksum="0C4B70DC">
	contact-delete-YYYYMMDD.csv		contact-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvContact:deletes>		</csvContact:deletes>
	...		...
	Example of the contact-delete-YYYYMMDD.csv file. The file contains		The following is an example of the contact-delete-YYYYMMDD.csv file.
	six contact records.		The file contains six contact records:
	domain1admin		domain1admin
	domain1tech		domain1tech
	domain1billing		domain1billing
	domain2admin		domain2admin
	domain2tech		domain2tech
	domain2billing		domain2billing
	5.4. Registrar Object		5.4. Registrar Object
	The registrar object represents the sponsoring client for other		The registrar object represents the sponsoring client for other
	objects, and is typically referred to as the sponsoring registrar.		objects and is typically referred to as the sponsoring registrar.
	The registrar object supports both the XML Model and the CSV Model,		The registrar object supports both the XML model and the CSV model,
	defined in Section 2. The elements used for both models are defined		defined in Section 2. The elements used for both models are defined
	in the following sections.		in the following sections.
	5.4.1. XML Model		5.4.1. XML Model
	There are two elements used in the data escrow of the registrar		There are two elements used in the data escrow of the registrar
	objects for the XML model including the <rdeRegistrar:registrar>,		objects for the XML model including the <rdeRegistrar:registrar>
	under the <rdeRegistrar:contents> element, and the		element, under the <rdeRegistrar:contents> element, and the
	<rdeRegistrar:delete> element, under the <rde:deletes> element.		<rdeRegistrar:delete> element, under the <rde:deletes> element.
	A <rdeRegistrar:registrar> element substitutes for the		An <rdeRegistrar:registrar> element substitutes for the
	<rdeRegistrar:abstractRegistrar> abstract element to define a		<rdeRegistrar:abstractRegistrar> abstract element to create a
	concrete definition of a registrar. The		concrete definition of a registrar. The
	<rdeRegistrar:abstractRegistrar> element can be replaced by other		<rdeRegistrar:abstractRegistrar> element can be replaced by other
	domain definitions using the XML schema substitution groups feature.		domain definitions using the XML schema substitution groups feature.
	5.4.1.1. <rdeRegistrar:registrar> element		5.4.1.1. <rdeRegistrar:registrar> Element
	The <registrar> element contains the following child elements:		The <registrar> element contains the following child elements:
	o An <id> element that contains the Registry-unique identifier of		* An <id> element that contains the registry-unique identifier of
	the registrar object. This <id> has a superordinate relationship		the registrar object. This <id> has a superordinate relationship
	to a subordinate <clID>, <crRr> or <upRr> of domain, contact and		to a subordinate <clID>, <crRr>, or <upRr> of domain, contact, and
	host objects.		host objects.
	o An <name> element that contains the name of the registrar.		* An <name> element that contains the name of the registrar.
	o An OPTIONAL <gurid> element that contains the Globally Unique		* An OPTIONAL <gurid> element that contains the GURID assigned by
	Registrar Identifier (GURID) assigned by ICANN.		ICANN.
	o An OPTIONAL <status> element that contains the operational status		* An OPTIONAL <status> element that contains the operational status
	of the registrar. Possible values are: ok, readonly and		of the registrar. Possible values are: ok, readonly, and
	terminated.		terminated.
	o One or two OPTIONAL <postalInfo> elements that contain postal-		* One or two OPTIONAL <postalInfo> elements that contain postal
	address information. Two elements are provided so that address		address information. Two elements are provided so that address
	information can be provided in both internationalized and		information can be provided in both internationalized and
	localized forms; a "type" attribute is used to identify the two		localized forms; a "type" attribute is used to identify the two
	forms. If an internationalized form (type="int") is provided,		forms. If an internationalized form (type="int") is provided,
	element content MUST be represented in a subset of UTF-8 that can		element content MUST be represented in a subset of UTF-8 that can
	be represented in the 7-bit US-ASCII character set. If a		be represented in the 7-bit US-ASCII character set. If a
	localized form (type="loc") is provided, element content MAY be		localized form (type="loc") is provided, element content MAY be
	represented in unrestricted UTF-8. The <postalInfo> element		represented in unrestricted UTF-8. The <postalInfo> element
	contains the following child elements:		contains the following child elements:
	* A <addr> element that contains address information associated		- A <addr> element that contains address information associated
	with the registrar. The <addr> element contains the following		with the registrar. The <addr> element contains the following
	child elements:		child elements:
	+ One, two, or three OPTIONAL <street> elements that contain		o One, two, or three OPTIONAL <street> elements that contain
	the registrar's street address.		the registrar's street address.
	+ A <city> element that contains the registrar's city.		o A <city> element that contains the registrar's city.
	+ An OPTIONAL <sp> element that contains the registrar's state		o An OPTIONAL <sp> element that contains the registrar's state
	or province.		or province.
	+ An OPTIONAL <pc> element that contains the registrar's		o An OPTIONAL <pc> element that contains the registrar's
	postal code.		postal code.
	+ A <cc> element that contains the registrar's country code.		o A <cc> element that contains the registrar's country code.
	o An OPTIONAL <voice> element that contains the registrar's voice		* An OPTIONAL <voice> element that contains the registrar's voice
	telephone number.		telephone number.
	o An OPTIONAL <fax> element that contains the registrar's facsimile		* An OPTIONAL <fax> element that contains the registrar's facsimile
	telephone number.		telephone number.
	o An OPTIONAL <email> element that contains the registrar's email		* An OPTIONAL <email> element that contains the registrar's email
	address.		address.
	o An OPTIONAL <url> element that contains the registrar's URL.		* An OPTIONAL <url> element that contains the registrar's URL.
	o An OPTIONAL <whoisInfo> elements that contains whois information.		* An OPTIONAL <whoisInfo> element that contains WHOIS information.
	The <whoisInfo> element contains the following child elements:		The <whoisInfo> element contains the following child elements:
	* An OPTIONAL <name> element that contains the name of the		- An OPTIONAL <name> element that contains the name of the
	registrar WHOIS server listening on TCP port 43 as specified in		registrar WHOIS server listening on TCP port 43 as specified in
	[RFC3912].		[RFC3912].
	* An OPTIONAL <url> element that contains the name of the		- An OPTIONAL <url> element that contains the name of the
	registrar WHOIS server listening on TCP port 80/443.		registrar WHOIS server listening on TCP port 80/443.
	o An OPTIONAL <crDate> element that contains the date and time of		* An OPTIONAL <crDate> element that contains the creation date and
	registrar-object creation.		time of the registrar object.
	o An OPTIONAL <upDate> element that contains the date and time of		* An OPTIONAL <upDate> element that contains the date and time of
	the most recent registrar-object modification. This element MUST		the most recent modification of the registrar object. This
	NOT be present if the registrar-object has never been modified.		element MUST NOT be present if the registrar object has never been
			modified.
	Example of a <registrar> object:		The following is an example of a <registrar> object:
	...		...
	<rdeRegistrar:registrar>		<rdeRegistrar:registrar>
	<rdeRegistrar:id>RegistrarX</rdeRegistrar:id>		<rdeRegistrar:id>RegistrarX</rdeRegistrar:id>
	<rdeRegistrar:name>Registrar X</rdeRegistrar:name>		<rdeRegistrar:name>Registrar X</rdeRegistrar:name>
	<rdeRegistrar:gurid>8</rdeRegistrar:gurid>		<rdeRegistrar:gurid>8</rdeRegistrar:gurid>
	<rdeRegistrar:status>ok</rdeRegistrar:status>		<rdeRegistrar:status>ok</rdeRegistrar:status>
	<rdeRegistrar:postalInfo type="int">		<rdeRegistrar:postalInfo type="int">
	<rdeRegistrar:addr>		<rdeRegistrar:addr>
	<rdeRegistrar:street>123 Example Dr.</rdeRegistrar:street>		<rdeRegistrar:street>123 Example Dr.</rdeRegistrar:street>
	skipping to change at page 66, line 43 ¶		skipping to change at line 2878 ¶
	<rdeRegistrar:url>http://www.example.example</rdeRegistrar:url>		<rdeRegistrar:url>http://www.example.example</rdeRegistrar:url>
	<rdeRegistrar:whoisInfo>		<rdeRegistrar:whoisInfo>
	<rdeRegistrar:name>whois.example.example</rdeRegistrar:name>		<rdeRegistrar:name>whois.example.example</rdeRegistrar:name>
	<rdeRegistrar:url>http://whois.example.example</rdeRegistrar:url>		<rdeRegistrar:url>http://whois.example.example</rdeRegistrar:url>
	</rdeRegistrar:whoisInfo>		</rdeRegistrar:whoisInfo>
	<rdeRegistrar:crDate>2005-04-23T11:49:00.0Z</rdeRegistrar:crDate>		<rdeRegistrar:crDate>2005-04-23T11:49:00.0Z</rdeRegistrar:crDate>
	<rdeRegistrar:upDate>2009-02-17T17:51:00.0Z</rdeRegistrar:upDate>		<rdeRegistrar:upDate>2009-02-17T17:51:00.0Z</rdeRegistrar:upDate>
	</rdeRegistrar:registrar>		</rdeRegistrar:registrar>
	...		...
	5.4.1.2. <rdeRegistrar:delete> object		5.4.1.2. <rdeRegistrar:delete> Object
	The <rdeRegistrar:delete> element contains the id of a registrar that		The <rdeRegistrar:delete> element contains the id of a registrar that
	was deleted.		was deleted.
	Example of <rdeRegistrar:delete> object:		The following is an example of <rdeRegistrar:delete> object:
	...		...
	<rde:deletes>		<rde:deletes>
	...		...
	<rdeRegistrar:delete>		<rdeRegistrar:delete>
	<rdeRegistrar:id>agnt0001-TEST</rdeRegistrar:id>		<rdeRegistrar:id>agnt0001-TEST</rdeRegistrar:id>
	</rdeRegistrar:delete>		</rdeRegistrar:delete>
	...		...
	</rde:deletes>		</rde:deletes>
	...		...
	5.4.2. CSV Model		5.4.2. CSV Model
	For the CSV Model of the registrar object, the		For the CSV model of the registrar object, the
	<csvRegistrar:contents> child element of the <rde:contents> element		<csvRegistrar:contents> child element of the <rde:contents> element
	is used to hold the new or updated registrar objects for the deposit.		is used to hold the new or updated registrar objects for the deposit.
	The <csvRegistrar:deletes> child element of the <rde:deletes> element		The <csvRegistrar:deletes> child element of the <rde:deletes> element
	is used to hold the deleted or purged registrar objects for the		is used to hold the deleted or purged registrar objects for the
	deposit. Both the <csvRegistrar:contents> and <csvRegistrar:deletes>		deposit. Both the <csvRegistrar:contents> and <csvRegistrar:deletes>
	elements contain one or more <rdeCsv:csv> elements with a set of		elements contain one or more <rdeCsv:csv> elements with a set of
	named CSV file definitions using the <rdeCsv:csv> "name" attribute.		named CSV file definitions using the <rdeCsv:csv> "name" attribute.
	Differential and Incremental Deposits are based on changes to the		Differential and Incremental Deposits are based on changes to the
	registrar objects. The updated registrar object data under the		registrar objects. The updated registrar object data under the
	<csvContact:contents> element is a cascade replace down all of the		<csvContact:contents> element is a cascade replace down all of the
	registrar CSV files starting with the parent "registrar" CSV File		registrar CSV files starting with the parent '"registrar" CSV File
	Definition (Section 5.4.2.1.1). The child CSV file definitions		Definition' (Section 5.4.2.1.1). The child CSV file definitions
	include a <csvRegistrar:fId parent="true"> field. All the child CSV		include a <csvRegistrar:fId parent="true"> field. All the child CSV
	file definition data for the registrar objects in the parent		file definition data for the registrar objects in the parent
	"registrar" CSV File Definition (Section 5.4.2.1.1) MUST first be		'"registrar" CSV File Definition' (Section 5.4.2.1.1) MUST first be
	deleted and then set using the data in the child CSV files. The		deleted and then set using the data in the child CSV files. The
	deleted registrar object data under the <csvRegistrar:deletes>		deleted registrar object data under the <csvRegistrar:deletes>
	element is a cascade delete starting from the "registrar" Deletes CSV		element is a cascade delete starting from the '"registrar" Deletes
	File Definition (Section 5.4.2.2.1).		CSV File Definition' (Section 5.4.2.2.1).
	5.4.2.1. <csvRegistrar:contents>		5.4.2.1. <csvRegistrar:contents>
	The <csvRegistrar:contents> is used to hold the new or updated		The <csvRegistrar:contents> is used to hold the new or updated
	registrar object information for the deposit. The		registrar object information for the deposit. The
	<csvRegistrar:contents> is split into separate CSV file definitions		<csvRegistrar:contents> is split into separate CSV file definitions
	using named <rdeCsv:csv> elements with the "name" attribute. The		using named <rdeCsv:csv> elements with the "name" attribute. The
	following sections include the supported contact CSV file		following sections include the supported registrar CSV file
	definitions.		definitions.
	5.4.2.1.1. "registrar" CSV File Definition		5.4.2.1.1. "registrar" CSV File Definition
	The "registrar" CSV File Definition defines the fields and CSV file		The "registrar" CSV File Definition defines the fields and CSV file
	references used for the registrar object records.		references used for the registrar object records.
	The following "csvRegistrar" field elements MUST be used in the		The following "csvRegistrar" field elements MUST be used in the
	"registrar" <rdeCsv:csv> <rdeCsv:fields> element:		"registrar" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvRegistrar:fId> or <csvRegistrar:fGurid> A choice of:		<csvRegistrar:fId> or <csvRegistrar:fGurid> A choice of the
			following:
	<csvRegistrar:fId> Contains the server-unique registrar		<csvRegistrar:fId> Contains the server-unique registrar
	identifier with type="eppcom:clIDType" and isRequired="true".		identifier with type="eppcom:clIDType" and isRequired="true".
	<csvRegistrar:fGurid> Contains the Globally Unique Registrar		<csvRegistrar:fGurid> Contains the GURID assigned by ICANN with
	Identifier (GURID) assigned by ICANN with
	type="positiveInteger" and isRequired="true".		type="positiveInteger" and isRequired="true".
	<csvRegistrar:fName> Contains the name of the registrar with		<csvRegistrar:fName> Contains the name of the registrar with
	type="normalizedString" and isRequired="true".		type="normalizedString" and isRequired="true".
	The following field elements MAY be used in the "registrar"		The following field elements MAY be used in the "registrar"
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:csv> <rdeCsv:fields> element:
	<csvRegistrar:fStatus> Contains the status of the registrar with		<csvRegistrar:fStatus> Contains the status of the registrar with
	type="csvRegistrar:statusValueType".		type="csvRegistrar:statusValueType".
	<csvRegistrar:fGurid> Contains the ID assigned by ICANN with		<csvRegistrar:fGurid> Contains the ID assigned by ICANN with
	type="positiveInteger". This field is included in this section in		type="positiveInteger". This field is included in this section in
	addition to the section above to support optionally providing the		addition to the section above to support optionally providing the
	<csvRegistrar:fGurid> field when the <csvRegistrar:fId> field is		<csvRegistrar:fGurid> field when the <csvRegistrar:fId> field is
	used.		used.
	<csvRegistrar:fWhoisUrl> Contains the Whois URL of the registrar		<csvRegistrar:fWhoisUrl> Contains the Whois URL of the registrar
	with type="anyURI".		with type="anyURI".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "registrar"		(Section 4.6.2.2), MAY be used in the "registrar" <rdeCsv:csv>
	<rdeCsv:csv> <rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fCrDate> Created date and time of the registrar object.		<rdeCsv:fCrDate> Date and time of the registrar object creation.
	<rdeCsv:fUpDate> Date and time of the last update to the registrar		<rdeCsv:fUpDate> Date and time of the last update to the registrar
	object. This field MUST NOT be set if the domain name object has		object. This field MUST NOT be set if the domain name object has
	never been modified.		never been modified.
	<rdeCsv:fUrl> URL for the registrar web home page.		<rdeCsv:fUrl> URL for the registrar web home page.
	The following "csvContact" fields, defined in section Contact Object		The following "csvContact" fields, defined in 'Contact Object'
	(Section 5.3), MAY be used in the "registrar" <rdeCsv:csv>		(Section 5.3), MAY be used in the "registrar" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<csvContact:fStreet> Registrar street address line with an "index"		<csvContact:fStreet> Registrar street address line with an "index"
	attribute that represents the order of the street address line		attribute that represents the order of the street address line
	from "0" to "2". An OPTIONAL "isLoc" attribute that is used to		from "0" to "2". An OPTIONAL "isLoc" attribute that is used to
	indicate the localized or internationalized form, as defined in		indicate the localized or internationalized form, as defined in
	Section 4.6.3.		Section 4.6.3.
	<csvContact:fCity> Registrar city with an OPTIONAL "isLoc" attribute		<csvContact:fCity> Registrar city with an OPTIONAL "isLoc" attribute
	skipping to change at page 70, line 5 ¶		skipping to change at line 3012 ¶
	internationalized form, as defined in Section 4.6.3.		internationalized form, as defined in Section 4.6.3.
	<csvContact:fVoice> Registrar voice telephone number.		<csvContact:fVoice> Registrar voice telephone number.
	<csvContact:fVoiceExt> Registrar voice telephone number extension.		<csvContact:fVoiceExt> Registrar voice telephone number extension.
	<csvContact:fFax> Registrar facsimile telephone number.		<csvContact:fFax> Registrar facsimile telephone number.
	<csvContact:fFaxExt> Registrar facsimile telephone number extension.		<csvContact:fFaxExt> Registrar facsimile telephone number extension.
	Example of a "registrar" <csvRegistrar:contents> <rdeCsv:csv>		The following is an example of a "registrar" <csvRegistrar:contents>
	element.		<rdeCsv:csv> element:
	...		...
	<csvRegistrar:contents>		<csvRegistrar:contents>
	...		...
	<rdeCsv:csv name="registrar">		<rdeCsv:csv name="registrar">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvRegistrar:fId/>		<csvRegistrar:fId/>
	<csvRegistrar:fName isLoc="false"/>		<csvRegistrar:fName isLoc="false"/>
	<csvRegistrar:fGurid/>		<csvRegistrar:fGurid/>
	<csvRegistrar:fStatus/>		<csvRegistrar:fStatus/>
	skipping to change at page 70, line 45 ¶		skipping to change at line 3052 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="57F6856F">		cksum="57F6856F">
	registrar-YYYYMMDD.csv		registrar-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvRegistrar:contents>		</csvRegistrar:contents>
	...		...
	Example of the registrar-YYYYMMDD.csv file. The file contains one		The following is an example of the registrar-YYYYMMDD.csv file. The
	registrar record.		file contains one registrar record:
	registrarX,"Example Inc.",8,ok,"123 Example Dr.",		registrarX,"Example Inc.",8,ok,"123 Example Dr.",
	"Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234,		"Suite 100",,Dulles,VA,20166-6503,US,+1.7035555555,1234,
	+1.7035555556,,jdoe@example.example,http://www.example.example,		+1.7035555556,,jdoe@example.example,http://www.example.example,
	http://whois.example.example,2005-04-23T11:49:00.0Z,		http://whois.example.example,2005-04-23T11:49:00.0Z,
	2009-02-17T17:51:00.0Z		2009-02-17T17:51:00.0Z
	5.4.2.2. <csvRegistrar:deletes>		5.4.2.2. <csvRegistrar:deletes>
	The <csvRegistrar:deletes> is used to hold the deleted registrar		The <csvRegistrar:deletes> is used to hold the deleted registrar
	skipping to change at page 71, line 20 ¶		skipping to change at line 3076 ¶
	<csvRegistrar:deletes> is split into separate CSV file definitions		<csvRegistrar:deletes> is split into separate CSV file definitions
	using named <rdeCsv:csv> elements with the "name" attribute. The		using named <rdeCsv:csv> elements with the "name" attribute. The
	following section defines the supported registrar deletes CSV file		following section defines the supported registrar deletes CSV file
	definition.		definition.
	5.4.2.2.1. "registrar" Deletes CSV File Definition		5.4.2.2.1. "registrar" Deletes CSV File Definition
	The following "csvRegistrar" field elements MUST be used in the		The following "csvRegistrar" field elements MUST be used in the
	deletes "registrar" <rdeCsv:csv> <rdeCsv:fields> element:		deletes "registrar" <rdeCsv:csv> <rdeCsv:fields> element:
	<csvRegistrar:fId> or <csvRegistrar:fGurid> A choice of:		<csvRegistrar:fId> or <csvRegistrar:fGurid> A choice of the
			following:
	<csvRegistrar:fId> Contains the server-unique registrar		<csvRegistrar:fId> Contains the server-unique registrar
	identifier with type="eppcom:clIDType" and isRequired="true".		identifier with type="eppcom:clIDType" and isRequired="true".
	<csvRegistrar:fGurid> Contains the Globally Unique Registrar		<csvRegistrar:fGurid> Contains the GURID assigned by ICANN with
	Identifier (GURID) assigned by ICANN with
	type="positiveInteger". The attribute "isRequired" MUST equal		type="positiveInteger". The attribute "isRequired" MUST equal
	"true".		"true".
	Example of a "registrar" <csvRegistrar:deletes> <rdeCsv:csv> element.		The following is an example of a "registrar" <csvRegistrar:deletes>
			<rdeCsv:csv> element:
	...		...
	<csvRegistrar:deletes>		<csvRegistrar:deletes>
	...		...
	<rdeCsv:csv name="registrar">		<rdeCsv:csv name="registrar">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvRegistrar:fId/>		<csvRegistrar:fId/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="5CB20A52">		cksum="5CB20A52">
	registrar-delete-YYYYMMDD.csv		registrar-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvRegistrar:deletes>		</csvRegistrar:deletes>
	...		...
	Example of the registrar-delete-YYYYMMDD.csv file. The file contains		The following is an example of the registrar-delete-YYYYMMDD.csv
	one registrar record.		file. The file contains one registrar record:
	registrarZ		registrarZ
	5.5. IDN Table Reference Object		5.5. IDN Table Reference Object
	The Internationalized Domain Names (IDN) table reference object is a		The Internationalized Domain Names (IDN) table reference object is a
	pseudo-object that is used to provide a short reference to the IDN		pseudo-object that is used to provide a short reference to the IDN
	Table and Policy used in IDN registrations. The IDN reference object		table and policy used in IDN registrations. The IDN reference object
	supports both the XML and the CSV Model, defined in the Models		supports both the XML and the CSV model, defined in 'Models'
	(Section 2) section. The elements used for both models are defined		(Section 2). The elements used for both models are defined in the
	in the following sections.		following sections.
	5.5.1. XML Model		5.5.1. XML Model
	There is one element used in the data escrow of the IDN table		There is one element used in the data escrow of the IDN table
	reference objects for the XML model that is the <rdeIDN:idnTableRef>,		reference objects for the XML model, and that is the
	under the <rde:contents> element.		<rdeIDN:idnTableRef>, under the <rde:contents> element.
	5.5.1.1. <rdeIDN:idnTableRef> object		5.5.1.1. <rdeIDN:idnTableRef> Object
	The <rdeIDN:idnTableRef> contains the following elements. An "id"		The <rdeIDN:idnTableRef> contains the following elements. An "id"
	attribute is used to specify an identifier for the IDN table.		attribute is used to specify an identifier for the IDN table.
	o An <url> element that contains the URL of the IDN table that is		* A <url> element that contains the URL of the IDN table that is
	being referenced.		being referenced.
	o A <urlPolicy> element that contains the URL of the IDN policy		* A <urlPolicy> element that contains the URL of the IDN policy
	document. If IDN variants are generated algorithmically, the		document. If IDN variants are generated algorithmically, the
	policy document MUST define the algorithm and the state of the		policy document MUST define the algorithm and the state of the
	implicit generated IDN variants. For a list of suggested states		implicitly generated IDN variants. For a list of suggested states
	for implicit IDN variants, please see [variantTLDsReport].		for implicit IDN variants, please see [variantTLDsReport].
	Example of <idnTableRef> object:		The following is an example of <idnTableRef> object:
	...		...
	<rdeIDN:idnTableRef id="pt-BR">		<rdeIDN:idnTableRef id="pt-BR">
	<rdeIDN:url>		<rdeIDN:url>
	http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html		http://www.iana.org/domains/idn-tables/tables/br_pt-br_1.0.html
	</rdeIDN:url>		</rdeIDN:url>
	<rdeIDN:urlPolicy>		<rdeIDN:urlPolicy>
	http://registro.br/dominio/regras.html		http://registro.br/dominio/regras.html
	</rdeIDN:urlPolicy>		</rdeIDN:urlPolicy>
	</rdeIDN:idnTableRef>		</rdeIDN:idnTableRef>
	...		...
	5.5.2. CSV Model		5.5.2. CSV Model
	The IDN domain names, defined in Section 5.1, MAY have references to		The IDN domain names, defined in Section 5.1, MAY have references to
	the IDN language identifier using the <rdeCsv:fIdnTableId> field		the IDN language identifier using the <rdeCsv:fIdnTableId> field
	element. The IDN table reference object defines the mapping of a		element. The IDN table reference object defines the mapping of a
	language identifier to a language table URL. The language table URL		language identifier to a language table URL. The language table URL
	defines the character code points that can be used for the language		defines the character code points that can be used for the language
	identifier. The elements used for the IDN table reference object is		identifier. The elements used for the IDN table reference object are
	defined in this section. The <csvIDN:contents> child element of the		defined in this section. The <csvIDN:contents> child element of the
	<rde:contents> element is used to hold the new or updated IDN table		<rde:contents> element is used to hold the new or updated IDN table
	reference objects for the deposit. The <csvIDN:deletes> child		reference objects for the deposit. The <csvIDN:deletes> child
	element of the <rde:deletes> element is used to hold the deleted or		element of the <rde:deletes> element is used to hold the deleted or
	purged IDN table reference objects for the deposit. Both the		purged IDN table reference objects for the deposit. Both the
	<csvIDN:contents> and <csvIDN:deletes> elements contain one or more		<csvIDN:contents> and <csvIDN:deletes> elements contain one or more
	<rdeCsv:csv> elements with a set of named CSV file definitions using		<rdeCsv:csv> elements with a set of named CSV file definitions using
	the <rdeCsv:csv> "name" attribute.		the <rdeCsv:csv> "name" attribute.
	5.5.2.1. <csvIDN:contents>		5.5.2.1. <csvIDN:contents>
	skipping to change at page 73, line 39 ¶		skipping to change at line 3188 ¶
	5.5.2.1.1. "idnLanguage" CSV File Definition		5.5.2.1.1. "idnLanguage" CSV File Definition
	The "idnLanguage" CSV File Definition defines the fields and CSV file		The "idnLanguage" CSV File Definition defines the fields and CSV file
	references used for the IDN table reference object records.		references used for the IDN table reference object records.
	The following "rdeCsv" fields, defined in Section 4.6.2.2, MUST be		The following "rdeCsv" fields, defined in Section 4.6.2.2, MUST be
	used in the "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:		used in the "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:
	<rdeCsv:fIdnTableId> The language identifier that matches the values		<rdeCsv:fIdnTableId> The language identifier that matches the values
	for the <rdeCsv:fIdnTableId> field element in the "domain" CSV		for the <rdeCsv:fIdnTableId> field element in the '"domain" CSV
	File Definition (Section 5.1.2.1.1) files. The attribute		File Definition' (Section 5.1.2.1.1) files. The attribute
	"isRequired" MUST equal "true".		"isRequired" MUST equal "true".
	<rdeCsv:fUrl> URL that defines the character code points that can be		<rdeCsv:fUrl> URL that defines the character code points that can be
	used for <csvDomain:fName> field in the "domain" CSV File		used for <csvDomain:fName> field in the '"domain" CSV File
	Definition Section 5.1.2.1.1 files. The attribute "isRequired"		Definition' (Section 5.1.2.1.1) files. The attribute "isRequired"
	MUST equal "true".		MUST equal "true".
	Example of a "idnLanguage" <csvIDN:contents> <rdeCsv:csv> element.		The following is an example of a "idnLanguage" <csvIDN:contents>
			<rdeCsv:csv> element:
	...		...
	<csvIDN:contents>		<csvIDN:contents>
	...		...
	<rdeCsv:csv name="idnLanguage" sep=",">		<rdeCsv:csv name="idnLanguage" sep=",">
	<rdeCsv:fields>		<rdeCsv:fields>
	<rdeCsv:fIdnTableId isRequired="true"/>		<rdeCsv:fIdnTableId isRequired="true"/>
	<rdeCsv:fUrl isRequired="true"/>		<rdeCsv:fUrl isRequired="true"/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="D6B0424F">		cksum="D6B0424F">
	idnLanguage-YYYYMMDD.csv		idnLanguage-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvIDN:contents>		</csvIDN:contents>
	...		...
	Example of the corresponding idnLanguage-YYYYMMDD.csv file. The file		The following is an example of the corresponding idnLanguage-
	contains two IDN language records.		YYYYMMDD.csv file. The file contains two IDN language records:
	LANG-1,		LANG-1,
	http://www.iana.org/domains/idn-tables/tables/test_tab1_1.1.txt		http://www.iana.org/domains/idn-tables/tables/test_tab1_1.1.txt
	LANG-2,		LANG-2,
	http://www.iana.org/domains/idn-tables/tables/test_tab2_1.1.txt		http://www.iana.org/domains/idn-tables/tables/test_tab2_1.1.txt
	5.5.2.2. <csvIDN:deletes>		5.5.2.2. <csvIDN:deletes>
	The <csvIDN:deletes> is used to hold the deleted IDN table reference		The <csvIDN:deletes> is used to hold the deleted IDN table reference
	objects in a Differential or Incremental Deposit. The		objects in a Differential or Incremental Deposit. The
	skipping to change at page 74, line 49 ¶		skipping to change at line 3242 ¶
	named <rdeCsv:csv> elements with the "name" attribute. The following		named <rdeCsv:csv> elements with the "name" attribute. The following
	section defines the supported IDN table reference deletes CSV file		section defines the supported IDN table reference deletes CSV file
	definition.		definition.
	5.5.2.2.1. "idnLanguage" Deletes CSV File Definition		5.5.2.2.1. "idnLanguage" Deletes CSV File Definition
	The following "idnLanguage" field elements MUST be used in the		The following "idnLanguage" field elements MUST be used in the
	deletes "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:		deletes "idnLanguage" <rdeCsv:csv> <rdeCsv:fields> element:
	<rdeCsv:fIdnTableId> The language identifier that matches the values		<rdeCsv:fIdnTableId> The language identifier that matches the values
	for the <rdeCsv:fIdnTableId> field element in the "domain" CSV		for the <rdeCsv:fIdnTableId> field element in the '"domain" CSV
	File Definition (Section 5.1.2.1.1) files. The attribute		File Definition' (Section 5.1.2.1.1) files. The attribute
	"isRequired" MUST equal "true".		"isRequired" MUST equal "true".
	Example of a "idnLanguage" <csvIDN:deletes> <rdeCsv:csv> element.		The following is an example of a "idnLanguage" <csvIDN:deletes>
			<rdeCsv:csv> element:
	...		...
	<csvIDN:deletes>		<csvIDN:deletes>
	...		...
	<rdeCsv:csv name="idnLanguage">		<rdeCsv:csv name="idnLanguage">
	<rdeCsv:fields>		<rdeCsv:fields>
	<rdeCsv:fIdnTableId isRequired="true"/>		<rdeCsv:fIdnTableId isRequired="true"/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="4A28A569">		cksum="4A28A569">
	idnLanguage-delete-YYYYMMDD.csv		idnLanguage-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvIDN:deletes>		</csvIDN:deletes>
	...		...
	Example of the idnLanguage-delete-YYYYMMDD.csv file. The file		The following is an example of the idnLanguage-delete-YYYYMMDD.csv
	contains one IDN language record.		file. The file contains one IDN language record:
	LANG-2		LANG-2
	5.6. NNDN Object		5.6. NNDN Object
	An NNDN (NNDN's not domain name) can be used to store registry		An NNDN (NNDN's not domain name) can be used to store registry
	reserved names or (blocked, withheld or mirrored) IDN variants.		reserved names or (blocked, withheld, or mirrored) IDN variants.
	Domain Name Registries may maintain domain names without their being		Domain name registries may maintain domain names without their being
	persisted as domain objects in the registry system, for example, a		persisted as domain objects in the registry system, for example, a
	list of reserved names not available for registration. The NNDN is a		list of reserved names not available for registration. The NNDN is a
	lightweight domain-like object that is used to escrow domain names		lightweight domain-like object that is used to escrow domain names
	not maintained as domain name objects.		not maintained as domain name objects.
	A domain name can only exist as a domain name object or an NNDN		A domain name can only exist as a domain name object or an NNDN
	object, but not both.		object, but not both.
	The NNDN object supports both the XML and the CSV Model, defined in		The NNDN object supports both the XML and the CSV model, defined in
	the Models (Section 2) section. The elements used for both models		'Models' (Section 2). The elements used for both models are defined
	are defined in the following sections.		in the following sections.
	5.6.1. XML Model		5.6.1. XML Model
	There are two elements used in the data escrow of the NNDN objects		There are two elements used in the data escrow of the NNDN objects
	for the XML model including the <rdeNNDN:NNDN>, under the		for the XML model including the <rdeNNDN:NNDN> element, under the
	<rde:contents> element, and the <rdeNNDN:delete> element, under the		<rde:contents> element, and the <rdeNNDN:delete> element, under the
	<rde:deletes> element.		<rde:deletes> element.
	A <rdeNNDN:NNDN> element substitutes for the <rdeNNDN:abstractNNDN>		An <rdeNNDN:NNDN> element substitutes for the <rdeNNDN:abstractNNDN>
	abstract element to define a concrete definition of an NNDN. The		abstract element to create 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 qualified		* An <aName> element that contains the fully qualified name of the
	name of the NNDN. For IDNs the A-Label is used (see [RFC5891],		NNDN. For IDNs, the A-label is used (see [RFC5891], Section 4.4).
	Section 4.4).
	o An OPTIONAL <uName> element that contains the fully-qualified name		* 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 the Unicode character set. It MUST be provided if
	available.		available.
	o An OPTIONAL <idnTableId> element that references the IDN		* An OPTIONAL <idnTableId> element that references the IDN table
	Table used for the NNDN. This corresponds to the "id" attribute		used for the NNDN. This corresponds to the "id" attribute of the
	of the <idnTableRef> element. This element MUST be present if the		<idnTableRef> element. This element MUST be present if the NNDN
	NNDN is an IDN.		is an IDN.
	o An OPTIONAL <originalName> element is used to indicate that the		* 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
	name used to generate the IDN variant.		name used to generate the IDN variant.
	o A <nameState> element that indicates the state of the NNDN:		* A <nameState> element that indicates the state of the NNDN:
	blocked, withheld or mirrored.		blocked, withheld, or mirrored.
	* If an NNDN is considered undesirable for registration (i.e.,		- If an NNDN is considered undesirable for registration (i.e.,
	unavailable for allocation to anyone), then the NNDN will be		unavailable for allocation to anyone), then the NNDN will be
	tagged as "blocked".		tagged as "blocked".
	* If an NNDN is considered a potential registration of a domain		- If an NNDN is considered a potential registration of a domain
	name 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		"withheld". This status is only used when the NNDN is used for
	an IDN variant.		an IDN variant.
	* If an NNDN is considered a mirrored IDN variant of a domain		- If an NNDN is considered a mirrored IDN variant of a domain
	name 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		"mirroringNS" attribute is used to specify if the mirrored IDN
	variant uses the NS mirror mechanism, meaning that the		variant uses the NS mirror mechanism, meaning that the
	activated variant domain name (i.e., NNDN) is delegated in the		activated variant domain name (i.e., NNDN) is delegated in the
	DNS using the same NS records as in the <originalName>. The		DNS using the same NS records as in the <originalName>. The
	default value of mirroringNS is true. If another mechanism		default value of "mirroringNS" is true. If another mechanism
	such as DNAME is used, the value of mirroringNS attribute MUST		such as DNAME [RFC6672] is used, the value of the "mirroringNS"
	be false.		attribute MUST be false.
	o An OPTIONAL <crDate> element that contains the date and time of		* An OPTIONAL <crDate> element that contains the date and time of
	the NNDN object creation.		the NNDN object creation.
	Example of an <rdeNNDN:NNDN> object:		The following is an example of an <rdeNNDN:NNDN> object:
	...		...
	<rdeNNDN:NNDN>		<rdeNNDN:NNDN>
	<rdeNNDN:aName>xn--exampl-gva.example</rdeNNDN:aName>		<rdeNNDN:aName>xn--exampl-gva.example</rdeNNDN:aName>
	<rdeNNDN:idnTableId>pt-BR</rdeNNDN:idnTableId>		<rdeNNDN:idnTableId>pt-BR</rdeNNDN:idnTableId>
	<rdeNNDN:originalName>example.example</rdeNNDN:originalName>		<rdeNNDN:originalName>example.example</rdeNNDN:originalName>
	<rdeNNDN:nameState>withheld</rdeNNDN:nameState>		<rdeNNDN:nameState>withheld</rdeNNDN:nameState>
	<rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>		<rdeNNDN:crDate>2005-04-23T11:49:00.0Z</rdeNNDN:crDate>
	</rdeNNDN:NNDN>		</rdeNNDN:NNDN>
	...		...
	5.6.1.2. <rdeNNDN:delete> object		5.6.1.2. <rdeNNDN:delete> Object
	The <rdeNNDN:delete> element contains the NNDN that was deleted,		The <rdeNNDN:delete> element contains the NNDN that was deleted,
	i.e., the <aName>.		i.e., the <aName>.
	Example of an <rdeNNDN::delete> object:		The following is an example of an <rdeNNDN::delete> object:
	...		...
	<rde:deletes>		<rde:deletes>
	...		...
	<rdeNNDN:delete>		<rdeNNDN:delete>
	<rdeNNDN:aName>xn--pingino-q2a.example</rdeNNDN:aName>		<rdeNNDN:aName>xn--pingino-q2a.example</rdeNNDN:aName>
	</rdeNNDN:delete>		</rdeNNDN:delete>
	...		...
	</rde:deletes>		</rde:deletes>
	...		...
	5.6.2. CSV Model		5.6.2. CSV Model
	For the CSV Model of the NNDN object, the <csvNNDN:contents> child		For the CSV model of the NNDN object, the <csvNNDN:contents> child
	element of the <rde:contents> element is used to hold the new or		element of the <rde:contents> element is used to hold the new or
	updated NNDN objects for the deposit. The <csvNNDN:deletes> child		updated NNDN objects for the deposit. The <csvNNDN:deletes> child
	element of the <rde:deletes> element is used to hold the deleted or		element of the <rde:deletes> element is used to hold the deleted or
	purged NNDN objects for the deposit. Both the <csvNNDN:contents> and		purged NNDN objects for the deposit. Both the <csvNNDN:contents> and
	<csvNNDN:deletes> elements contain one or more <rdeCsv:csv> elements		<csvNNDN:deletes> elements contain one or more <rdeCsv:csv> elements
	with a set of named CSV file definitions using the <rdeCsv:csv>		with a set of named CSV file definitions using the <rdeCsv:csv>
	"name" attribute.		"name" attribute.
	5.6.2.1. <csvNNDN:contents>		5.6.2.1. <csvNNDN:contents>
	skipping to change at page 78, line 21 ¶		skipping to change at line 3403 ¶
	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:
	<csvNNDN:fOriginalName> Domain name used to generate the IDN variant		<csvNNDN:fOriginalName> Domain name used to generate the IDN variant
	with type="eppcom:labelType".		with type="eppcom:labelType".
	<csvNNDN:fMirroringNS> Defines whether the "mirroring"		<csvNNDN:fMirroringNS> Defines whether the "mirroring"
	<csvNNDN:fNameState> uses the NS mirror mechanism, as described		<csvNNDN:fNameState> uses the NS mirror mechanism, as described
	for the <rdeNNDN:nameState> "mirroringNS" attribute in		for the <rdeNNDN:nameState> "mirroringNS" attribute in
	Section 5.6.1.1, with type="boolean". If the field element is not		Section 5.6.1.1, with type="boolean". If the field element is not
	defined the default value is "true".		defined the default value is "true".
	The following "rdeCsv" fields, defined in section CSV common field		The following "rdeCsv" fields, defined in 'CSV Common Field Elements'
	elements (Section 4.6.2.2), MAY be used in the "NNDN" <rdeCsv:csv>		(Section 4.6.2.2), MAY be used in the "NNDN" <rdeCsv:csv>
	<rdeCsv:fields> element:		<rdeCsv:fields> element:
	<rdeCsv:fCrDate> Created date and time of the NNDN object.		<rdeCsv:fCrDate> Date and time of the NNDN object creation.
	<rdeCsv:fUName> Name of the NNDN in Unicode character set for the		<rdeCsv:fUName> Name of the NNDN in the Unicode character set for
	<csvNNDN:fAName> field element.		the <csvNNDN:fAName> field element.
	<rdeCsv:fIdnTableId> IDN Table Identifier for the NNDN that matches		<rdeCsv:fIdnTableId> IDN table identifier for the NNDN that matches
	an IDN Table Reference Object record, as defined in Section 5.5.2.		an IDN table reference object record, as defined in Section 5.5.2.
	Example of an "NNDN" <csvNNDN:contents> <rdeCsv:csv> element:		The following is an example of an "NNDN" <csvNNDN:contents>
			<rdeCsv:csv> element:
	...		...
	<csvNNDN:contents>		<csvNNDN:contents>
	...		...
	<rdeCsv:csv name="NNDN" sep=",">		<rdeCsv:csv name="NNDN" sep=",">
	<rdeCsv:fields>		<rdeCsv:fields>
	<csvNNDN:fAName/>		<csvNNDN:fAName/>
	<rdeCsv:fIdnTableId/>		<rdeCsv:fIdnTableId/>
	<csvNNDN:fOriginalName/>		<csvNNDN:fOriginalName/>
	<csvNNDN:fNameState/>		<csvNNDN:fNameState/>
	skipping to change at page 79, line 30 ¶		skipping to change at line 3462 ¶
	<rdeCsv:file		<rdeCsv:file
	cksum="085A7CE4">		cksum="085A7CE4">
	NNDN-YYYYMMDD.csv		NNDN-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvNNDN:contents>		</csvNNDN:contents>
	...		...
	Example of the corresponding NNDN-YYYYMMDD.csv file. The file		The following is an example of the corresponding NNDN-YYYYMMDD.csv
	contains two NNDN records for an IDN with one blocked variant and one		file. The file contains two NNDN records for an IDN with one blocked
	mirrored variant.		variant and one mirrored variant:
	xn--bc456-3ve.example,LANG-1,xn--bc123-3ve.example,		xn--bc456-3ve.example,LANG-1,xn--bc123-3ve.example,
	blocked,,2005-04-23T11:49:00.0Z		blocked,,2005-04-23T11:49:00.0Z
	xn--bc789-3ve.example,LANG-1,xn--bc123-3ve.example,		xn--bc789-3ve.example,LANG-1,xn--bc123-3ve.example,
	mirrored,1,2005-04-23T11:49:00.0Z		mirrored,1,2005-04-23T11:49:00.0Z
	5.6.2.2. <csvNNDN:deletes>		5.6.2.2. <csvNNDN:deletes>
	The <csvNNDN:deletes> is used to hold the deleted NNDN objects in a		The <csvNNDN:deletes> is used to hold the deleted NNDN objects in a
	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.		The following is an 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/>
	</rdeCsv:fields>		</rdeCsv:fields>
	<rdeCsv:files>		<rdeCsv:files>
	<rdeCsv:file		<rdeCsv:file
	cksum="A41F1D9B">		cksum="A41F1D9B">
	NNDN-delete-YYYYMMDD.csv		NNDN-delete-YYYYMMDD.csv
	</rdeCsv:file>		</rdeCsv:file>
	</rdeCsv:files>		</rdeCsv:files>
	</rdeCsv:csv>		</rdeCsv:csv>
	...		...
	</csvNNDN:deletes>		</csvNNDN:deletes>
	...		...
	Example of the corresponding NNDN-delete-YYYYMMDD.csv file. The file		The following is an example of the corresponding NNDN-delete-
	contains one NNDN records.		YYYYMMDD.csv file. The file contains one NNDN records:
	xn--bc456-3ve.example		xn--bc456-3ve.example
	5.7. EPP Parameters Object		5.7. EPP Parameters Object
	The EPP Parameters Object is a pseudo-object that defines the set of		The EPP parameters object is a pseudo-object that defines the set of
	object and object extension services supported by the registry, as		object and object extension services supported by the registry, as
	defined in [RFC5730]. The EPP Parameters Object is only defined 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		XML but could be used in either the XML model or CSV model. The EPP
	Parameters Object is defined using the <rdeEppParams:eppParams>		parameters object is defined using the <rdeEppParams:eppParams>
	element. The EPP Parameters Object SHOULD be included if the		element. The EPP parameters object SHOULD be included if the
	registry supports EPP. A maximum of one EPP Parameters Object MUST		registry supports EPP. A maximum of one EPP parameters object MUST
	exist at a certain point in time (watermark).		exist at a certain point in time (Time Watermark).
	The syntax and content of the <rdeEppParams:eppParams> children		The syntax and content of the <rdeEppParams:eppParams> children
	elements is as explained in section 2.4 of [RFC5730]. The children		elements is as explained in Section 2.4 of [RFC5730]. The children
	of the <eppParams> are as follows:		of the <eppParams> are as follows:
	o One or more <version> elements that indicate the EPP versions		* One or more <version> elements that indicate the EPP versions
	supported by the registry.		supported by the registry.
	o One or more <lang> elements that indicate the identifiers of the		* One or more <lang> elements that indicate the identifiers of the
	text response languages supported by the registry's EPP server.		text response languages supported by the registry's EPP server.
	o One or more <objURI> elements that contain namespace URIs		* One or more <objURI> elements that contain namespace URIs
	representing the objects that the registry's EPP server is capable		representing the objects that the registry's EPP server is capable
	of managing.		of managing.
	o An OPTIONAL <svcExtension> element that contains one or more		* An OPTIONAL <svcExtension> element that contains one or more
	<extURI> elements that contain namespace URIs representing object		<extURI> elements that contain namespace URIs representing object
	extensions supported by the registry's EPP server.		extensions supported by the registry's EPP server.
	o A <dcp> element that contains child elements used to describe the		* A <dcp> element that contains child elements used to describe the
	server's privacy policy for data collection and management. See		server's privacy policy for data collection and management. See
	section 2.4 of [RFC5730] for more details.		Section 2.4 of [RFC5730] for more details.
	Example of <eppParams> element object:		The following is an example of <eppParams> element object:
	...		...
	<rdeEppParams:eppParams>		<rdeEppParams:eppParams>
	<rdeEppParams:version>1.0</rdeEppParams:version>		<rdeEppParams:version>1.0</rdeEppParams:version>
	<rdeEppParams:lang>en</rdeEppParams:lang>		<rdeEppParams:lang>en</rdeEppParams:lang>
	<rdeEppParams:objURI>urn:ietf:params:xml:ns:domain-1.0		<rdeEppParams:objURI>urn:ietf:params:xml:ns:domain-1.0
	</rdeEppParams:objURI>		</rdeEppParams:objURI>
	<rdeEppParams:objURI>urn:ietf:params:xml:ns:contact-1.0		<rdeEppParams:objURI>urn:ietf:params:xml:ns:contact-1.0
	</rdeEppParams:objURI>		</rdeEppParams:objURI>
	<rdeEppParams:objURI>urn:ietf:params:xml:ns:host-1.0		<rdeEppParams:objURI>urn:ietf:params:xml:ns:host-1.0
	skipping to change at page 82, line 7 ¶		skipping to change at line 3583 ¶
	<epp:retention>		<epp:retention>
	<epp:stated/>		<epp:stated/>
	</epp:retention>		</epp:retention>
	</epp:statement>		</epp:statement>
	</rdeEppParams:dcp>		</rdeEppParams:dcp>
	</rdeEppParams:eppParams>		</rdeEppParams:eppParams>
	...		...
	5.8. Policy Object		5.8. Policy Object
	The Policy object is a pseudo-object that is used to specify which		The policy object is a pseudo-object that is used to specify which
	OPTIONAL elements from the XML Model are REQUIRED based on the		OPTIONAL elements from the XML model are REQUIRED based on the
	business model of the registry. For the CSV Model, the OPTIONAL		business model of the registry. For the CSV model, the OPTIONAL
	"isRequired" attribute of the <rdeCsv:field> elements, defined in		"isRequired" attribute of the <rdeCsv:field> elements, defined in
	Section 4.6.2.1, is used to specify which OPTIONAL fields are		Section 4.6.2.1, is used to specify which OPTIONAL fields are
	REQUIRED based on the business model of the registry.		REQUIRED based on the business model of the registry.
	5.8.1. <rdePolicy:policy> object		5.8.1. <rdePolicy:policy> Object
	The OPTIONAL <policy> contains the following attributes:		The OPTIONAL <policy> contains the following attributes:
	o An <element> that defines that the referenced <element> is		* An <element> that defines that the referenced <element> is
	REQUIRED.		REQUIRED.
	o <scope> that defines the XPath (see, [W3C.REC-xpath-31-20170321])		* <scope> that defines the XPath (see [W3C.REC-xpath-31-20170321])
	of the element referenced by <element>.		of the element referenced by <element>.
	Example of <rdePolicy:policy> object:		The following is an example of <rdePolicy:policy> object:
	...		...
	<rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain"		<rdePolicy:policy scope="//rde:deposit/rde:contents/rdeDomain:domain"
	element="rdeDomain:registrant" />		element="rdeDomain:registrant" />
	...		...
	5.9. Header Object		5.9. Header Object
	The Header Object is a pseudo-object that is used to specify the		The header object is a pseudo-object that is used to specify the
	number of objects in the repository at a specific point in time		number of objects in the repository at a specific point in time
	(watermark) regardless of the type of deposit: Differential, Full or		(Timeline Watermark) regardless of the type of deposit: Differential,
	Incremental Deposit. The Header Object may also be used to provide		Full, or Incremental Deposit. The header object may also be used to
	additional information on the contents of the deposit. The Header		provide additional information on the contents of the deposit. The
	Object is only defined as XML but one header object MUST always be		header object is only defined as XML but one header object MUST
	present per escrow deposit regardless of using XML Model or CSV		always be present per escrow deposit regardless of using the XML
	Model. The Header Object is defined using the <rdeHeader:header>		model or CSV model. The header object is defined using the
	element.		<rdeHeader:header> element.
	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		* 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 RCDN being		- An <rdeHeader:tld> element that defines TLD or the RCDN being
	escrowed in the case of a Registry data escrow deposit. For		escrowed in the case of a registry data escrow deposit. For
	IDNs the A-Label is used (see [RFC5891], Section 4.4).		IDNs, the A-label is used (see [RFC5891], Section 4.4).
	* A <rdeHeader:registrar> element that defines the Registrar ID		- An <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		- An <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 (PPSP)
	escrow deposit. In the case of an ICANN-accredited Privacy and		data escrow deposit. In the case of an ICANN-accredited PPSP,
	Proxy Services Provider, the <rdeHeader:ppsp> element MUST be		the <rdeHeader:ppsp> element MUST be the unique ID assigned by
	the unique ID assigned by ICANN.		ICANN.
	* A <rdeHeader:reseller> element that defines the provider ID		- An <rdeHeader:reseller> element that defines the provider ID
	corresponding to a Reseller data escrow deposit.		corresponding to a reseller data escrow deposit.
	o A <count> element that contains the number of objects in the SRS		* A <count> element that contains the number of objects in the SRS
	at a specific point in time (watermark) regardless of the type of		at a specific point in time (Timeline Watermark) regardless of the
	deposit: Differential, Full or Incremental. The <count> element		type of deposit: Differential, Full, or Incremental. The <count>
	supports the following attributes:		element 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 RCDN of the objects		- An OPTIONAL "rcdn" attribute indicates the RCDN of the objects
	included in the <count> element. For IDNs the A-Label is used		included in the <count> element. For IDNs, the A-label is used
	[RFC5891], Section 4.4. If the "rcdn" attribute is present,		[RFC5891], Section 4.4. If the "rcdn" attribute is present,
	the value of the <count> element must include only objects		the value of the <count> element must include only objects
	related to registrations in the same and lower levels. For		related to registrations in the same and lower levels. For
	example in a data escrow deposit for the .EXAMPLE TLD, a value		example in a data escrow deposit for the .EXAMPLE TLD, a value
	of "example" in the "rcdn" attribute within the <count> element		of "example" in the "rcdn" attribute within the <count> element
	indicates the number of objects in the TLD including objects in		indicates the number of objects in the TLD including objects in
	other RCDNs within the TLD, whereas a value of "com.example"		other RCDNs within the TLD, whereas a value of "com.example"
	indicates the number of elements for objects under		indicates the number of elements for objects under
	"com.example" and lower levels. Omitting the "rcdn" attribute		"com.example" and lower levels. Omitting the "rcdn" attribute
	indicates that the total includes all objects of the specified		indicates that the total includes all objects of the specified
	"uri" in the repository (e.g. the TLD, Registrar, or PPSP).		"uri" in the repository (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		* 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.
	Example of <rdeHeader:header> object referencing only the XML Model		The following is an example of <rdeHeader:header> object referencing
	objects:		only the XML model objects:
	...		...
	<rdeHeader:header>		<rdeHeader:header>
	<rdeHeader:tld>test</rdeHeader:tld>		<rdeHeader:tld>test</rdeHeader:tld>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>		uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
	skipping to change at page 85, line 5 ¶		skipping to change at line 3707 ¶
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1		uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
	</rdeHeader:count>		</rdeHeader:count>
	</rdeHeader:header>		</rdeHeader:header>
	...		...
	Example of <rdeHeader:header> object referencing the CSV and XML		The following is an example of an <rdeHeader:header> object
	Model objects:		referencing the CSV and XML model objects:
	...		...
	<rdeHeader:header>		<rdeHeader:header>
	<rdeHeader:tld>test</rdeHeader:tld>		<rdeHeader:tld>test</rdeHeader:tld>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:csvDomain-1.0">2</rdeHeader:count>		uri="urn:ietf:params:xml:ns:csvDomain-1.0">2</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:csvHost-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:csvHost-1.0">1</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:csvContact-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:csvContact-1.0">1</rdeHeader:count>
	skipping to change at page 85, line 32 ¶		skipping to change at line 3734 ¶
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:csvNNDN-1.0">1</rdeHeader:count>		uri="urn:ietf:params:xml:ns:csvNNDN-1.0">1</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1		uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
	</rdeHeader:count>		</rdeHeader:count>
	</rdeHeader:header>		</rdeHeader:header>
	...		...
	5.10. DNRD Common Objects Collection		5.10. DNRD Common Objects Collection
	The DNRD Common Objects Collection contains data structures		The DNRD common objects collection contains data structures
	referenced by two or more of the main objects in the XML model.		referenced by two or more of the main objects in the XML model.
	6. RDE IDN Variants handling		6. RDE IDN Variants Handling
	Depending on the Registration Policy of the Registry, for a domain		Depending on the registration policy of the registry, for a domain
	name there may be multiple variant names. See [variantTLDsReport]		name there may be multiple variant names. See [variantTLDsReport]
	for further detail on IDN variants.		for further details on IDN variants.
	A registry could choose to escrow IDN variants as domains or NNDN		A registry could choose to escrow IDN variants as domains or NNDN
	objects. A specific IDN variant can be represented in the escrow		objects. A specific IDN variant can be represented in the escrow
	deposit, as a domain or as an NNDN object, but not both.		deposit, as a domain or as an NNDN object, but not both.
	If using domain objects to represent IDN variants, the normal		If using domain objects to represent IDN variants, the normal
	behavior during restoration of an SRS based on an escrow deposit is		behavior during restoration of an SRS based on an escrow deposit is
	to restore the IDN variants as a mirrored variant. If the		to restore the IDN variants as a mirrored variant. If the
	registration data of the IDN variant is different from the original		registration data of the IDN variant is different from the original
	name, the details of this specific implementation MUST be described		name, the details of this specific implementation MUST be described
	in the IDN policy document.		in the IDN policy document.
	An NNDN or a domain name are explicit representations of an IDN		An NNDN or a domain name are explicit representations of an IDN
	variant while an IDN variant computed based on an algorithm is an		variant while an IDN variant that is computed based on an algorithm
	implicit representation. Explicit representation of an IDN variant		is an implicit representation. Explicit representation of an IDN
	takes precedence over an implicit representation.		variant takes precedence over an implicit representation.
	7. Profile		7. Profile
	Different business models of registries exist, therefore the registry		Different business models of registries exist, therefore the registry
	is responsible for defining a profile that matches its particular		is responsible for defining a profile that matches its particular
	business model. The profile mechanism allows a registry to extend		business model. The profile mechanism allows a registry to extend
	this specification.		this specification.
	A profile is the process of:		A profile is the process of the following:
	1. Extending base objects with the mechanisms defined for XML and		1. Extending base objects with the mechanisms defined for XML and
	CSV models.		CSV models.
	* In the case of the XML model, abstract elements could be use		* In the case of the XML model, abstract elements could be used
	to extend the following objects: <domain>, <host>, <contact>,		to extend the following objects: <domain>, <host>, <contact>,
	<NNDN> and <registrar> using XML schema substitution groups		<NNDN>, and <registrar> using the XML schema substitution
	feature.		groups feature.
	2. Defining a <policy> object to specify which OPTIONAL elements of		2. Defining a <policy> object to specify which OPTIONAL elements of
	this base specification is required based on the business model		this base specification are required based on the business model
	of the registry. An example is the <registrant> element that is		of the registry. An example is the <registrant> element that is
	usually REQUIRED but it is specified as OPTIONAL in this		usually REQUIRED, but it is specified as OPTIONAL in this
	specification to support some existing business models.		specification to support some existing business models.
	3. Adding new escrowed objects using the <rde:contents> and		3. Adding new escrowed objects using the <rde:contents> and
	<rde:deletes> elements.		<rde:deletes> elements.
	4. Providing the XML schemas to third parties that require them to		4. Providing the XML schemas to third parties that require them to
	validate the escrow deposits.		validate the escrow deposits.
	8. Data escrow agent extended verification process		8. Data Escrow Agent Extended Verification Process
	A Data Escrow Agent SHOULD perform an extended verification process		A data escrow agent SHOULD perform an extended verification process
	that starts by creating a dataset to be tested by following section		that starts by creating a dataset to be tested by following
	5.2 in [I-D.ietf-regext-data-escrow].		Section 5.2 of [RFC8909].
	The following are the minimum suggested tests on the dataset:		The following are the minimum suggested tests on the dataset:
	o Validate the escrow deposits using the definition agreed with the		* Validate the escrow deposits using the definition agreed with the
	registry.		registry.
	* In the case of the XML model, the contents of the escrow		- In the case of the XML model, the contents of the escrow
	deposits MUST be validated using the XML schemas of the		deposits MUST be validated using the XML schemas of the
	profile.		profile.
	o Count the objects and validate that the number of objects is equal		* Count the objects and validate that the number of objects is equal
	to the number objects reported in the <header> element of the		to the number objects reported in the <header> element of the
	escrow deposit of that point in time (watermark).		escrow deposit of that point in time (Timeline Watermark).
	o All contact objects linked to domain names MUST be present.		* All contact objects linked to domain names MUST be present.
	o All registrars objects linked to other objects MUST be present.		* All registrar objects linked to other objects MUST be present.
	o No domain name exists as both a domain name and an NNDN.		* No domain name exists as both a domain name and an NNDN.
	o The elements listed as required in the <policy> element MUST be		* The elements listed as required in the <policy> element MUST be
	present.		present.
	o All idnTableRef definitions linked from other objects MUST be		* All idnTableRef definitions linked from other objects MUST be
	present.		present.
	o If an EPP Parameters Object was escrowed in the past, one and only		* If an EPP parameters object was escrowed in the past, one and only
	one EPP Parameters Object MUST be present.		one EPP parameters object MUST be present.
	o The watermark is not in the future.		* The Timeline Watermark is not in the future.
	9. Formal Syntax		9. Formal Syntax
	This standard is specified in XML Schema notation. The formal syntax		This standard is specified in XML Schema notation. The formal syntax
	presented here is a complete schema representation suitable for		presented here is a complete schema representation suitable for
	automated validation.		automated validation.
	The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema;		The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema;
	they are used to note the beginning and ending of the schema for URI		they are used to note the beginning and ending of the schema for URI
	registration purposes.		registration purposes.
	skipping to change at page 88, line 25 ¶		skipping to change at line 3872 ¶
	<element name="files"		<element name="files"
	type="rdeCsv:filesType" />		type="rdeCsv:filesType" />
	</sequence>		</sequence>
	<attribute name="name"		<attribute name="name"
	type="token"		type="token"
	use="required" />		use="required" />
	<attribute name="sep"		<attribute name="sep"
	type="rdeCsv:sepType"		type="rdeCsv:sepType"
	default="," />		default="," />
	</complexType>		</complexType>
	<!-- field seperator must be a single character -->		<!-- field separator must be a single character -->
	<simpleType name="sepType">		<simpleType name="sepType">
	<restriction base="string">		<restriction base="string">
	<minLength value="1" />		<minLength value="1" />
	<maxLength value="1" />		<maxLength value="1" />
	</restriction>		</restriction>
	</simpleType>		</simpleType>
	<!-- Abstract field type -->		<!-- Abstract field type -->
	<element name="field"		<element name="field"
	type="rdeCsv:fieldType"		type="rdeCsv:fieldType"
	abstract="true" />		abstract="true" />
	skipping to change at page 89, line 21 ¶		skipping to change at line 3915 ¶
	<attribute name="isRequired"		<attribute name="isRequired"
	type="boolean"		type="boolean"
	default="true" />		default="true" />
	<attribute name="parent"		<attribute name="parent"
	type="boolean"		type="boolean"
	default="false" />		default="false" />
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<!-- Concrete field types -->		<!-- Concrete field types -->
	<!-- UTF-8 Name field (e.g. domain name) -->		<!-- UTF-8 Name field (e.g., domain name) -->
	<element name="fUName"		<element name="fUName"
	type="rdeCsv:fNameType"		type="rdeCsv:fNameType"
	substitutionGroup="rdeCsv:field" />		substitutionGroup="rdeCsv:field" />
	<complexType name="fNameType">		<complexType name="fNameType">
	<complexContent>		<complexContent>
	<extension base="rdeCsv:fieldOptionalType">		<extension base="rdeCsv:fieldOptionalType">
	<sequence />		<sequence />
	<attribute name="type"		<attribute name="type"
	type="token"		type="token"
	default="eppcom\:labelType" />		default="eppcom\:labelType" />
	skipping to change at page 97, line 4 ¶		skipping to change at line 4283 ¶
	type="rdeCsv:anyURIType"		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">
	<sequence />		<sequence />
	<attribute name="type"		<attribute name="type"
	type="token"		type="token"
	default="anyURI" />		default="anyURI" />
	</extension>		</extension>
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<!--		<!--
	End of schema.		End of schema.
	-->		-->
	</schema>		</schema>
	<CODE ENDS>		<CODE ENDS>
	9.2. RDE Domain Object		9.2. RDE Domain Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:rdeDomain-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:rdeDomain-1.0"
	xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"		xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeIDN="urn:ietf:params:xml:ns:rdeIDN-1.0"		xmlns:rdeIDN="urn:ietf:params:xml:ns:rdeIDN-1.0"
	xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"		xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
	xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"		xmlns:secDNS="urn:ietf:params:xml:ns:secDNS-1.1"
	xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"		xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"		xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"		xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"
	xmlns="http://www.w3.org/2001/XMLSchema"		xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">		elementFormDefault="qualified">
	<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />		<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
	<import namespace="urn:ietf:params:xml:ns:domain-1.0" />		<import namespace="urn:ietf:params:xml:ns:domain-1.0" />
	<import namespace="urn:ietf:params:xml:ns:secDNS-1.1" />		<import namespace="urn:ietf:params:xml:ns:secDNS-1.1" />
	<import namespace="urn:ietf:params:xml:ns:rgp-1.0" />		<import namespace="urn:ietf:params:xml:ns:rgp-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rde-1.0" />		<import namespace="urn:ietf:params:xml:ns:rde-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rdeIDN-1.0" />		<import namespace="urn:ietf:params:xml:ns:rdeIDN-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />		<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />
	<annotation>		<annotation>
	<documentation>		<documentation>
	Registry Data Escrow Domain provisioning schema		Registry Data Escrow Domain provisioning schema
	</documentation>		</documentation>
	</annotation>		</annotation>
	<element name="abstractDomain"		<element name="abstractDomain"
	type="rdeDomain:abstractContentType"		type="rdeDomain:abstractContentType"
	substitutionGroup="rde:content"		substitutionGroup="rde:content"
	abstract="true" />		abstract="true" />
	<element name="domain"		<element name="domain"
	substitutionGroup="rdeDomain:abstractDomain" />		substitutionGroup="rdeDomain:abstractDomain" />
	<element name="delete"		<element name="delete"
	type="rdeDomain:deleteType"		type="rdeDomain:deleteType"
	substitutionGroup="rde:delete" />		substitutionGroup="rde:delete" />
	<!-- Content Type -->		<!-- Content Type -->
	<complexType name="abstractContentType">		<complexType name="abstractContentType">
	<complexContent>		<complexContent>
	<extension base="rde:contentType">		<extension base="rde:contentType">
	<sequence>		<sequence>
	<element name="name"		<element name="name"
	type="eppcom:labelType" />		type="eppcom:labelType" />
	<element name="roid"		<element name="roid"
	type="eppcom:roidType" />		type="eppcom:roidType" />
	<element name="uName"		<element name="uName"
	type="eppcom:labelType"		type="eppcom:labelType"
	minOccurs="0" />		minOccurs="0" />
	<element name="idnTableId"		<element name="idnTableId"
	type="rdeIDN:idType"		type="rdeIDN:idType"
	minOccurs="0" />		minOccurs="0" />
	<element name="originalName"		<element name="originalName"
	type="eppcom:labelType"		type="eppcom:labelType"
	minOccurs="0" />		minOccurs="0" />
	<element name="status"		<element name="status"
	type="domain:statusType"		type="domain:statusType"
	maxOccurs="11" />		maxOccurs="11" />
	<element name="rgpStatus"		<element name="rgpStatus"
	type="rgp:statusType"		type="rgp:statusType"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded" />		maxOccurs="unbounded" />
	<element name="registrant"		<element name="registrant"
	type="eppcom:clIDType"		type="eppcom:clIDType"
	minOccurs="0" />		minOccurs="0" />
	<element name="contact"		<element name="contact"
	type="domain:contactType"		type="domain:contactType"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded" />		maxOccurs="unbounded" />
	<element name="ns"		<element name="ns"
	type="domain:nsType"		type="domain:nsType"
	minOccurs="0" />		minOccurs="0" />
	<element name="clID"		<element name="clID"
	type="eppcom:clIDType" />		type="eppcom:clIDType" />
	<element name="crRr"		<element name="crRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
	<element name="crDate"		<element name="crDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	<element name="exDate"		<element name="exDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	<element name="upRr"		<element name="upRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
	<element name="upDate"		<element name="upDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
			<element name="secDNS"
	<element name="secDNS"		type="secDNS:dsOrKeyType"
	type="secDNS:dsOrKeyType"		minOccurs="0" />
	minOccurs="0" />		<element name="trDate"
	<element name="trDate"		type="dateTime"
	type="dateTime"		minOccurs="0" />
	minOccurs="0" />		<element name="trnData"
	<element name="trnData"		type="rdeDomain:transferDataType"
	type="rdeDomain:transferDataType"		minOccurs="0" />
	minOccurs="0" />		</sequence>
	</sequence>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>		<complexType name="transferDataType">
	<complexType name="transferDataType">		<sequence>
	<sequence>		<element name="trStatus"
	<element name="trStatus"		type="eppcom:trStatusType" />
	type="eppcom:trStatusType" />		<element name="reRr"
	<element name="reRr"		type="rdeDnrdCommon:rrType" />
	type="rdeDnrdCommon:rrType" />		<element name="reDate"
	<element name="reDate"		type="dateTime" />
	type="dateTime" />		<element name="acRr"
	<element name="acRr"		type="rdeDnrdCommon:rrType" />
	type="rdeDnrdCommon:rrType" />		<element name="acDate"
	<element name="acDate"		type="dateTime" />
	type="dateTime" />		<element name="exDate"
	<element name="exDate"		type="dateTime"
	type="dateTime"		minOccurs="0" />
	minOccurs="0" />		</sequence>
	</sequence>		</complexType>
	</complexType>		<!-- Delete Type -->
	<!-- Delete Type -->		<complexType name="deleteType">
	<complexType name="deleteType">		<complexContent>
	<complexContent>		<extension base="rde:deleteType">
	<extension base="rde:deleteType">		<sequence>
	<sequence>		<element name="name"
	<element name="name"		type="eppcom:labelType"
	type="eppcom:labelType"		minOccurs="0"
	minOccurs="0"		maxOccurs="unbounded" />
	maxOccurs="unbounded" />		</sequence>
	</sequence>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>		</schema>
	</schema>		<CODE ENDS>
	<CODE ENDS>
	9.3. CSV Domain Object		9.3. CSV Domain Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:csvDomain-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:csvDomain-1.0"
	xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"		xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"		xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"
	xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"		xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
	skipping to change at page 103, line 36 ¶		skipping to change at line 4601 ¶
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<!--		<!--
	End of schema.		End of schema.
	-->		-->
	</schema>		</schema>
	<CODE ENDS>		<CODE ENDS>
	9.4. RDE Host Object		9.4. RDE Host Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:rdeHost-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:rdeHost-1.0"
	xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"		xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:host="urn:ietf:params:xml:ns:host-1.0"		xmlns:host="urn:ietf:params:xml:ns:host-1.0"
	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"		xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"		xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"
	xmlns="http://www.w3.org/2001/XMLSchema"		xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">		elementFormDefault="qualified">
	<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />		<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
	<import namespace="urn:ietf:params:xml:ns:host-1.0" />		<import namespace="urn:ietf:params:xml:ns:host-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rde-1.0" />		<import namespace="urn:ietf:params:xml:ns:rde-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />		<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />
	<annotation>		<annotation>
	<documentation>		<documentation>
	Registry Data Escrow Host provisioning schema		Registry Data Escrow Host provisioning schema
	</documentation>		</documentation>
	</annotation>		</annotation>
	<element name="abstractHost"		<element name="abstractHost"
	type="rdeHost:abstractContentType"		type="rdeHost:abstractContentType"
	substitutionGroup="rde:content"		substitutionGroup="rde:content"
	abstract="true" />		abstract="true" />
	<element name="host"		<element name="host"
	substitutionGroup="rdeHost:abstractHost" />		substitutionGroup="rdeHost:abstractHost" />
	<element name="delete"		<element name="delete"
	type="rdeHost:deleteType"		type="rdeHost:deleteType"
	substitutionGroup="rde:delete" />		substitutionGroup="rde:delete" />
	<!-- Content Type -->		<!-- Content Type -->
	<complexType name="abstractContentType">		<complexType name="abstractContentType">
	<complexContent>		<complexContent>
	<extension base="rde:contentType">		<extension base="rde:contentType">
	<sequence>		<sequence>
	<element name="name"		<element name="name"
	type="eppcom:labelType" />		type="eppcom:labelType" />
	<element name="roid"		<element name="roid"
	type="eppcom:roidType" />		type="eppcom:roidType" />
	<element name="status"		<element name="status"
	type="host:statusType"		type="host:statusType"
	maxOccurs="7" />		maxOccurs="7" />
	<element name="addr"		<element name="addr"
	type="host:addrType"		type="host:addrType"
	minOccurs="0"		minOccurs="0"
	maxOccurs="unbounded" />		maxOccurs="unbounded" />
	<element name="clID"		<element name="clID"
	type="eppcom:clIDType" />		type="eppcom:clIDType" />
	<element name="crRr"		<element name="crRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
	<element name="crDate"		<element name="crDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	<element name="upRr"		<element name="upRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
	<element name="upDate"		<element name="upDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	<element name="trDate"		<element name="trDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	</sequence>		</sequence>
	</extension>		</extension>
	</complexContent>		</complexContent>
			</complexType>
	</complexType>		<!-- Delete Type -->
	<!-- Delete Type -->		<complexType name="deleteType">
	<complexType name="deleteType">		<complexContent>
	<complexContent>		<extension base="rde:deleteType">
	<extension base="rde:deleteType">		<choice minOccurs="0"
	<choice minOccurs="0"		maxOccurs="unbounded">
	maxOccurs="unbounded">		<element name="name"
	<element name="name"		type="eppcom:labelType" />
	type="eppcom:labelType" />		<element name="roid"
	<element name="roid"		type="eppcom:roidType" />
	type="eppcom:roidType" />		</choice>
	</choice>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>		</schema>
	</schema>		<CODE ENDS>
	<CODE ENDS>
	9.5. CSV Host Object		9.5. CSV Host Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:csvHost-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:csvHost-1.0"
	xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"		xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"		xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"
	xmlns:host="urn:ietf:params:xml:ns:host-1.0"		xmlns:host="urn:ietf:params:xml:ns:host-1.0"
	skipping to change at page 107, line 38 ¶		skipping to change at line 4794 ¶
	</complexContent>		</complexContent>
	</complexType>		</complexType>
	<!--		<!--
	End of schema.		End of schema.
	-->		-->
	</schema>		</schema>
	<CODE ENDS>		<CODE ENDS>
	9.6. RDE Contact Object		9.6. RDE Contact Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:rdeContact-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:rdeContact-1.0"
	xmlns:rdeContact="urn:ietf:params:xml:ns:rdeContact-1.0"		xmlns:rdeContact="urn:ietf:params:xml:ns:rdeContact-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"		xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"		xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"		xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"
	xmlns="http://www.w3.org/2001/XMLSchema"		xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">		elementFormDefault="qualified">
	<!-- Import common element types. -->		<!-- Import common element types. -->
	<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />		<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
	<import namespace="urn:ietf:params:xml:ns:contact-1.0" />		<import namespace="urn:ietf:params:xml:ns:contact-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rde-1.0" />		<import namespace="urn:ietf:params:xml:ns:rde-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />		<import namespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0" />
	<annotation>		<annotation>
	<documentation>		<documentation>
	Registry Data Escrow contact provisioning schema		Registry Data Escrow contact provisioning schema
	</documentation>		</documentation>
	</annotation>		</annotation>
	<element name="abstractContact"		<element name="abstractContact"
	type="rdeContact:abstractContentType"		type="rdeContact:abstractContentType"
	substitutionGroup="rde:content"		substitutionGroup="rde:content"
	abstract="true" />		abstract="true" />
	<element name="contact"		<element name="contact"
	substitutionGroup="rdeContact:abstractContact" />		substitutionGroup="rdeContact:abstractContact" />
	<element name="delete"		<element name="delete"
	type="rdeContact:deleteType"		type="rdeContact:deleteType"
	substitutionGroup="rde:delete" />		substitutionGroup="rde:delete" />
	<!-- Contact Type -->		<!-- Contact Type -->
	<complexType name="abstractContentType">		<complexType name="abstractContentType">
	<complexContent>		<complexContent>
	<extension base="rde:contentType">		<extension base="rde:contentType">
	<sequence>		<sequence>
	<element name="id"		<element name="id"
	type="eppcom:clIDType" />		type="eppcom:clIDType" />
	<element name="roid"		<element name="roid"
	type="eppcom:roidType" />		type="eppcom:roidType" />
	<element name="status"		<element name="status"
	type="contact:statusType"		type="contact:statusType"
	maxOccurs="7" />		maxOccurs="7" />
	<element name="postalInfo"		<element name="postalInfo"
	type="contact:postalInfoType"		type="contact:postalInfoType"
	maxOccurs="2" />		maxOccurs="2" />
	<element name="voice"		<element name="voice"
	type="contact:e164Type"		type="contact:e164Type"
	minOccurs="0" />		minOccurs="0" />
	<element name="fax"		<element name="fax"
	type="contact:e164Type"		type="contact:e164Type"
	minOccurs="0" />		minOccurs="0" />
	<element name="email"		<element name="email"
	type="eppcom:minTokenType" />		type="eppcom:minTokenType" />
	<element name="clID"		<element name="clID"
	type="eppcom:clIDType" />		type="eppcom:clIDType" />
	<element name="crRr"		<element name="crRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
	<element name="crDate"		<element name="crDate"
	type="dateTime"		type="dateTime"
	minOccurs="0" />		minOccurs="0" />
	<element name="upRr"		<element name="upRr"
	type="rdeDnrdCommon:rrType"		type="rdeDnrdCommon:rrType"
	minOccurs="0" />		minOccurs="0" />
			<element name="upDate"
	<element name="upDate"		type="dateTime"
	type="dateTime"		minOccurs="0" />
	minOccurs="0" />		<element name="trDate"
	<element name="trDate"		type="dateTime"
	type="dateTime"		minOccurs="0" />
	minOccurs="0" />		<element name="trnData"
	<element name="trnData"		type="rdeContact:transferDataType"
	type="rdeContact:transferDataType"		minOccurs="0" />
	minOccurs="0" />		<element name="disclose"
	<element name="disclose"		type="contact:discloseType"
	type="contact:discloseType"		minOccurs="0" />
	minOccurs="0" />		</sequence>
	</sequence>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>		<complexType name="transferDataType">
	<complexType name="transferDataType">		<sequence>
	<sequence>		<element name="trStatus"
	<element name="trStatus"		type="eppcom:trStatusType" />
	type="eppcom:trStatusType" />		<element name="reRr"
	<element name="reRr"		type="rdeDnrdCommon:rrType" />
	type="rdeDnrdCommon:rrType" />		<element name="reDate"
	<element name="reDate"		type="dateTime" />
	type="dateTime" />		<element name="acRr"
	<element name="acRr"		type="rdeDnrdCommon:rrType" />
	type="rdeDnrdCommon:rrType" />		<element name="acDate"
	<element name="acDate"		type="dateTime" />
	type="dateTime" />		</sequence>
	</sequence>		</complexType>
	</complexType>		<!-- Delete Type -->
	<!-- Delete Type -->		<complexType name="deleteType">
	<complexType name="deleteType">		<complexContent>
	<complexContent>		<extension base="rde:deleteType">
	<extension base="rde:deleteType">		<sequence>
	<sequence>		<element name="id"
	<element name="id"		type="eppcom:clIDType"
	type="eppcom:clIDType"		minOccurs="0"
	minOccurs="0"		maxOccurs="unbounded" />
	maxOccurs="unbounded" />		</sequence>
	</sequence>		</extension>
	</extension>		</complexContent>
	</complexContent>		</complexType>
	</complexType>		</schema>
	</schema>		<CODE ENDS>
	<CODE ENDS>
	9.7. CSV Contact Object		9.7. CSV Contact Object
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:csvContact-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:csvContact-1.0"
	xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"		xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"		xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"
	xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"		xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
	skipping to change at page 120, line 15 ¶		skipping to change at line 5394 ¶
	<!--		<!--
	Import common element types.		Import common element types.
	-->		-->
	<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />		<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
	<import namespace="urn:ietf:params:xml:ns:domain-1.0" />		<import namespace="urn:ietf:params:xml:ns:domain-1.0" />
	<import namespace="urn:ietf:params:xml:ns:contact-1.0" />		<import namespace="urn:ietf:params:xml:ns:contact-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rde-1.0" />		<import namespace="urn:ietf:params:xml:ns:rde-1.0" />
	<import namespace="urn:ietf:params:xml:ns:rdeCsv-1.0" />		<import namespace="urn:ietf:params:xml:ns:rdeCsv-1.0" />
	<annotation>		<annotation>
	<documentation>		<documentation>
	Registar Comma-Separated Values (CSV) Object		Registrar Comma-Separated Values (CSV) Object
	</documentation>		</documentation>
	</annotation>		</annotation>
	<!--		<!--
	Child elements of the <rde:contents> object		Child elements of the <rde:contents> object
	-->		-->
	<element name="contents"		<element name="contents"
	type="csvRegistrar:contentType"		type="csvRegistrar:contentType"
	substitutionGroup="rde:content" />		substitutionGroup="rde:content" />
	<complexType name="contentType">		<complexType name="contentType">
	<complexContent>		<complexContent>
	skipping to change at page 132, line 7 ¶		skipping to change at line 5937 ¶
	<attribute name="registrarId"		<attribute name="registrarId"
	type="positiveInteger" />		type="positiveInteger" />
	</extension>		</extension>
	</simpleContent>		</simpleContent>
	</complexType>		</complexType>
	</schema>		</schema>
	<CODE ENDS>		<CODE ENDS>
	9.17. DNRD Common Objects		9.17. DNRD Common Objects
	<CODE BEGINS>		<CODE BEGINS>
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<schema targetNamespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"		<schema targetNamespace="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"
	xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"		xmlns:rdeDnrdCommon="urn:ietf:params:xml:ns:rdeDnrdCommon-1.0"
	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"		xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns="http://www.w3.org/2001/XMLSchema"		xmlns="http://www.w3.org/2001/XMLSchema"
	elementFormDefault="qualified">		elementFormDefault="qualified">
	<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />		<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
	<annotation>		<annotation>
	<documentation>		<documentation>
	Data Escrow Deposit Common Objects schema		Data Escrow Deposit Common Objects schema
	</documentation>		</documentation>
	</annotation>		</annotation>
	<complexType name="rrType">		<complexType name="rrType">
	<simpleContent>		<simpleContent>
	<extension base="eppcom:clIDType">		<extension base="eppcom:clIDType">
	<attribute name="client"		<attribute name="client"
	type="eppcom:clIDType" />		type="eppcom:clIDType" />
	</extension>		</extension>
	</simpleContent>		</simpleContent>
	</complexType>		</complexType>
	</schema>		</schema>
	<CODE ENDS>		<CODE ENDS>
	10. Internationalization Considerations		10. Internationalization Considerations
	Data Escrow deposits are represented in XML, which provides native		Data escrow deposits are represented in XML, which provides native
	support for encoding information using the Unicode character set and		support for encoding information using the Unicode character set and
	its more compact representations including UTF-8. Conformant XML		its more compact representations including UTF-8. Conformant XML
	processors recognize both UTF-8 and UTF-16. Though XML includes		processors recognize both UTF-8 and UTF-16. Though XML includes
	provisions to identify and use other character encodings through use		provisions to identify and use other character encodings through use
	of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is		of an "encoding" attribute in an <?xml?> declaration, the use of
	RECOMMENDED.		UTF-8 is RECOMMENDED.
	11. IANA Considerations		11. IANA Considerations
	This document uses URNs to describe XML namespaces and XML schemas		This document uses URNs to describe XML namespaces and XML schemas
	conforming to a registry mechanism described in [RFC3688]. The		conforming to a registry mechanism described in [RFC3688]. The
	following URI assignments is requested of IANA.		following URIs have been assigned by IANA.
	Registration request for the RDE CSV namespace:
	URI: urn:ietf:params:xml:ns:rdeCsv-1.0
	Registrant Contact: IESG <regext@ietf.org>
	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 <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 domain XML schema:
	URI: urn:ietf:params:xml:schema:rdeDomain-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 domain XML schema:
	URI: urn:ietf:params:xml:schema:csvDomain-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 host XML schema:
	URI: urn:ietf:params:xml:schema:rdeHost-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 contact XML schema:
	URI: urn:ietf:params:xml:schema:rdeContact-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 registrar XML schema:
	URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 registrar XML schema:
	URI: urn:ietf:params:xml:schema:csvRegistrar-1.0
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC
	after IANA records it.
	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 <regext@ietf.org>
	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 IDN XML schema:
	URI: urn:ietf:params:xml:schema:rdeIDN-1.0		RDE CSV namespace:
	Registrant Contact: IESG <regext@ietf.org>		URI: urn:ietf:params:xml:ns:rdeCsv-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Note to RFC Editor: Please remove the email address from the RFC		RDE CSV XML schema:
	after IANA records it.
	See Section 9.10 of this document.		URI: urn:ietf:params:xml:schema:rdeCsv-1.0
			Registrant Contact: IESG
	Registration request for the CSV IDN namespace:		See Section 9.1 of this document.
	URI: urn:ietf:params:xml:ns:csvIDN-1.0		RDE domain namespace:
	Registrant Contact: IESG <regext@ietf.org>		URI: urn:ietf:params:xml:ns:rdeDomain-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Note to RFC Editor: Please remove the email address from the RFC		RDE domain XML schema:
	after IANA records it.
	XML: None. Namespace URIs do not represent an XML specification.		URI: urn:ietf:params:xml:schema:rdeDomain-1.0
			Registrant Contact: IESG
	Registration request for the CSV IDN XML schema:		See Section 9.2 of this document.
	URI: urn:ietf:params:xml:schema:csvIDN-1.0		CSV domain namespace:
	Registrant Contact: IESG <regext@ietf.org>		URI: urn:ietf:params:xml:ns:csvDomain-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Note to RFC Editor: Please remove the email address from the RFC		CSV domain XML schema:
	after IANA records it.
	See Section 9.11 of this document.		URI: urn:ietf:params:xml:schema:csvDomain-1.0
			Registrant Contact: IESG
	Registration request for the RDE EPP parameters namespace:		See Section 9.3 of this document.
	URI: urn:ietf:params:xml:ns:rdeEppParams-1.0		RDE host namespace:
	Registrant Contact: IESG <regext@ietf.org>		URI: urn:ietf:params:xml:ns:rdeHost-1.0
	Note to RFC Editor: Please remove the email address from the RFC		Registrant Contact: IESG
	after IANA records it.		XML: None. Namespace URIs do not represent an XML specification.
	XML: None. Namespace URIs do not represent an XML specification.		RDE host XML schema:
	Registration request for the RDE EPP parameters XML schema:		URI: urn:ietf:params:xml:schema:rdeHost-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:schema:rdeEppParams-1.0		See Section 9.4 of this document.
	Registrant Contact: IESG <regext@ietf.org>		CSV host namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:csvHost-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	See Section 9.12 of this document.		CSV host XML schema:
	Registration request for the RDE NNDN namespace:		URI: urn:ietf:params:xml:schema:csvHost-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:rdeNNDN-1.0		See Section 9.5 of this document.
	Registrant Contact: IESG <regext@ietf.org>		RDE contact namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:rdeContact-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	XML: None. Namespace URIs do not represent an XML specification.		RDE contact XML schema:
	Registration request for the RDE NNDN XML schema:		URI: urn:ietf:params:xml:schema:rdeContact-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:schema:rdeNNDN-1.0		See Section 9.6 of this document.
	Registrant Contact: IESG <regext@ietf.org>		CSV contact namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:csvContact-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	See Section 9.13 of this document.		CSV contact XML schema:
	Registration request for the CSV NNDN namespace:		URI: urn:ietf:params:xml:schema:csvContact-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:csvNNDN-1.0		See Section 9.7 of this document.
	Registrant Contact: IESG <regext@ietf.org>		RDE registrar namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:rdeRegistrar-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	XML: None. Namespace URIs do not represent an XML specification.		RDE registrar XML schema:
	Registration request for the CSV NNDN XML schema:		URI: urn:ietf:params:xml:schema:rdeRegistrar-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:schema:csvNNDN-1.0		See Section 9.8 of this document.
	Registrant Contact: IESG <regext@ietf.org>		CSV registrar namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:csvRegistrar-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	See Section 9.14 of this document.		CSV registrar XML schema:
	Registration request for the RDE Policy namespace:		URI: urn:ietf:params:xml:schema:csvRegistrar-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:rdePolicy-1.0		See Section 9.9 of this document.
	Registrant Contact: IESG <regext@ietf.org>		RDE IDN namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:rdeIDN-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	XML: None. Namespace URIs do not represent an XML specification.		RDE IDN XML schema:
	Registration request for the RDE Policy XML schema:		URI: urn:ietf:params:xml:schema:rdeIDN-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:rdePolicy-1.0		See Section 9.10 of this document.
	Registrant Contact: IESG <regext@ietf.org>		CSV IDN namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:csvIDN-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	See Section 9.15 of this document.		CSV IDN XML schema:
	Registration request for the RDE Header namespace:		URI: urn:ietf:params:xml:schema:csvIDN-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:rdeHeader-1.0		See Section 9.11 of this document.
	Registrant Contact: IESG <regext@ietf.org>		RDE EPP parameters namespace:
	Note to RFC Editor: Please remove the email address from the RFC		URI: urn:ietf:params:xml:ns:rdeEppParams-1.0
	after IANA records it.		Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	XML: None. Namespace URIs do not represent an XML specification.		RDE EPP parameters XML schema:
	Registration request for the RDE Header XML schema:		URI: urn:ietf:params:xml:schema:rdeEppParams-1.0
			Registrant Contact: IESG
	URI: urn:ietf:params:xml:ns:rdeHeader-1.0		See Section 9.12 of this document.
	Registrant Contact: IESG <regext@ietf.org>
	Note to RFC Editor: Please remove the email address from the RFC		RDE NNDN namespace:
	after IANA records it.
	See Section 9.16 of this document.		URI: urn:ietf:params:xml:ns:rdeNNDN-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Registration request for the RDE Common Objects namespace:		RDE NNDN XML schema:
	URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0		URI: urn:ietf:params:xml:schema:rdeNNDN-1.0
			Registrant Contact: IESG
	Registrant Contact: IESG <regext@ietf.org>		See Section 9.13 of this document.
	Note to RFC Editor: Please remove the email address from the RFC		CSV NNDN namespace:
	after IANA records it.
	XML: None. Namespace URIs do not represent an XML specification.		URI: urn:ietf:params:xml:ns:csvNNDN-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Registration request for the RDE Common Objects XML schema:		CSV NNDN XML schema:
	URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0		URI: urn:ietf:params:xml:schema:csvNNDN-1.0
			Registrant Contact: IESG
	Registrant Contact: IESG <regext@ietf.org>		See Section 9.14 of this document.
	Note to RFC Editor: Please remove the email address from the RFC		RDE Policy namespace:
	after IANA records it.
	See Section 9.17 of this document.		URI: urn:ietf:params:xml:ns:rdePolicy-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	12. Implementation Status		RDE Policy XML schema:
	Note to RFC Editor: Please remove this section and the reference to		URI: urn:ietf:params:xml:schema:rdePolicy-1.0
	RFC 7942 [RFC7942] before publication.		Registrant Contact: IESG
	This section records the status of known implementations of the		See Section 9.15 of this document.
	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
	intended to assist the IETF in its decision processes in progressing
	drafts to RFCs. Please note that the listing of any individual
	implementation here does not imply endorsement by the IETF.
	Furthermore, no effort has been spent to verify the information
	presented here that was supplied by IETF contributors. This is not
	intended as, and must not be construed to be, a catalog of available
	implementations or their features. Readers are advised to note that
	other implementations may exist.
	According to RFC 7942 [RFC7942], "this will allow reviewers and		RDE Header namespace:
	working groups to assign due consideration to documents that have the
	benefit of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented protocols
	more mature. It is up to the individual working groups to use this
	information as they see fit".
	12.1. Implementation in the gTLD space		URI: urn:ietf:params:xml:ns:rdeHeader-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Organization: ICANN		RDE Header XML schema:
	Name: ICANN Registry Agreement		URI: urn:ietf:params:xml:schema:rdeHeader-1.0
			Registrant Contact: IESG
	Description: the ICANN Base Registry Agreement requires Registries,		See Section 9.16 of this document.
	Data Escrow Agents, and ICANN to implement this specification. ICANN
	receives daily notifications from Data Escrow Agents confirming that
	more than 1,200 gTLDs are sending deposits that comply with this
	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.		RDE Common Objects namespace:
	Coverage: all aspects of this specification are implemented.		URI: urn:ietf:params:xml:ns:rdeDnrdCommon-1.0
			Registrant Contact: IESG
			XML: None. Namespace URIs do not represent an XML specification.
	Version compatibility: versions 03 - 09 are known to be implemented.		RDE Common Objects XML schema:
	Contact: gustavo.lozano@icann.org		URI: urn:ietf:params:xml:schema:rdeDnrdCommon-1.0
			Registrant Contact: IESG
	URL: https://www.icann.org/resources/pages/registries/registries-		See Section 9.17 of this document.
	agreements-en
	13. Security Considerations		12. Security Considerations
	This specification does not define the security mechanisms to be used		This specification does not define the security mechanisms to be used
	in the transmission of the data escrow deposits, since it only		in the transmission of the data escrow deposits, since it only
	specifies the minimum necessary to enable the rebuilding of a		specifies the minimum necessary to enable the rebuilding of a
	registry from deposits without intervention from the original		registry from deposits without intervention from the original
	registry.		registry.
	Depending on local policies, some elements, or, most likely, the		Depending on local policies, some elements, or, most likely, the
	whole deposit will be considered confidential. As such, the parties		whole deposit will be considered confidential. As such, the parties
	SHOULD take all the necessary precautions such as encrypting the data		SHOULD take all the necessary precautions such as encrypting the data
	skipping to change at page 142, line 21 ¶		skipping to change at line 6228 ¶
	before submitting any data, and the data escrow agent MUST		before submitting any data, and the data escrow agent MUST
	authenticate the identity of the party receiving the data escrow		authenticate the identity of the party receiving the data escrow
	deposits for the purposes deemed appropriate.		deposits for the purposes deemed appropriate.
	Additionally, the registry and the escrow agent MUST use integrity		Additionally, the registry and the escrow agent MUST use integrity
	checking mechanisms to ensure the data transmitted is what the source		checking mechanisms to ensure the data transmitted is what the source
	intended. Validation of the contents by the parties is RECOMMENDED		intended. Validation of the contents by the parties is RECOMMENDED
	to ensure that the file was transmitted correctly from the registry		to ensure that the file was transmitted correctly from the registry
	or escrow agent and that the contents are "meaningful".		or escrow agent and that the contents are "meaningful".
	A few elements in this specification contain URLs, the use of HTTP		A few elements in this specification contain URLs; the use of HTTP
	over TLS (Transport Layer Security), [RFC2818] is RECOMMENDED on the		over TLS (Transport Layer Security) [RFC2818] is RECOMMENDED on the
	URLs.		URLs.
	The various data structures in the document include a few places that		The various data structures in the document include a few places that
	have internal redundancy, and if the values become inconsistent there		have internal redundancy, and if the values become inconsistent there
	can be harmful consequences, such as different entities using		can be harmful consequences, such as different entities using
	different fields as their reference.		different fields as their reference.
	Note: if Transport Layer Security (TLS) is used when providing an		| Note: if TLS is used when providing an escrow service, the
	escrow services, the recommendations in [BCP195] MUST be implemented.		| recommendations in [BCP195] MUST be implemented.
	14. Privacy Considerations		13. Privacy Considerations
	This specification defines a format that may be used to escrow		This specification defines a format that may be used to escrow
	personal data. The process of data escrow is governed by a legal		personal data. The process of data escrow is governed by a legal
	document agreed by the parties, and such legal document must ensure		document that is agreed to by the parties, and such a legal document
	that privacy-sensitive and/or personal data receives the required		must ensure that privacy-sensitive and/or personal data receives the
	protection.		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, 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
	1. Added definition for child elements under the <domain> element.
	2. Added definition for child elements under the <host> element.
	3. Added definition for child elements under the <contact> element.
	4. Rewrote the IDN Variants Handling section to use the variant
	states as described in ICANN's Study of Issues Related to the
	Management of IDN Variant TLDs.
	5. Renamed <icannID> to <gurid> in the <rdeRegistrar>.
	6. Renamed <dnssec> to <secDNS> in the <domain> element.
	7. Renamed <transfData> to <trnData> in the <domain> element.
	8. Added <whoisInfo> element under <rdeRegistrar> element.
	9. Fixed some typographical errors and omissions.
	16.2. Changes from 00 to 01
	1. Specify OPTIONAL elements in the draft.
	2. Added NNDN object to support list of reserved names and different
	IDN variants models.
	3. Removed subordinated host element from the domain object.
	4. Added eppParams object.
	5. Added variantGenerator element to the domain object.
	6. Added lgr to the IDN table object.
	16.3. Changes from 01 to 02
	1. Updates to the all objects based on feedback from the list.
	2. Start of XML and CSV drafts merge.
	3. Added header object.
	4. Added report object.
	5. Added notification object.
	6. Added Data Escrow Agent Extended Verification Process section.
	7. Added Notifications from Registries to Third Parties.
	8. Added Notifications from Data Escrow Agents to Third Parties.
	9. Added FULL, DIFF deposit examples using the XML model only.
	16.4. Changes from 02 to 03
	1. Remove authinfo from the XML Schema.
	2. Resend attribute is now an element
	3. Scope attribute added to policy object.
	16.5. Changes from 03 to 04
	1. Merged draft-gould-thippeswamy-dnrd-csv-mapping-03 into draft-
	arias-noguchi-dnrd-objects-mapping-02.
	2. Changed the cksum attribute of <rdeCsv:file> to use CRC32 and
	changed all of the sample cksum values to use CRC32, based on
	feedback from David Kipling.
	3. Changed the optional <rdeCsv:sep> element to be an optional
	"sep" attribute value of the <rdeCsv:csv> element with a default
	value of "," based on feedback from David Kipling.
	4. Added support for the optional "parent" attribute for the to the
	CSV fields to indicate a field as a reference to a parent
	object, based on feedback from David Kipling.
	5. Added support for the CSV model for the NNDN.
	6. Added support to delete hosts based on roid.
	7. Added mirrored state to NNDN
	8. Minor fixes to XML XSDs.
	9. The Report and Notification objects were moved to draft-lozano-
	icann-registry-interfaces
	10. The section Data escrow notifications was moved to draft-lozano-
	icann-registry-interfaces
	11. Removed references to the <rdeCsv:fCrRr>, <rdeCsv:fCrID>, and
	<rdeCsv:fCrDate> from the "hostStatuses" and "hostAddresses" CSV
	files.
	12. Removed references to the <rdeCsv:fCrRr>, <rdeCsv:fCrID>, and
	<rdeCsv:fCrDate> from the "contactStatuses" CSV file.
	13. Removed references to the <rdeCsv:fCrRr>, <rdeCsv:fCrID>, and
	<rdeCsv:fCrDate> from the "domainContacts", "domainStatuses",
	and "domainNameServers" CSV files.
	14. Changed <rdeCsv:fLanguage> to <rdeCsv:fLang>.
	15. Replaced use of <rdeCsv:fLang> to new <rdeCsv:fIdnTableId> field
	in the "domain", "idnLanguage", and "NNDN" CSV files.
	16. Replaced use of <csvHost:fName> with <rdeCsv:fRoid> in the
	"host" <csvHost:deletes> <rdeCsv:csv> element.
	17. Changed the foreign key of the hosts to use <rdeCsv:fRoid>
	instead of <csvHost:fName> and removed use of <csvHost:fName> in
	the "domainNameServers", "hostStatuses", and "hostAddresses" CSV
	files.
	18. Added use of the MUST keyword for CSV fields that are required
	to be supported in an EPP based system.
	19. Removed use of the <rdeCsv:fRoid> field element for the
	"registrar" CSV file.
	20. Added definition of <csvNNDN:fMirroringNS> field element.
	16.6. Changes from 04 to 05
	1. Updated the examples of the full and differential deposits using
	the CSV and XML model.
	2. Made <rdeCsv:fExDate> optional for the "domainTransfer" CSV file
	to match the XML definition.
	3. Made <csvDomain:fOriginalName> optional for the "domain" CSV file
	to match the XML definition.
	4. Made <rdeCsv:fTrDate> optional for the "domain" and "contact" CSV
	files to match the XML definition.
	5. Change <idnTableId> from IDREF to idType.
	6. Minor editorial changes.
	16.7. Changes from 05 to 06
	1. Revised the differential and incremental deposits for the CSV
	format to use cascade update / replace and delete from the parent
	object to be consistent with the XML format.
	2. Revised the structure of the CSV format sections to utilize sub-
	sections instead of a list for the CSV file definitions.
	3. Added the "CSV Parent Child Relationship" section to describe the
	concept of parent child relationships across CSV file
	definitions.
	4. Added the "domainNameServersAddresses" CSV File Definition
	section to support the domain host attributes model of [RFC5731].
	5. Made the required fields in the CSV format consistent with the
	XML format. The CSV fields updated to be required include:
	<rdeCsv:fCrDate>, <csvDomain:fContactType>, <csvDomain:fStatus>,
	<csvDomain:fKeyTag>, <csvDomain:fDsAlg>, <csvDomain:fDigestType>,
	<csvDomain:fDigest>, <csvDomain:fFlags>, <csvDomain:fProtocol>,
	<csvDomain:fKeyAlg>, <csvDomain:fPubKey>, <rdeCsv:fTrStatus>,
	<rdeCsv:fReRr>, <rdeCsv:fReDate<, <rdeCsv:fAcRr>,
	<rdeCsv:fAcDate>, <csvHost:fStatus>, <csvContact:fCc>,
	<csvContact:fStatus>, <csvContact:fPostalType>,
	<csvRegistrar:fStatus>, and <csvNNDN:fNameState>.
	6. Revised the CSV examples to use a more realistic set of records.
	16.8. Changes from 06 to 07
	1. Created "repositoryTypeGroup" group element in the rdeHeader
	including the <rdeHeader:registrar>, <rdeHeader:ppsp> and
	<rdeHeader:tld> elements.
	2. Added the optional "rcdn" and "registrarId" attributes to the
	<rdeHeader:count> element
	16.9. Changes from 07 to 08
	1. The following registrar elements were made optional to support
	greater flexibility for the implementation of policies: status,
	postalInfo, email and crDate.
	2. The following domain name elements were made optional to support
	greater flexibility for the implementation of policies: crRr.
	16.10. Changes from 08 to 09
	1. Implementation Status section was added
	16.11. Changes from 09 to 10
	1. Editorial changes in section Section 5.1.2.1.6.
	2. Added MAY clause when the DS Data Interface is used in section
	Section 5.1.2.1.6.
	16.12. Changes from 10 to REGEXT 00
	1. Internet Draft (I-D) adopted by the REGEXT WG.
	16.13. Changes REGEXT 00 to REGEXT 01
	1. Added the <rdeHeader:reseller> element to the
	"repositoryTypeGroup" group element in the rdeHeader.
	2. Privacy consideration section was added
	3. Updates on section 8
	16.14. Changes REGEXT 01 to REGEXT 02
	1. Added a choice between the use of the <rdeCsv:fClID> or
	<csvRegistrar:fGurid> fields in the CSV "domain", "host", and
	"contact" definitions.
	2. Added a choice between the use of the <rdeCsv:fRoid> or
	<csvHost:fName> fields in the CSV "domainNameServers"
	definition.
	3. Changed "of client" to "of the client" throughout the document.
	4. Modified all references of 'The attribute isRequired MUST equal
	"true".' to 'The attribute "isRequired" MUST equal "true".'
	5. Combined the <csvDomain:fName> and <csvDomain:fContactType>
	fields in a single required list for the CSV "domainContacts"
	definition.
	6. Combined the <csvDomain:fName>, <csvDomain:fStatus>, and
	<csvDomain:fRgpStatus> fields in a single required list for the
	CSV "domainStatuses" definition.
	7. Moved the <rdeCsv:fCrRr> the <rdeCsv:fUpRr> fields to the MAY
	list for the CSV "domain", "host", and "contact" definitions.
	8. Made the order of the <rdeCsv:fCrRr>, <rdeCsv:crID>,
	<rdeCsv:UpRr>, and <rdeCsv:UpID> fields more consistent in the
	CSV lists.
	9. Fixed an error in the order of the <contact> object example.
	10. Changed <rdeCsv:fCrDate> to be optional to match <crDate> being
	optional in the XML model, by having it use type
	rdeCsv:fDateTimeType instead of rdeCsv:fRequiredDateTimeType and
	ensuring that <rdeCsv:fCrDate> is included in the MAY field
	lists and not the MUST field lists.
	11. Made <rdeCsv:fExDate> optional for the "domain" CSV definition
	to be consistent with the XML model, by removing the sentence
	'The attribute "isRequired" MUST equal "true".' from the
	description and moving the field to the MAY field list.
	12. Made <rdeCsv:fUpDate> optional for the "domain" and "contact"
	CSV definitions to be consistent with the XML model, by moving
	the field to the MAY field list.
	13. Made <rdeCsv:fCrRr> optional to be consistent with the XML
	model, by having it use type rdeCsv:fClIDType instead of
	rdeCsv:fClIDRequiredType.
	14. Made <rdeCsv:fReRr> required to be consistent with the XML
	model, by having it use type rdeCsv:fClIDRequiredType instead of
	rdeCsv:fClIDType.
	15. Made the <csvRegistrar:fGurid> field in the "host", "contact",
	and "registrar" CSV definitions required explicitly by removing
	'and isRequired="true"' and adding the sentence 'The attribute
	isRequired MUST equal "true".', when it is chosen as the primary
	field.
	16. Removed extra '/>.' at the end of the <csvHost:fStatus> field
	description in the "hostStatuses" CSV definition.
	17. Made the <csvRegistrar:fStatus> field optional to be consistent
	with the XML model, by having csvRegistrar:fStatusType extend
	rdeCsv:fieldOptionalType instead of rdeCsv:fRequiredType.
	18. Made the <csvContact:fEmail> field for the "registrar" CSV
	definition explicitly optional to be consistent with the XML
	model, by adding the sentence 'The attribute isRequired MUST
	equal "false".' to the field description and including the
	definition of isRequired="false" in the "registrar" CSV
	definition examples.
	19. Added the choice between the use of the <csvRegistrar:fId> and
	<csvRegistrar:fGurid> fields in the deletes "registrar" CSV
	definition to be consistent with the "registrar" CSV definition.
	20. Made the <crRr> and <crDate> elements optional for the host and
	contact objects in the XML model to be consistent with the
	domain object.
	16.15. Changes REGEXT 02 to REGEXT 03
	1. Added the optional element contentTag in the header object.
	2. Editorial updates.
	16.16. Changes REGEXT 03 to REGEXT 04
	1. Note: Updates from version REGEXT 03 to REGEXT 04 attend the
	feedback provided during the document shepherd review.
	2. Editorial updates.
	3. Examples now use domain names from the .example TLD.
	4. The introduction was enhanced by explaining the need for data
	escrow and the proposed solution.
	5. Explanation regarding NNDN was improved.
	6. Explanation regarding the CSV and XML model was improved.
	7. Section 4.5 updated to make the text clearer.
	8. draft-arias-noguchi-registry-data-escrow is now referenced from
	the I-D repository.
	9. The XML prefix "rdeDomain" is now consistently used.
	10. The prevID attribute was removed from the examples of full
	deposits.
	11. The examples were updated to use present dates.
	16.17. Changes REGEXT 04 to REGEXT 05
	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 [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
	1. Changes based on the feedback provided here:
	https://mailarchive.ietf.org/arch/msg/regext/hDLz2ym4oR-ukA4Fm-
	QJ8FzaxxE
	2. Changes based on the feedback provided here:
	https://mailarchive.ietf.org/arch/msg/regext/780Xw-
	z1RMRb79nmZ6ABmRTo1fU
	16.20. Changes REGEXT 07 to REGEXT 08
	1. Changes based on the feedback provided here:
	https://mailarchive.ietf.org/arch/msg/regext/
	UaMNvl1xh60ldjpqHHYc3TNsfhg
	2. Changes based on the feedback provided here:
	https://mailarchive.ietf.org/arch/msg/regext/
	B3QTxUCWUE4R_QharAQlA3041j0
	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
	16.23. Changes REGEXT 10 to REGEXT 11
	1. Changes based on the feedback provided here:
	https://mailarchive.ietf.org/arch/msg/regext/
	ghEr55r7CVdwUSvkvMGpol4aSh0
	17. Example of a Full Deposit using the XML model		14. Example of a Full Deposit Using the XML Model
	Example of a Full Deposit using the XML model:		The following is an 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"
	xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"		xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
	xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"		xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"
	xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"		xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
	skipping to change at page 157, line 16 ¶		skipping to change at line 6507 ¶
	</epp:retention>		</epp:retention>
	</epp:statement>		</epp:statement>
	</rdeEppParams:dcp>		</rdeEppParams:dcp>
	</rdeEppParams:eppParams>		</rdeEppParams:eppParams>
	<rdePolicy:policy		<rdePolicy:policy
	scope="//rde:deposit/rde:contents/rdeDomain:domain"		scope="//rde:deposit/rde:contents/rdeDomain:domain"
	element="rdeDomain:registrant" />		element="rdeDomain:registrant" />
	</rde:contents>		</rde:contents>
	</rde:deposit>		</rde:deposit>
	18. Example of Differential Deposit using the XML model		15. Example of a Differential Deposit Using the XML Model
	Example of a Differential Deposit using the XML model:		The following is an example of a Differential Deposit using the XML
			model:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<rde:deposit type="DIFF" id="20191017002" prevId="20191017001"		<rde:deposit type="DIFF" id="20191017002" prevId="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"
	xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"		xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
	xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"		xmlns:rdeDomain="urn:ietf:params:xml:ns:rdeDomain-1.0"
	xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"		xmlns:rdeHost="urn:ietf:params:xml:ns:rdeHost-1.0"
	skipping to change at page 158, line 46 ¶		skipping to change at line 6586 ¶
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1		uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1
	</rdeHeader:count>		</rdeHeader:count>
	<rdeHeader:count		<rdeHeader:count
	uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1		uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
	</rdeHeader:count>		</rdeHeader:count>
	</rdeHeader:header>		</rdeHeader:header>
	</rde:contents>		</rde:contents>
	</rde:deposit>		</rde:deposit>
	19. Example of a Full Deposit using the CSV model		16. Example of a Full Deposit Using the CSV Model
	Example of a Full Deposit using the CSV model:		The following is an example of a Full Deposit using the CSV model:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<rde:deposit		<rde:deposit
	xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"		xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"		xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"
	xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"		xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"
	xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"		xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"
	xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"		xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"
	xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0"		xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0"
	skipping to change at page 168, line 5 ¶		skipping to change at line 7021 ¶
	</epp:recipient>		</epp:recipient>
	<epp:retention>		<epp:retention>
	<epp:indefinite/>		<epp:indefinite/>
	</epp:retention>		</epp:retention>
	</epp:statement>		</epp:statement>
	</rdeEppParams:dcp>		</rdeEppParams:dcp>
	</rdeEppParams:eppParams>		</rdeEppParams:eppParams>
	</rde:contents>		</rde:contents>
	</rde:deposit>		</rde:deposit>
	20. Example of Differential Deposit using the CSV model		17. Example of a Differential Deposit Using the CSV Model
	Example of a Differential Deposit using the CSV model:		The following is an example of a Differential Deposit using the CSV
			model:
	<?xml version="1.0" encoding="UTF-8"?>		<?xml version="1.0" encoding="UTF-8"?>
	<rde:deposit		<rde:deposit
	xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"		xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
	xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"		xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
	xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"		xmlns:rdeCsv="urn:ietf:params:xml:ns:rdeCsv-1.0"
	xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"		xmlns:csvDomain="urn:ietf:params:xml:ns:csvDomain-1.0"
	xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"		xmlns:csvHost="urn:ietf:params:xml:ns:csvHost-1.0"
	xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"		xmlns:csvContact="urn:ietf:params:xml:ns:csvContact-1.0"
	xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0"		xmlns:csvRegistrar="urn:ietf:params:xml:ns:csvRegistrar-1.0"
	skipping to change at page 178, line 37 ¶		skipping to change at line 7535 ¶
	</epp:recipient>		</epp:recipient>
	<epp:retention>		<epp:retention>
	<epp:indefinite/>		<epp:indefinite/>
	</epp:retention>		</epp:retention>
	</epp:statement>		</epp:statement>
	</rdeEppParams:dcp>		</rdeEppParams:dcp>
	</rdeEppParams:eppParams>		</rdeEppParams:eppParams>
	</rde:contents>		</rde:contents>
	</rde:deposit>		</rde:deposit>
	21. References		18. References
	21.1. Normative References		18.1. Normative References
	[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,		[BCP195] 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, May 2015.
	2015, <https://www.rfc-editor.org/info/bcp195>.
	[I-D.ietf-regext-data-escrow]		<https://www.rfc-editor.org/info/bcp195>
	Lozano, G., "Registry Data Escrow Specification", draft-
	ietf-regext-data-escrow-10 (work in progress), June 2020.
	[ISO-3166-1]		[ISO-3166-1]
	3166, I. S., "Codes for the representation of names of		International Organization for Standardization, "Codes for
	countries and their subdivisions -- Part 1: Country		the representation of names of countries and their
	codes", ISO Standard 3166, November 2006.		subdivisions -- Part 1: Country codes", ISO Standard 3166,
			August 2020.
	[ITU-E164]		[ITU-E164] International Telecommunication Union, "The international
	International Telecommunication Union, "The international
	public telecommunication numbering plan", ITU-T		public telecommunication numbering plan", ITU-T
	Recommendation E.164, February 2005.		Recommendation E.164, February 2005.
	[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,		[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
	DOI 10.17487/RFC0791, September 1981,		DOI 10.17487/RFC0791, September 1981,
	<https://www.rfc-editor.org/info/rfc791>.		<https://www.rfc-editor.org/info/rfc791>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	skipping to change at page 180, line 34 ¶		skipping to change at line 7620 ¶
	<https://www.rfc-editor.org/info/rfc6234>.		<https://www.rfc-editor.org/info/rfc6234>.
	[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		[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,		Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
	January 2019, <https://www.rfc-editor.org/info/rfc8499>.		January 2019, <https://www.rfc-editor.org/info/rfc8499>.
			[RFC8909] Lozano, G., "Registry Data Escrow Specification",
			RFC 8909, DOI 10.17487/RFC8909, November 2020,
			<https://www.rfc-editor.org/info/rfc8909>.
	[V42] International Telecommunication Union, "V.42 : Error-		[V42] International Telecommunication Union, "V.42 : Error-
	correcting procedures for DCEs using asynchronous-to-		correcting procedures for DCEs using asynchronous-to-
	synchronous conversion", March 2002,		synchronous conversion", ITU-T Recommendation V.42, March
	<https://www.itu.int/rec/T-REC-V.42/en>.		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. M., Maler, E.,
	F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth		and F. Yergeau, "Extensible Markup Language (XML) 1.0
	Edition) REC-xml-20081126", November 2008,		(Fifth Edition) REC-xml-20081126", W3C Recommendation,
			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. S., Beech, D., Maloney, M., and N.
	"XML Schema Part 1: Structures Second Edition REC-		Mendelsohn, "XML Schema Part 1: Structures Second Edition
	xmlschema-1-20041028", October 2004,		REC-xmlschema-1-20041028", W3C Recommendation, 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. V. and A. Malhotra, "XML Schema Part 2:
	Second Edition REC-xmlschema-2-20041028", October 2004,		Datatypes Second Edition REC-xmlschema-2-20041028",
			W3C Recommendation, October 2004,
	<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.		<https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
	[W3C.REC-xpath-31-20170321]		[W3C.REC-xpath-31-20170321]
	Robie, J., Dyck, M., and J. Spiegel, "XML Path Language		Robie, J., Dyck, M., and J. Spiegel, "XML Path Language
	(XPath) 3.1", March 2017,		(XPath) 3.1", W3C Recommendation, March 2017,
	<https://www.w3.org/TR/2017/REC-xpath-31-20170321/>.		<https://www.w3.org/TR/2017/REC-xpath-31-20170321/>.
	21.2. Informative References		18.2. Informative References
	[ICANN-GTLD-AGB-20120604]		[ICANN-GTLD-AGB-20120604]
	ICANN, "gTLD Applicant Guidebook Version 2012-06-04", June		ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 4
	2012, <http://newgtlds.icann.org/en/applicants/agb/		June 2012, <http://newgtlds.icann.org/en/applicants/agb/
	guidebook-full-04jun12-en.pdf>.		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", 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",		[RFC1952] Deutsch, P., "GZIP file format specification version 4.3",
	RFC 1952, DOI 10.17487/RFC1952, May 1996,		RFC 1952, DOI 10.17487/RFC1952, May 1996,
	<https://www.rfc-editor.org/info/rfc1952>.		<https://www.rfc-editor.org/info/rfc1952>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,		DOI 10.17487/RFC2818, May 2000,
	<https://www.rfc-editor.org/info/rfc2818>.		<https://www.rfc-editor.org/info/rfc2818>.
	skipping to change at page 181, line 48 ¶		skipping to change at line 7687 ¶
	[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-		[RFC4180] Shafranovich, Y., "Common Format and MIME Type for Comma-
	Separated Values (CSV) Files", RFC 4180,		Separated Values (CSV) Files", RFC 4180,
	DOI 10.17487/RFC4180, October 2005,		DOI 10.17487/RFC4180, October 2005,
	<https://www.rfc-editor.org/info/rfc4180>.		<https://www.rfc-editor.org/info/rfc4180>.
	[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the
	Code: The Implementation Status Section", BCP 205,		DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012,
	RFC 7942, DOI 10.17487/RFC7942, July 2016,		<https://www.rfc-editor.org/info/rfc6672>.
	<https://www.rfc-editor.org/info/rfc7942>.
	[variantTLDsReport]		[variantTLDsReport]
	Internet Corporation for Assigned Names and Numbers		Internet Corporation for Assigned Names and Numbers
	(ICANN), "A Study of Issues Related to the Management of		(ICANN), "A Study of Issues Related to the Management of
	IDN Variant TLDs", February 2012,		IDN Variant TLDs", 20 February 2012,
	<http://www.icann.org/en/topics/idn/idn-vip-integrated-		<https://www.icann.org/en/system/files/files/idn-vip-
	issues-final-clean-20feb12-en.pdf>.		integrated-issues-final-clean-20feb12-en.pdf>.
			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, Alexander Mayrhofer, and
			Benjamin Kaduk.
			Shoji Noguchi and Francisco Arias participated as coauthors through
			version 05 of earlier drafts of this document and provided invaluable
			support.
	Authors' Addresses		Authors' Addresses
	Gustavo Lozano		Gustavo Lozano
	Internet Corporation for Assigned Names and Numbers		Internet Corporation for Assigned Names and Numbers
	12025 Waterfront Drive, Suite 300		Suite 300
	Los Angeles 90292		12025 Waterfront Drive
			Los Angeles, CA 90292
	United States of America		United States of America
	Phone: +1.310.823.9358		Phone: +1.310.823.9358
	Email: gustavo.lozano@icann.org		Email: gustavo.lozano@icann.org
	James Gould		James Gould
	VeriSign, Inc.		VeriSign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston 20190		Reston, VA 20190
	United States of America		United States of America
	Email: jgould@verisign.com		Email: jgould@verisign.com
	Chethan Thippeswamy		Chethan Thippeswamy
	VeriSign, Inc.		VeriSign, Inc.
	12061 Bluemont Way		12061 Bluemont Way
	Reston 20190		Reston, VA 20190
	United States of America		United States of America
	Email: cthippeswamy@verisign.com		Email: cthippeswamy@verisign.com
End of changes. 566 change blocks.
	2017 lines changed or deleted		1385 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/