rfc8909xml2.original.xml   rfc8909.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
nsus="true" docName="draft-ietf-regext-data-escrow-10" indexInclude="true" ipr="
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ trust200902" number="8909" prepTime="2020-11-13T16:10:15" scripts="Common,Latin"
<!-- One method to get references from the online citation libraries. sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocInclude="t
There has to be one entity for each item to be referenced. rue" xml:lang="en">
An alternate method (rfc include) is described in the references. --> <link href="https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow-10"
]> rel="prev"/>
<link href="https://dx.doi.org/10.17487/rfc8909" rel="alternate"/>
<?rfc toc="yes"?> <link href="urn:issn:2070-1721" rel="alternate"/>
<?rfc strict="yes"?> <front>
<?rfc tocompact="yes"?> <title abbrev="Registry Data Escrow">Registry Data Escrow Specification</tit
<?rfc compact="yes"?> le>
<?rfc subcompact="no"?> <seriesInfo name="RFC" value="8909" stream="IETF"/>
<?rfc tocdepth="2"?> <author initials="G." surname="Lozano" fullname="Gustavo Lozano">
<?rfc symrefs="yes"?> <organization abbrev="ICANN" showOnFrontPage="true">Internet Corporation f
<?rfc comments="yes" ?> or Assigned Names and Numbers</organization>
<?rfc sortrefs="yes" ?> <address>
<postal>
<rfc category="std" ipr="trust200902" docName="draft-ietf-regext-data-escrow-10" <street>12025 Waterfront Drive, Suite 300</street>
> <city>Los Angeles</city>
<region>CA</region>
<front> <code>90292</code>
<country>United States of America</country>
<title abbrev="Registry Data Escrow"> </postal>
<phone>+1.310.823.9358</phone>
Registry Data Escrow Specification <email>gustavo.lozano@icann.org</email>
</address>
</title> </author>
<date month="11" year="2020"/>
<author initials="G." surname="Lozano" fullname="Gustavo Lozano"> <keyword>data escrow</keyword>
<organization abbrev="ICANN"> <keyword>registry</keyword>
Internet Corporation for Assigned Names and Numbers <abstract pn="section-abstract">
</organization> <t indent="0" pn="section-abstract-1">This document specifies the format a
<address> nd contents of data escrow
<postal>
<street>12025 Waterfront Drive, Suite 300</street>
<country>United States of America</country>
<code>90292</code> <city>Los Angeles</city>
</postal>
<phone>+1.310.823.9358</phone>
<email>gustavo.lozano@icann.org</email>
</address>
</author>
<date day="1" month="Jun" year="2020"/>
<area> Applications </area>
<keyword>data escrow</keyword>
<keyword>registry</keyword>
<abstract>
<t>This document specifies the format and contents of data escrow
deposits targeted primarily for domain name registries. The deposits targeted primarily for domain name registries. The
specification is designed to be independent of the underlying specification is designed to be independent of the underlying
objects that are being escrowed and therefore it could also be used for objects that are being escrowed, and therefore it could also be used for
purposes other than domain name registries.</t> purposes other than domain name registries.</t>
</abstract> </abstract>
<boilerplate>
</front> <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
"exclude" pn="section-boilerplate.1">
<middle> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<section title="Introduction"> <t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
<t> </t>
Registry Data Escrow is the process by which a registry periodic <t indent="0" pn="section-boilerplate.1-2">
ally submits data This document is a product of the Internet Engineering Task Force
deposits to a third-party called an escrow agent. These deposits (IETF). It represents the consensus of the IETF community. It has
comprise the received public review and has been approved for publication by
minimum data needed by a third-party to resume operations if the the Internet Engineering Steering Group (IESG). Further
registry information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc8909" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-terminology">T
erminology</xref></t>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref der
ivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-problem-scope"
>Problem Scope</xref></t>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conve
ntions Used in This Document</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-date-and-time">Date an
d Time</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-protocol-description">Protocol Des
cription</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.5.2">
<li pn="section-toc.1-1.5.2.1">
<t indent="0" pn="section-toc.1-1.5.2.1.1"><xref derivedContent=
"5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-root-element-deposit">
Root Element &lt;deposit&gt;</xref></t>
</li>
<li pn="section-toc.1-1.5.2.2">
<t indent="0" pn="section-toc.1-1.5.2.2.1"><xref derivedContent=
"5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rebuilding-the-registr
y-fro">Rebuilding the Registry from Data Escrow Deposits</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-formal-syntax">Formal Syntax</xref
></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-rde-schema">RDE Schema
</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-internationalization-consid">Inter
nationalization Considerations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" fo
rmat="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-privacy-considerations">Privacy
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" fo
rmat="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-example-of-a-full-deposit">Examp
le of a Full Deposit</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="12" fo
rmat="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-example-of-a-differential-d">Exa
mple of a Differential Deposit</xref></t>
</li>
<li pn="section-toc.1-1.13">
<t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="13" fo
rmat="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-example-of-an-incremental-d">Exa
mple of an Incremental Deposit</xref></t>
</li>
<li pn="section-toc.1-1.14">
<t indent="0" pn="section-toc.1-1.14.1"><xref derivedContent="14" fo
rmat="counter" sectionFormat="of" target="section-14"/>. <xref derivedContent=""
format="title" sectionFormat="of" target="name-references">References</xref></t
>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.14.2">
<li pn="section-toc.1-1.14.2.1">
<t indent="0" pn="section-toc.1-1.14.2.1.1"><xref derivedContent
="14.1" format="counter" sectionFormat="of" target="section-14.1"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-normative-reference
s">Normative References</xref></t>
</li>
<li pn="section-toc.1-1.14.2.2">
<t indent="0" pn="section-toc.1-1.14.2.2.1"><xref derivedContent
="14.2" format="counter" sectionFormat="of" target="section-14.2"/>.  <xref deri
vedContent="" format="title" sectionFormat="of" target="name-informative-referen
ces">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.15">
<t indent="0" pn="section-toc.1-1.15.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.16">
<t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-address">Author's Addre
ss</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section numbered="true" toc="include" removeInRFC="false" pn="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
Registry Data Escrow (RDE) is the process by which a registry pe
riodically submits data
deposits to a third party called an escrow agent. These deposits
comprise the
minimum data needed by a third party to resume operations if the
registry
cannot function and is unable or unwilling to facilitate an cannot function and is unable or unwilling to facilitate an
orderly transfer of service. orderly transfer of service.
For example, for a domain name registry or registrar, the data t o be deposited For example, for a domain name registry or registrar, the data t o be deposited
would include all the objects related to registered domain names would include all of the objects related to registered domain na
, e.g., mes, e.g.,
names, contacts, name servers, etc. names, contacts, name servers.
</t> </t>
<t> <t indent="0" pn="section-1-2">
The goal of data escrow is higher resiliency of registration services, for the b The goal of data escrow is higher resiliency of registration services, for the b
enefit of Internet users. The beneficiaries of a registry are not just those re enefit of Internet users. The beneficiaries of a registry are not just those re
gistering information there, but also the users of services relying on the regis gistering information there but also the users of services relying on the regist
try data. ry data.
</t> </t>
<t> <t indent="0" pn="section-1-3">
In the context of domain name registries, registration data escr ow is In the context of domain name registries, registration data escr ow is
a requirement for generic top-level domains (e.g., Specification a requirement for generic Top-Level Domains (gTLDs) (e.g.,
2 of the ICANN Base Registry Agreement, see <xref Specification 2 of the ICANN Base Registry Agreement; see
target='ICANN-GTLD-RA-20170731' />) and some country code top-leve <xref target="ICANN-GTLD-RA-20170731" format="default" sectionFo
l rmat="of" derivedContent="ICANN-GTLD-RA-20170731"/>), and
domain managers are also currently escrowing data. some country code TLD (ccTLD)
managers are also currently escrowing data.
There is also a similar requirement for ICANN-accredited There is also a similar requirement for ICANN-accredited
domain registrars. domain registrars.
</t> </t>
<t> <t indent="0" pn="section-1-4">
This document specifies a format for data escrow deposits indepe ndent of the objects being escrowed. An independent specification is required fo r each type of registry/set of objects that is expected to be escrowed. This document specifies a format for data escrow deposits indepe ndent of the objects being escrowed. An independent specification is required fo r each type of registry/set of objects that is expected to be escrowed.
</t> </t>
<t indent="0" pn="section-1-5">
<t> The format for data escrow deposits is specified using version
The format for data escrow deposits is specified using the Exten 1.0 of the Extensible Markup Language (XML) as described in <xre
sible Markup Language (XML) 1.0 as described in <xref target='W3C.REC-xml-200811 f target="W3C.REC-xml-20081126" format="default" sectionFormat="of" derivedConte
26' /> and XML Schema notation as described in <xref target='W3C.REC-xmlschema-1 nt="W3C.REC-xml-20081126"/>, and XML Schema notation as described in <xref targe
-20041028' /> and <xref target='W3C.REC-xmlschema-2-20041028' />. t="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of" derivedCont
</t> ent="W3C.REC-xmlschema-1-20041028"/> and <xref target="W3C.REC-xmlschema-2-20041
028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-2-200
<t> 41028"/>.
Readers are advised to read the terminology section carefully to und </t>
erstand the precise meanings of Differential and Incremental Deposits as the def <t indent="0" pn="section-1-6">
initions used in this document are different from the definitions typically used Readers are advised to read <xref target="terms" format="default" se
in the domain of data backups. ctionFormat="of" derivedContent="Section 2"/> ("Terminology") carefully to under
</t> stand the precise meanings of Differential and Incremental Deposits, as the defi
nitions used in this document are different from the definitions typically used
</section> in the domain of data backups.
</t>
<section title="Terminology"> </section>
<section anchor="terms" numbered="true" toc="include" removeInRFC="false" pn
<t> ="section-2">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name slugifiedName="name-terminology">Terminology</name>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp1
"MAY", and "OPTIONAL" in this document are to be interpreted as 4>MUST NOT</bcp14>",
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
, and only when, they "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
appear in all capitals, as shown here. "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
<t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
Deposit. are to be interpreted as described in BCP 14
Deposits can be of three kinds: Full, Differential or Incrementa <xref target="RFC2119" format="default" sectionFormat="of" derivedContent
l. For all kinds of deposits, the ="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedC
universe of registry objects to be considered for data escrow ar ontent="RFC8174"/> when, and only
e those objects necessary in order to when, they appear in all capitals, as shown here.</t>
offer the registry services. <dl newline="false" spacing="normal" indent="3" pn="section-2-2">
</t> <dt pn="section-2-2.1">Deposit:</dt>
<t> <dd pn="section-2-2.2">There are three kinds of deposits: Full, Differen
Differential Deposit. Contains data that reflects all transactio tial, and
ns involving the database Incremental. For all three kinds of deposits, the
that were not reflected in the last previous Full, Incremental o universe of registry objects to be considered for data escrow
r Differential Deposit, as the case may is comprised of any objects required to offer the registry servi
ces.</dd>
<dt pn="section-2-2.3">Differential Deposit:</dt>
<dd pn="section-2-2.4">A Differential Deposit contains data that reflect
s all transactions involving the database
that were not reflected in the last previous Full, Incremental,
or Differential Deposit, as the case may
be. Differential Deposit files will contain information from all database objects that were added, be. Differential Deposit files will contain information from all database objects that were added,
modified or deleted since the previous deposit was completed as modified, or deleted since the previous deposit was completed as
of its defined Timeline Watermark. of its defined Timeline Watermark.</dd>
</t> <dt pn="section-2-2.5">Domain Name:</dt>
<t> <dd pn="section-2-2.6">See the definition of "domain name" in <xref targ
Domain Name. See definition of Domain name in <xref target='RFC8 et="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd
499' />. >
</t> <dt pn="section-2-2.7">Escrow Agent:</dt>
<t> <dd pn="section-2-2.8">An escrow agent is the organization designated by
Escrow Agent. The organization designated by the registry or the the registry or the third-party beneficiary to receive and
third-party beneficiary to receive and guard data escrow deposits from the registry.</dd>
guard data escrow deposits from the registry. <dt pn="section-2-2.9">Full Deposit:</dt>
</t> <dd pn="section-2-2.10">A Full Deposit contains the registry data that r
<t> eflects the current and complete registry
Full Deposit. Contains the registry data that reflects the curre
nt and complete registry
database and will consist of data that reflects the state of the registry as of a defined database and will consist of data that reflects the state of the registry as of a defined
Timeline Watermark for the deposit. Timeline Watermark for the deposit.</dd>
</t> <dt pn="section-2-2.11">Incremental Deposit:</dt>
<t> <dd pn="section-2-2.12">An Incremental Deposit contains data that reflec
Incremental Deposit. Contains data that reflects all transaction ts all transactions involving the database that were not
s involving the database that were not
reflected in the last previous Full Deposit. Incremental Deposit files will contain information from reflected in the last previous Full Deposit. Incremental Deposit files will contain information from
all database objects that were added, modified or deleted since all database objects that were added, modified, or deleted since
the previous Full Deposit was completed the previous Full Deposit was completed
as of its defined Timeline Watermark. as of its defined Timeline Watermark. If the Timeline Watermark
If the Timeline Watermark of an Incremental Deposit were to cover (i.e., one or of an
more Incremental or Differential Deposits exist for the period between the Timel Incremental Deposit were to cover the Timeline Watermark of another
ine Watermark of a Full and an Incremental or Differential Deposit) the Timeline Incremental or Differential Deposit since the last Full Deposit
Watermark of another Incremental or Differential Deposit since the last Full De (i.e., one or more Incremental or Differential Deposits exist for
posit, the more recent deposit MUST contain all the transactions of the earlier the period between the Timeline Watermark of a Full Deposit and an
deposit. Incremental or Differential Deposit), the more recent deposit <bcp14>MUST</bcp1
</t> 4>
<t> contain all of the transactions of the earlier deposit.
Registrar. See definition of Registrar in <xref target='RFC8499'
/>.
</t>
<t>
Registry. See definition of Registry in <xref target='RFC8499' /
>.
</t>
<t>
Third-Party Beneficiary. Is the organization that, under extraor
dinary circumstances, would receive the
escrow deposits the registry transferred to the escrow agent. Th
is organization could be a backup
registry, registry regulator, contracting party of the registry,
etc.
</t>
<t>
Timeline Watermark. Point in time on which to base the collectin
g of database objects for a deposit.
Deposits are expected to be consistent to that point in time.
</t>
<t>
Top-Level Domain. See definition of Top-Level Domain (TLD) in <x
ref target='RFC8499' />.
</t>
</section>
<section title="Problem Scope">
<t> </dd>
In the past few years, the issue of registry continuity has been <dt pn="section-2-2.13">Registrar:</dt>
carefully considered in the gTLD and <dd pn="section-2-2.14">See the definition of "registrar" in <xref targe
ccTLD space. Various organizations have carried out risk analyse t="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
s and developed business continuity plans to <dt pn="section-2-2.15">Registry:</dt>
<dd pn="section-2-2.16">See the definition of "registry" in <xref target
="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
<dt pn="section-2-2.17">Third-Party Beneficiary:</dt>
<dd pn="section-2-2.18">A third-party beneficiary is the organization th
at, under extraordinary circumstances, would receive the
escrow deposits the registry transferred to the escrow agent. Th
is organization could be a backup
registry, registry regulator, contracting party of the registry,
etc.</dd>
<dt pn="section-2-2.19">Timeline Watermark:</dt>
<dd pn="section-2-2.20">The Timeline Watermark is the point in time on w
hich to base the collecting of database objects for a deposit.
Deposits are expected to be consistent with that point in time.<
/dd>
<dt pn="section-2-2.21">Top-Level Domain (TLD):</dt>
<dd pn="section-2-2.22">See the definition of "Top-Level Domain" in <xre
f target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/
>.</dd>
</dl>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-3">
<name slugifiedName="name-problem-scope">Problem Scope</name>
<t indent="0" pn="section-3-1">
In the past few years, the issue of registry continuity has
been carefully considered in the gTLD and
ccTLD spaces. Various organizations have carried out risk analys
es and developed business continuity plans to
deal with those risks, should they materialize. deal with those risks, should they materialize.
</t> </t>
<t> <t indent="0" pn="section-3-2">
One of the solutions considered and used, especially in the gTLD space, is Registry Data Escrow as a One of the solutions considered and used, especially in the gTLD space, is Registry Data Escrow as a
way to ensure the continuity of registry services in the extreme case of registry failure. way to ensure the continuity of registry services in the extreme case of registry failure.
</t> </t>
<t> <t indent="0" pn="section-3-3">
So far, almost every registry that uses Registry Data Escrow has its own specification. It is So far, almost every registry that uses Registry Data Escrow has its own specification. It is
anticipated that more registries will be implementing escrow esp ecially with an increasing number of domain anticipated that more registries will be implementing escrow, es pecially with an increasing number of domain
registries coming into service, adding complexity to this issue. registries coming into service, adding complexity to this issue.
</t> </t>
<t> <t indent="0" pn="section-3-4">
It would seem beneficial to have a standardized specification fo r Registry Data Escrow that can be used It would seem beneficial to have a standardized specification fo r Registry Data Escrow that can be used
by any registry to submit its deposits. by any registry to submit its deposits.
</t> </t>
<t> <t indent="0" pn="section-3-5">
While the domain name industry has been the main target for this specification, it has been designed to be as general as possible. While the domain name industry has been the main target for this specification, it has been designed to be as general as possible.
</t> </t>
<t> <t indent="0" pn="section-3-6">
Specifications covering the objects used by registration organiz ations shall identify the format and contents of the deposits a Specifications covering the objects used by registration organiz ations shall identify the format and contents of the deposits a
registry has to make, such that a different registry would be ab le to rebuild the registration registry has to make, such that a different registry would be ab le to rebuild the registration
services of the former, without its help, in a timely manner, wi services of the former, without its help, in a timely manner and
th minimum disruption to its users. with minimum disruption to its users.
</t> </t>
<t> <t indent="0" pn="section-3-7">
Since the details of the registration services provided vary fro m registry to registry, specifications covering the objects Since the details of the registration services provided vary fro m registry to registry, specifications covering the objects
used by registration organizations shall provide mechanisms that used by registration organizations shall provide mechanisms that
allow its extensibility to accommodate variations and allow extensibility to accommodate variations and
extensions of the registration services. extensions of the registration services.</t>
</t> <t indent="0" pn="section-3-8">
<t>
Given the requirement for confidentiality and the importance of accuracy of the information that is handled in order to offer Given the requirement for confidentiality and the importance of accuracy of the information that is handled in order to offer
registration services, parties using this specification shall de fine confidentiality and integrity mechanisms for handling registration services, parties using this specification shall de fine confidentiality and integrity mechanisms for handling
the registration data. the registration data.
</t> </t>
<t> <t indent="0" pn="section-3-9">
Specifications covering the objects used by registration organiz ations shall not include in the specification Specifications covering the objects used by registration organiz ations shall not include in the specification
transient objects that can be recreated by the new registry, par ticularly those of delicate confidentiality, transient objects that can be recreated by the new registry, par ticularly those of delicate confidentiality,
e.g., DNSSEC KSK/ZSK private keys. e.g., DNSSEC KSK/ZSK (Key Signing Key / Zone Signing Key) privat
</t> e keys.
<t> </t>
<t indent="0" pn="section-3-10">
Details that are a matter of policy should be identified as such for the benefit of the implementers. Details that are a matter of policy should be identified as such for the benefit of the implementers.
</t> </t>
<t> <t indent="0" pn="section-3-11">
Non-technical issues concerning data escrow, such as whether to Non-technical issues concerning data escrow, such as whether
escrow data and under which purposes the data may to escrow data and for what purposes the data may
be used, are outside of scope of this document. be used, are outside the scope of this document.
</t> </t>
<t> <t indent="0" pn="section-3-12">
Parties using this specification shall use a signaling mechanism to Parties using this specification shall use a signaling mechanism to
control the transmission, reception and validation of data escrow deposits. The control the transmission, reception, and validation of data escrow deposits. The
definition of such a signaling mechanism is out of the scope of this document. definition of such a signaling mechanism is outside the scope of this document.
</t> </t>
</section>
</section> <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
<name slugifiedName="name-conventions-used-in-this-do">Conventions Used in
<section title="Conventions Used in This Document"> This Document</name>
<t indent="0" pn="section-4-1">
<t> The XML namespace prefix "rde" is used for the namespace
The XML namespace prefix "rde" is used for the namespace "urn:ietf:p "urn:ietf:params:xml:ns:rde-1.0", but implementations <bcp14>MUST NO
arams:xml:ns:rde-1.0", but implementations MUST NOT depend on it; T</bcp14> depend on it;
instead, they should employ a proper namespace-aware XML parser and instead, they should employ a proper namespace-aware XML parser
serializer to interpret and output the XML documents. and serializer to interpret and output the XML documents.
</t> </t>
<t> <t indent="0" pn="section-4-2">
The XML namespace prefix "rdeObj1" and "rdeObj2" with the correspond The XML namespace prefixes "rdeObj1" and "rdeObj2", with the corresp
ing namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and onding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and
"urn:example:params:xml:ns:rdeObj2-1.0" are used as example data esc "urn:example:params:xml:ns:rdeObj2-1.0", are used as example data es
row objects. crow objects.
</t>
</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1
">
<section title="Date and Time"> <name slugifiedName="name-date-and-time">Date and Time</name>
<t> <t indent="0" pn="section-4.1-1">
Numerous fields indicate "dates", such as the creation and e xpiry Numerous fields indicate "dates", such as the creation and e xpiry
dates for objects. These fields SHALL contain timestamps in dicating dates for objects. These fields <bcp14>SHALL</bcp14> contai n timestamps indicating
the date and time in UTC, specified in Internet Date/Time Fo rmat the date and time in UTC, specified in Internet Date/Time Fo rmat
(see <xref target="RFC3339"/>, Section 5.6) with the time-of (see <xref target="RFC3339" sectionFormat="comma" section="5
fset specified as "Z". .6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3339#section-5.6
</t> " derivedContent="RFC3339"/>) with the time-offset parameter specified as "Z".
</section> </t>
</section>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-5">
<section title="Protocol Description"> <name slugifiedName="name-protocol-description">Protocol Description</name
>
<t> <t indent="0" pn="section-5-1">The format for data escrow deposits as prod
The following is a format for data escrow deposits as produced b uced by a registry is
y a defined below. The deposits are represented in XML (<xref target="formalSyntax
registry. The deposits are represented in XML. Only " format="default" sectionFormat="of" derivedContent="Section 6"/>).
the format of the objects deposited is defined. Nothing is presc Only the format of the objects deposited is defined. This document
ribed about the method used to transfer such does not prescribe the method used to transfer such deposits between
deposits between the registry and the escrow agent or vice versa the registry and the escrow agent or vice versa.</t>
. <t indent="0" pn="section-5-2">The protocol intends to be object agnostic,
</t> allowing the "overload"
<t> of abstract elements using the "substitutionGroup" attribute
The protocol intends to be object agnostic allowing the "overloa <xref target="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of"
d" of abstract elements using derivedContent="W3C.REC-xmlschema-1-20041028"/> of the XML Schema element to de
the "substitutionGroup" attribute of the XML Schema element to d fine
efine the actual elements of an object to be escrowed. the actual elements of an object to be escrowed.</t>
</t> <t indent="0" pn="section-5-3">
The specification for each object to be escrowed <bcp14>MUST</bcp
<t> 14> declare the identifier to be
The specification for each object to be escrowed MUST declare the
identifier to be
used to reference the object to be deleted or added/modified. used to reference the object to be deleted or added/modified.
</t> </t>
<section anchor="root_element" numbered="true" toc="include" removeInRFC="
<section title="Root element &lt;deposit&gt;" anchor="root_element"> false" pn="section-5.1">
<t> <name slugifiedName="name-root-element-deposit">Root Element &lt;deposit
&gt;</name>
<t indent="0" pn="section-5.1-1">
The container or root element for a Registry Data Escrow dep osit is &lt;deposit&gt;. The container or root element for a Registry Data Escrow dep osit is &lt;deposit&gt;.
</t> </t>
<t indent="0" pn="section-5.1-2">
<t>
The &lt;deposit&gt; element contains the following attribute s: The &lt;deposit&gt; element contains the following attribute s:
</t> </t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5
<t> .1-3">
<list style="symbols"> <li pn="section-5.1-3.1">
<t> <t indent="0" pn="section-5.1-3.1.1">
A REQUIRED &quot;type&quot; attribute that is used to ident A <bcp14>REQUIRED</bcp14> "type" attribute that is used to
ify the kind of deposit: identify the kind of deposit:
<list style="symbols"> </t>
<t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="secti
FULL: Full. on-5.1-3.1.2">
</t> <li pn="section-5.1-3.1.2.1">
<t> FULL: Full.
INCR: Incremental. </li>
</t> <li pn="section-5.1-3.1.2.2">
<t> INCR: Incremental.
DIFF: Differential. </li>
</t> <li pn="section-5.1-3.1.2.3">
</list> DIFF: Differential.
</t> </li>
<t> </ul>
A REQUIRED &quot;id&quot; attribute that is used to </li>
uniquely identify the escrow deposit. <li pn="section-5.1-3.2">
A <bcp14>REQUIRED</bcp14> "id" attribute that is use
d to uniquely identify the escrow deposit.
Each registry is responsible for maintaining its own escrow deposits' identifier Each registry is responsible for maintaining its own escrow deposits' identifier
space to ensure uniqueness. space to ensure uniqueness.
</t> </li>
<t> <li pn="section-5.1-3.3">
A &quot;prevId&quot; attribute that can be used to i A "prevId" attribute that can be used to identify th
dentify the previous e previous
Incremental, Differential or Full Deposit. This att Incremental, Differential, or Full Deposit. This at
ribute is REQUIRED tribute is <bcp14>REQUIRED</bcp14>
in Differential Deposits (&quot;DIFF&quot; type), is in Differential Deposits ("DIFF" type), is <bcp14>OP
OPTIONAL in Incremental TIONAL</bcp14> in Incremental
Deposits (&quot;INCR&quot; type), and is not used in Deposits ("INCR" type), and is not used in Full Depo
Full Deposits (&quot;FULL&quot; sits ("FULL"
type). type).
</t> </li>
<!-- Review FA --> <li pn="section-5.1-3.4">
<t> An <bcp14>OPTIONAL</bcp14> "resend" attribute that i
An OPTIONAL &quot;resend&quot; attribute that is inc s incremented
remented
each time the escrow deposit failed the verification procedure at the receiving party each time the escrow deposit failed the verification procedure at the receiving party
and a new escrow deposit needs to be generated by th e registry for that specific date. and a new escrow deposit needs to be generated by th e registry for that specific date.
The first time a deposit is generated the attribute The first time a deposit is generated, the
is either omitted or MUST be "0". attribute either (1) is omitted or (2) <bcp14>MUST</
If a deposit needs to be generated again, the attrib bcp14> be "0".
ute MUST be set to "1", and so on. If a deposit needs to be generated again, the attrib
</t> ute <bcp14>MUST</bcp14> be set to "1", and so on.
<!-- End Review FA --> </li>
</list> </ul>
</t> <t indent="0" pn="section-5.1-4">
The &lt;deposit&gt; element contains the following child
<t> elements:
The &lt;deposit&gt; element contains the following the ch </t>
ild elements: <section anchor="watermark" numbered="true" toc="exclude" removeInRFC="f
</t> alse" pn="section-5.1.1">
<name slugifiedName="name-child-watermark-element">Child &lt;watermark
<section title="Child &lt;watermark&gt; element" anchor="watermark"> &gt; Element</name>
<t> <t indent="0" pn="section-5.1.1-1">
A REQUIRED &lt;watermark&gt; element contains the date-time A <bcp14>REQUIRED</bcp14> &lt;watermark&gt; element
corresponding to contains the date-time <xref target="RFC3339" format="defaul
the Timeline Watermark of the deposit. t" sectionFormat="of" derivedContent="RFC3339"/> corresponding to
</t> the Timeline Watermark of the deposit.</t>
</section>
</section> <section anchor="rdeMenu" numbered="true" toc="exclude" removeInRFC="fal
se" pn="section-5.1.2">
<section title="Child &lt;rdeMenu&gt; element" anchor="rdeMenu"> <name slugifiedName="name-child-rdemenu-element">Child &lt;rdeMenu&gt;
<t> Element</name>
This element contains auxiliary information of the data escr <t indent="0" pn="section-5.1.2-1">
ow deposit. This element contains auxiliary information regarding the da
</t> ta escrow deposit.
</t>
<t> <t indent="0" pn="section-5.1.2-2">
A REQUIRED &lt;rdeMenu&gt; element contains the following ch A <bcp14>REQUIRED</bcp14> &lt;rdeMenu&gt; element contains t
ild elements: he following child elements:
</t> </t>
<t> <ul spacing="normal" bare="false" empty="false" indent="3" pn="section
<list style="symbols"> -5.1.2-3">
<t> <li pn="section-5.1.2-3.1">
A REQUIRED &lt;version&gt; element that identifies t A <bcp14>REQUIRED</bcp14> &lt;version&gt; element th
he RDE protocol version, this value MUST be 1.0. at identifies the RDE protocol version. This value <bcp14>MUST</bcp14> be 1.0.
</t> </li>
<t> <li pn="section-5.1.2-3.2">
One or more &lt;objURI&gt; elements that contain nam espace URIs One or more &lt;objURI&gt; elements that contain nam espace URIs
representing the &lt;contents&gt; and &lt;deletes&gt ; element objects. representing the &lt;contents&gt; and &lt;deletes&gt ; element objects.
</t> </li>
</list> </ul>
</t> </section>
<section anchor="deletes" numbered="true" toc="exclude" removeInRFC="fal
</section> se" pn="section-5.1.3">
<name slugifiedName="name-child-deletes-element">Child &lt;deletes&gt;
<section title="Child &lt;deletes&gt; element" anchor="deletes"> Element</name>
<t>For Differential Deposits, this element contains the list of <t indent="0" pn="section-5.1.3-1">For Differential Deposits, this ele
objects that have ment contains the list of objects that have
been deleted since the previous deposit of any type. For Incremental been deleted since the previous deposit of any type. For Incremental
Deposits, this element contains the list of objects that have been deleted Deposits, this element contains the list of objects that have been deleted
since the previous Full Deposit. since the previous Full Deposit.
</t> </t>
<t> <t indent="0" pn="section-5.1.3-2">
This section of the deposit MUST NOT be present in Full Depo This section of the deposit <bcp14>MUST NOT</bcp14> be prese
sits. nt in Full Deposits.
</t> </t>
</section>
</section> <section anchor="contents" numbered="true" toc="exclude" removeInRFC="fa
lse" pn="section-5.1.4">
<section title="Child &lt;contents&gt; element" anchor="contents"> <name slugifiedName="name-child-contents-element">Child &lt;contents&g
<t>For Full Deposits this element contains all objects. For Dif t; Element</name>
ferential <t indent="0" pn="section-5.1.4-1">For Full Deposits, this element con
tains all objects. For Differential
Deposits, this element contains the list of objects that have been added or Deposits, this element contains the list of objects that have been added or
modified since the previous deposit of any type. For Incremental Deposits, modified since the previous deposit of any type. For Incremental Deposits,
this element contains the list of objects that have been added or modified this element contains the list of objects that have been added or modified
since the previous Full Deposit. since the previous Full Deposit.
</t> </t>
</section>
</section> </section>
</section>
<section title="Rebuilding the registry from data escrow deposits <section anchor="rebuilding" numbered="true" toc="include" removeInRFC="fa
" anchor="rebuilding"> lse" pn="section-5.2">
<name slugifiedName="name-rebuilding-the-registry-fro">Rebuilding the Re
<t> gistry from Data Escrow Deposits</name>
<t indent="0" pn="section-5.2-1">
When applying Incremental or Differential Deposits (when reb uilding When applying Incremental or Differential Deposits (when reb uilding
the registry from data escrow deposits), the relative order of the the registry from data escrow deposits), the relative order of the
&lt;deletes&gt; and &lt;contents&gt; elements is important b ecause dependencies &lt;deletes&gt; and &lt;contents&gt; elements is important b ecause dependencies
may exist between the objects. All the &lt;deletes&gt; elem may exist between the objects. All of the &lt;deletes&gt; e
ents MUST be applied lements <bcp14>MUST</bcp14> be applied
first, in the order that they appear. All the &lt;contents& first, in the order in which they appear. All of the &lt;co
gt; elements ntents&gt; elements
MUST be applied next, in the order that they appear. <bcp14>MUST</bcp14> be applied next, in the order in which
</t> they appear.
</t>
<t> <t indent="0" pn="section-5.2-2">
If an object is present in the &lt;contents&gt; or &lt;delet If an object is present in the &lt;contents&gt; or
es&gt; section of several deposits (e.g. Full and Differential) the registry dat &lt;deletes&gt; section of several deposits (e.g., Full
a from the latest deposit (as defined by the Timeline Watermark) SHOULD be used and Differential), the registry data from the latest
when rebuilding the registry. An object SHOULD NOT exist multiple times either i deposit (as defined by the Timeline Watermark)
n the &lt;contents&gt; or &lt;deletes&gt; elements in a single deposit. <bcp14>SHOULD</bcp14> be used when rebuilding the
</t> registry. An object <bcp14>SHOULD NOT</bcp14> exist
multiple times in either the &lt;contents&gt; or
<t>When rebuilding a &lt;deletes&gt; elements in a single deposit.</t>
<t indent="0" pn="section-5.2-3">When rebuilding a
registry, the registry, the
&lt;deletes&gt; section MUST be ignored if present in a Full &lt;deletes&gt; section <bcp14>MUST</bcp14> be ignored if pr
Deposit.</t> esent in a Full Deposit.</t>
</section>
</section> </section>
</section>
<section title="Formal Syntax" anchor="formalSyntax"> <section anchor="formalSyntax" numbered="true" toc="include" removeInRFC="fa
lse" pn="section-6">
<t>RDE is specified in XML Schema notation. The formal syntax p <name slugifiedName="name-formal-syntax">Formal Syntax</name>
resented <t indent="0" pn="section-6-1">RDE is specified in XML Schema notation. T
here is a complete schema representation of RDE suitable he formal syntax presented
for here is a complete schema representation of RDE suitable
automated validation of RDE XML instances.</t> for
<t>The BEGIN and END tags are not part of the schema; they are u automated validation of RDE XML instances.</t>
sed to note <t indent="0" pn="section-6-2">The &lt;CODE BEGINS&gt; and &lt;CODE ENDS&g
the beginning and ending of the schema for URI registrati t; tags are not part of the schema; they are used to note
on purposes.</t> the beginning and ending of the schema for URI registrat
ion purposes.</t>
<section title="RDE Schema"> <section numbered="true" toc="include" removeInRFC="false" pn="section-6.1
">
<t> <name slugifiedName="name-rde-schema">RDE Schema</name>
<figure><artwork><![CDATA[BEGIN <sourcecode markers="true" name="" type="xml" pn="section-6.1-1">
<?xml version="1.0" encoding="UTF-8"?> &lt;?xml version="1.0" encoding="UTF-8"?&gt;
<schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0" &lt;schema targetNamespace="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"> elementFormDefault="qualified"&gt;
<annotation> &lt;annotation&gt;
<documentation> &lt;documentation&gt;
Registry Data Escrow schema Registry Data Escrow schema
</documentation> &lt;/documentation&gt;
</annotation> &lt;/annotation&gt;
<!-- Root element -->
<element name="deposit" type="rde:escrowDepositType"/>
<!-- RDE types -->
<complexType name="escrowDepositType">
<sequence>
<element name="watermark" type="dateTime"/>
<element name="rdeMenu" type="rde:rdeMenuType"/>
<element name="deletes" type="rde:deletesType" minOccurs="0"/>
<element name="contents" type="rde:contentsType" minOccurs="0"/>
</sequence>
<attribute name="type" type="rde:depositTypeType" use="required"/>
<attribute name="id" type="rde:depositIdType" use="required"/>
<attribute name="prevId" type="rde:depositIdType"/>
<attribute name="resend" type="unsignedShort" default="0"/>
</complexType>
<!-- Menu type -->
<complexType name="rdeMenuType">
<sequence>
<element name="version" type="rde:versionType"/>
<element name="objURI" type="anyURI" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- Deletes Type --> &lt;!-- Root element --&gt;
<complexType name="deletesType"> &lt;element name="deposit" type="rde:escrowDepositType"/&gt;
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="rde:delete"/>
</sequence>
</complexType>
<element name="delete" type="rde:deleteType" abstract="true" /> &lt;!-- RDE types --&gt;
<complexType name="deleteType"> &lt;complexType name="escrowDepositType"&gt;
<complexContent> &lt;sequence&gt;
<restriction base="anyType"/> &lt;element name="watermark" type="dateTime"/&gt;
</complexContent> &lt;element name="rdeMenu" type="rde:rdeMenuType"/&gt;
</complexType> &lt;element name="deletes" type="rde:deletesType" minOccurs="0"/&gt;
&lt;element name="contents" type="rde:contentsType"
minOccurs="0"/&gt;
&lt;/sequence&gt;
&lt;attribute name="type" type="rde:depositTypeType"
use="required"/&gt;
&lt;attribute name="id" type="rde:depositIdType" use="required"/&gt;
&lt;attribute name="prevId" type="rde:depositIdType"/&gt;
&lt;attribute name="resend" type="unsignedShort" default="0"/&gt;
&lt;/complexType&gt;
<!-- Contents Type --> &lt;!-- Menu type --&gt;
<complexType name="contentsType"> &lt;complexType name="rdeMenuType"&gt;
<sequence minOccurs="0" maxOccurs="unbounded"> &lt;sequence&gt;
<element ref="rde:content"/> &lt;element name="version" type="rde:versionType"/&gt;
</sequence> &lt;element name="objURI" type="anyURI" maxOccurs="unbounded"/&gt;
</complexType> &lt;/sequence&gt;
&lt;/complexType&gt;
<element name="content" type="rde:contentType" abstract="true" /> &lt;!-- Deletes type --&gt;
<complexType name="contentType"> &lt;complexType name="deletesType"&gt;
<complexContent> &lt;sequence minOccurs="0" maxOccurs="unbounded"&gt;
<restriction base="anyType"/> &lt;element ref="rde:delete"/&gt;
</complexContent> &lt;/sequence&gt;
</complexType> &lt;/complexType&gt;
<!-- Type of deposit --> &lt;element name="delete" type="rde:deleteType" abstract="true"/&gt;
<simpleType name="depositTypeType"> &lt;complexType name="deleteType"&gt;
<restriction base="token"> &lt;complexContent&gt;
<enumeration value="FULL"/> &lt;restriction base="anyType"/&gt;
<enumeration value="INCR"/> &lt;/complexContent&gt;
<enumeration value="DIFF"/> &lt;/complexType&gt;
</restriction>
</simpleType>
<!-- Deposit identifier type --> &lt;!-- Contents type --&gt;
<simpleType name="depositIdType"> &lt;complexType name="contentsType"&gt;
<restriction base="token"> &lt;sequence minOccurs="0" maxOccurs="unbounded"&gt;
<pattern value="\w{1,13}"/> &lt;element ref="rde:content"/&gt;
</restriction> &lt;/sequence&gt;
</simpleType> &lt;/complexType&gt;
<!-- A RDE version number is a dotted pair of decimal numbers --> &lt;element name="content" type="rde:contentType" abstract="true"/&gt;
<simpleType name="versionType"> &lt;complexType name="contentType"&gt;
<restriction base="token"> &lt;complexContent&gt;
<pattern value="[1-9]+\.[0-9]+"/> &lt;restriction base="anyType"/&gt;
<enumeration value="1.0"/> &lt;/complexContent&gt;
</restriction> &lt;/complexType&gt;
</simpleType>
</schema> &lt;!-- Type of deposit --&gt;
END]]></artwork></figure> &lt;simpleType name="depositTypeType"&gt;
</t> &lt;restriction base="token"&gt;
&lt;enumeration value="FULL"/&gt;
&lt;enumeration value="INCR"/&gt;
&lt;enumeration value="DIFF"/&gt;
&lt;/restriction&gt;
&lt;/simpleType&gt;
</section> &lt;!-- Deposit identifier type --&gt;
&lt;simpleType name="depositIdType"&gt;
&lt;restriction base="token"&gt;
&lt;pattern value="\w{1,13}"/&gt;
&lt;/restriction&gt;
&lt;/simpleType&gt;
</section> &lt;!-- A RDE version number is a dotted pair of decimal numbers --&gt;
&lt;simpleType name="versionType"&gt;
&lt;restriction base="token"&gt;
&lt;pattern value="[1-9]+\.[0-9]+"/&gt;
&lt;enumeration value="1.0"/&gt;
&lt;/restriction&gt;
&lt;/simpleType&gt;
<section title="Internationalization Considerations"> &lt;/schema&gt;</sourcecode>
<t> </section>
</section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-7">
<name slugifiedName="name-internationalization-consid">Internationalizatio
n Considerations</name>
<t indent="0" pn="section-7-1">
Data escrow deposits are represented in XML, which provides nati ve support for encoding information Data escrow deposits are represented in XML, which provides nati ve support for encoding information
using the Unicode character set and its more compact representat ions including UTF-8. Conformant XML using the Unicode character set and its more compact representat ions, including UTF-8. Conformant XML
processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other
character encodings through use of an "encoding" attribute in an character encodings through the use of an "encoding" attribute
&lt;?xml?&gt; declaration, use of UTF-8 in an &lt;?xml?&gt; declaration, the use of UTF-8
is RECOMMENDED. is <bcp14>RECOMMENDED</bcp14>.
</t> </t>
</section> </section>
<section numbered="true" toc="include" removeInRFC="false" pn="section-8">
<section title="IANA Considerations"> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
<t> <t indent="0" pn="section-8-1">
This document uses URNs to describe XML namespaces and XML schem as This document uses URNs to describe XML namespaces and XML schem as
conforming to a registry mechanism described in <xref target="RF C3688"/>. conforming to a registry mechanism described in <xref target="RF C3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>.
Two URI assignments have been registered by the IANA. Two URI assignments have been registered by the IANA.
</t> </t>
<t indent="0" pn="section-8-2">Registration for the RDE namespace:</t>
<t>Registration request for the RDE namespace: <dl newline="false" spacing="compact" indent="3" pn="section-8-3">
<list> <dt pn="section-8-3.1">URI:</dt>
<t>URI: urn:ietf:params:xml:ns:rde-1.0</t> <dd pn="section-8-3.2">urn:ietf:params:xml:ns:rde-1.0</dd>
<dt pn="section-8-3.3">Registrant Contact:</dt>
<t>Registrant Contact: IESG &lt;regext@ietf.org&g <dd pn="section-8-3.4">IESG</dd>
t;</t> <dt pn="section-8-3.5">XML:</dt>
<dd pn="section-8-3.6">None. Namespace URIs do not represent an XML spe
<t>Note to RFC Editor: Please remove the email ad cification.</dd>
dress from the RFC after IANA records it.</t> </dl>
<t indent="0" pn="section-8-4">Registration for the RDE XML schema:
<t>XML: None. Namespace URIs do not represent an XML specif </t>
ication.</t> <dl newline="false" spacing="compact" indent="3" pn="section-8-5">
</list> <dt pn="section-8-5.1">URI:</dt>
</t> <dd pn="section-8-5.2">urn:ietf:params:xml:schema:rde-1.0</dd>
<t>Registration request for the RDE XML schema: <dt pn="section-8-5.3">Registrant Contact:</dt>
<list> <dd pn="section-8-5.4">IESG</dd>
<t>URI: urn:ietf:params:xml:schema:rde-1.0</t> </dl>
<t indent="0" pn="section-8-6">See <xref target="formalSyntax" format="def
<t>Registrant Contact: IESG &lt;regext@ietf.org&g ault" sectionFormat="of" derivedContent="Section 6"/> ("Formal Syntax") of this
t;</t> document.</t>
</section>
<t>Note to RFC Editor: Please remove the email ad <section numbered="true" toc="include" removeInRFC="false" pn="section-9">
dress from the RFC after IANA records it.</t> <name slugifiedName="name-security-considerations">Security Considerations
</name>
<t>See the &quot;Formal Syntax&quot; section of this documen <t indent="0" pn="section-9-1">
t.</t>
</list>
</t>
</section>
<section anchor="ImplementationStatus" title="Implementation Status">
<t>Note to RFC Editor: Please remove this section and the reference
to RFC 7942 <xref target="RFC7942"/> before publication.</t>
<t>
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this Internet-D
raft, and is based on a proposal described in RFC 7942 <xref target="RFC7942"/>.
The description of implementations in this section is intended to assist the I
ETF in its decision processes in progressing drafts to RFCs. Please note that t
he listing of any individual implementation here does not imply endorsement by t
he IETF. Furthermore, no effort has been spent to verify the information presen
ted here that was supplied by IETF contributors. This is not intended as, and mu
st not be construed to be, a catalog of available implementations or their featu
res. Readers are advised to note that other implementations may exist.
</t>
<t>
According to RFC 7942 <xref target="RFC7942"/>, "this will allow
reviewers and working groups to assign due consideration to documents that have
the benefit of running code, which may serve as evidence of valuable experiment
ation 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".
</t>
<section title="Implementation in the gTLD space">
<t>Organization: ICANN</t>
<t>Name: ICANN Registry Agreement</t>
<t>Description: the ICANN Base Registry Agreement requires Regis
tries, Data Escrow Agents, and ICANN to implement this specification. ICANN rece
ives 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 Registr
ation Data Access file that also complies with this specification. In addition,
ICANN is aware of Registry Service Provider transitions using data files that co
nform to this specification.</t>
<t>Level of maturity: production.</t>
<t>Coverage: all aspects of this specification are implemented.<
/t>
<t>Version compatibility: versions 03 - 08 are known to be imple
mented.</t>
<t>Contact: gustavo.lozano@icann.org</t>
<t>URL: https://www.icann.org/resources/pages/registries/registr
ies-agreements-en</t>
</section>
</section>
<section title="Security Considerations">
<t>
This specification does not define the security mechanisms to be used in the transmission of the data escrow This specification does not define the security mechanisms to be used in the transmission of the data escrow
deposits, since it only specifies the minimum necessary to enabl e the rebuilding of a registry from deposits, since it only specifies the minimum necessary to enabl e the rebuilding of a registry from
deposits without intervention from the original registry. deposits without intervention from the original registry.
</t> </t>
<t> <t indent="0" pn="section-9-2">
Depending on local policies, some elements, or, most likely, the Depending on local policies, some elements -- or, most likely,
whole deposit will be considered confidential. As such, the parties SHOULD take the whole deposit -- will be considered confidential. As such, t
all the necessary precautions such as encrypting the data at rest and in transi he parties <bcp14>SHOULD</bcp14> take all necessary precautions, such as encrypt
t to avoid inadvertent disclosure of private data. Regardless of the precautions ing the data at rest and in transit to avoid inadvertent disclosure of private d
taken by the parties regarding data at rest and in transit, authentication cred ata. Regardless of the precautions taken by the parties regarding data at rest a
entials MUST NOT be escrowed. nd in transit, authentication credentials <bcp14>MUST NOT</bcp14> be escrowed.
</t> </t>
<t> <t indent="0" pn="section-9-3">
Authentication of the parties passing data escrow deposit files is also of the utmost importance. The Authentication of the parties passing data escrow deposit files is also of the utmost importance. The
escrow agent MUST properly authenticate the identity of the regi escrow agent <bcp14>MUST</bcp14> properly authenticate the ident
stry before accepting data escrow ity of the registry before accepting data escrow
deposits. In a similar manner, the registry MUST authenticate th deposits. Similarly, the registry <bcp14>MUST</bcp14> authentica
e identity of the escrow agent te the identity of the escrow agent
before submitting any data. before submitting any data.
</t> </t>
<t> <t indent="0" pn="section-9-4">
Additionally, the registry and the escrow agent MUST use integri Additionally, the registry and the escrow agent
ty checking mechanisms to ensure the <bcp14>MUST</bcp14> use integrity-checking mechanisms to
data transmitted is what the source intended. Validation of the ensure that the
contents by the escrow agent is RECOMMENDED data transmitted is what the source intended. Validation of the
to ensure not only that the file was transmitted correctly from contents by the escrow agent is <bcp14>RECOMMENDED</bcp14>
the registry, but also that the contents are to ensure not only that the file was transmitted correctly from
&quot;meaningful&quot;. the registry but also that the contents are
</t> "meaningful".
<t>Note: if Transport Layer Security (TLS) is used when providing an </t>
escrow services, the recommendations in <xref target="RFC7525"/> MUST be implem <aside pn="section-9-5">
ented.</t> <t indent="0" pn="section-9-5.1">Note: If Transport Layer Security (TLS)
</section> is used when providing
an escrow service, the recommendations in <xref target="RFC7525" format="d
<section title="Privacy Considerations"> efault" sectionFormat="of" derivedContent="RFC7525"/> <bcp14>MUST</bcp14> be imp
<t> lemented.</t>
This specification defines a format that may be used to escrow personal data. T </aside>
he process of data escrow is governed by a legal document agreed by the parties, </section>
and such legal document must ensure that privacy-sensitive and/or personal data <section numbered="true" toc="include" removeInRFC="false" pn="section-10">
receives the required protection. <name slugifiedName="name-privacy-considerations">Privacy Considerations</
</t> name>
</section> <t indent="0" pn="section-10-1">
This specification defines a format that may be used to escrow personal data.
<section title="Acknowledgments"> The process of data escrow is governed by a legal document agreed upon by the
<t> parties, and such a legal document must ensure that privacy-sensitive and/or per
Special suggestions that have been incorporated into this docume sonal data receives the required protection.
nt </t>
were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawr </section>
ence Conroy, Marc Groeneweg, <section numbered="true" toc="include" removeInRFC="false" pn="section-11">
Michael Young, Chris Wright, Patrick Mevzek, Stephen Morris, Sco <name slugifiedName="name-example-of-a-full-deposit">Example of a Full Dep
tt Hollenbeck, Stephane Bortzmeyer, osit</name>
Warren Kumari, Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim <t indent="0" pn="section-11-1">Example of a Full Deposit with the two exa
Galvin, Andrew Sullivan, Hiro Hotta, mple objects rdeObj1 and rdeObj2:</t>
Christopher Browne, Daniel Kalchev, David Conrad, James Mitchell <sourcecode name="" type="xml" markers="false" pn="section-11-2">
, Francisco Obispo, Bhadresh Modi and &lt;?xml version="1.0" encoding="UTF-8"?&gt;
Alexander Mayrhofer. &lt;rde:deposit
</t>
<t> Shoji Noguchi and Francisco Arias participated
as co-authors until version 07 providing invaluable support for
this
document.</t>
</section>
<section title="Change History">
<t>
[[RFC Editor: Please remove this section.]]
</t>
<section title="Changes from 00 to 01">
<t>
<list style="numbers">
<t>Included DNSSEC elements as part of the basic &lt;dom
ain&gt; element as defined in RFC 5910.</t>
<t>Included RGP elements as part of the basic &lt;domain
&gt; element as defined in RFC 3915.</t>
<t>Added support for IDNs and IDN variants.</t>
<t>Eliminated the &lt;summary&gt; element and all its su
bordinate objects, except &lt;watermarkDate&gt;.</t>
<t>Renamed &lt;watermarkDate&gt; to &lt;watermark&gt; an
d included it directly under root element.</t>
<t>Renamed root element to &lt;deposit&gt;.</t>
<t>Added &lt;authinfo&gt; element under &lt;registrar&gt
; element.</t>
<t>Added &lt;roid&gt; element under &lt;registrar&gt; el
ement.</t>
<t>Reversed the order of the &lt;deletes&gt; and &lt;con
tents&gt; elements.</t>
<t>Removed &lt;rdeDomain:status&gt; minOccurs=&quot;0&qu
ot;.</t>
<t>Added &lt;extension&gt; element under root element.</
t>
<t>Added &lt;extension&gt; element under &lt;contact&gt;
element.</t>
<t>Removed &lt;period&gt; element from &lt;domain&gt; el
ement.</t>
<t>Populated the &quot;Security Considerations&quot; sec
tion.</t>
<t>Populated the &quot;Internationalization Consideratio
ns&quot; section.</t>
<t>Populated the &quot;Extension Example&quot; section.<
/t>
<t>Added &lt;deDate&gt; element under &lt;domain&gt; ele
ment.</t>
<t>Added &lt;icannID&gt; element under &lt;registrar&gt;
element.</t>
<t>Added &lt;eppParams&gt; element under root element.</
t>
<t>Fixed some typographical errors and omissions.</t>
</list>
</t>
</section>
<section title="Changes from 01 to 02">
<t>
<list style="numbers">
<t>Added definition for "canonical" in the "IDN variants
Handling" section.</t>
<t>Clarified that "blocked" and "reserved" IDN variants
are optional.</t>
<t>Made &lt;rdeRegistrar:authInfo&gt; optional.</t>
<t>Introduced substitutionGroup as the mechanism for ext
ending the protocol.</t>
<t>Moved &lt;eppParams&gt; element to be child of &lt;co
ntents&gt;.</t>
<t>Text improvements in the Introduction, Terminology, a
nd Problem Scope per Jay's suggestion.</t>
<t>Removed &lt;trDate&gt; from &lt;rdeDomain&gt; and add
ed &lt;trnData&gt; instead, which
include all the data from the last (pending/processe
d) transfer request.</t>
<t>Removed &lt;trDate&gt; from &lt;rdeContact&gt; and ad
ded &lt;trnData&gt; instead, which
include all the data from the last (pending/processe
d) transfer request.</t>
<t>Fixed some typographical errors and omissions.</t>
</list>
</t>
</section>
<section title="Changes from 02 to 03">
<t>
<list style="numbers">
<t>Separated domain name objects from protocol.</t>
<t>Moved &lt;extension&gt; elements to be child of &lt;d
eletes&gt; and &lt;contents&gt;,
additionally removed &lt;extension&gt; element from
&lt;rdeDomain&gt;,&lt;rdeHost&gt;,
&lt;rdeContact&gt;,&lt;rdeRegistrar&gt; and &lt;rdeI
DN&gt; elements.</t>
<t>Modified the definition of &lt;rde:id&gt; and &lt;rde
:prevId&gt;.</t>
<t>Added &lt;rdeMenu&gt; element under &lt;deposit&gt; e
lement.</t>
<t>Fixed some typographical errors and omissions.</t>
</list>
</t>
</section>
<section title="Changes from 03 to 04">
<t>
<list style="numbers">
<t>Removed &lt;eppParams&gt; objects.</t>
<t>Populated the &quot;Extension Guidelines&quot; sectio
n.</t>
<t>Fixed some typographical errors and omissions.</t>
</list>
</t>
</section>
<section title="Changes from 04 to 05">
<t>
<list style="numbers">
<t>Fixes to the XSD.</t>
<t>Extension Guidelines moved to dnrd-mappings draft.</t
>
<t>Fixed some typographical errors and omissions.</t>
</list>
</t>
</section>
<section title="Changes from 05 to 06">
<t>
<list style="numbers">
<t>Fix resend definition.</t>
</list>
</t>
</section>
<section title="Changes from 06 to 07">
<t>
<list style="numbers">
<t>Editorial updates.</t>
<t>schemaLocation removed from RDE Schema.</t>
</list>
</t>
</section>
<section title="Changes from 07 to 08">
<t>
<list style="numbers">
<t>Ping update.</t>
</list>
</t>
</section>
<section title="Changes from 08 to 09">
<t>
<list style="numbers">
<t>Ping update.</t>
</list>
</t>
</section>
<section title="Changes from 09 to 10">
<t>
<list style="numbers">
<t>Implementation Status section was added.</t>
</list>
</t>
</section>
<section title="Changes from 10 to 11">
<t>
<list style="numbers">
<t>Ping update.</t>
</list>
</t>
</section>
<section title="Changes from 11 to REGEXT 00">
<t>
<list style="numbers">
<t>Internet Draft (I-D) adopted by the REGEXT WG.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 00 to REGEXT 01">
<t>
<list style="numbers">
<t>Privacy consideration section was added.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 01 to REGEXT 02">
<t>
<list style="numbers">
<t>Updated the Security Considerations section to make t
he language normative.</t>
<t>Updated the rde XML schema to remove the dependency w
ith the eppcom namespace reference.</t>
<t>Editorial updates.</t>
<t>Remove the reference to RFC 5730.</t>
<t>Added complete examples of deposits.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 02 to REGEXT 03">
<t>
<list style="numbers">
<t>The &lt;contents&gt; section changed from MUST to SH
OULD, in order to accommodate an Incremental or Differential Deposit that only i
ncludes deletes.</t>
<t>Editorial updates.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 03 to REGEXT 04">
<t>
<list style="numbers">
<t>Moved <xref target="RFC8499"/> to the Normative Refer
ences section.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 04 to REGEXT 05">
<t>
<list style="numbers">
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/UNo6YxapgjyerAYv0223zEuzjFk</t>
<t>The examples of deposits were moved to their o
wn sections.</t>
<t>&lt;deposit&gt; elements definition moved to s
ection 5.1.</t>
<t>The DIFF example was modified to make it more
representative of a differential deposit.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 05 to REGEXT 06">
<t>
<list style="numbers">
<t>Normative references for XLM, XML Schema added.</t>
<t>Text added to define that version MUST be 1.0.
</t>
<t>Normative SHOULD replaced should in the second
paragraph in the security section.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 06 to REGEXT 07">
<t>
<list style="numbers">
<t>Registration contact changed in section 8.</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 07 to REGEXT 08">
<t>
<list style="numbers">
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/hDLz2ym4oR-ukA4Fm-QJ8FzaxxE</t>
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/780Xw-z1RMRb79nmZ6ABmRTo1fU</t>
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/YnPnrSedrCcgQ2AXbjBTuQzqMds</t>
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/BiV0NHi_k7cYwTiLdLwVgqEcFuo</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 08 to REGEXT 09">
<t>
<list style="numbers">
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/x_8twvi-MS4dDDRfAZfNJH92UaQ</t>
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/B3QTxUCWUE4R_QharAQlA3041j0</t>
</list>
</t>
</section>
<section title="Changes from version REGEXT 09 to REGEXT 10">
<t>
<list style="numbers">
<t>Changes based on the feedback provided here: https://
mailarchive.ietf.org/arch/msg/regext/UaMNvl1xh60ldjpqHHYc3TNsfhg</t>
</list>
</t>
</section>
</section>
<section title="Example of a Full Deposit">
<t>Example of a Full Deposit with the two example objects rdeObj1 and rdeObj2:</
t>
<t>
<figure><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0" xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0" xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
type="FULL" type="FULL"
id="20191018001"> id="20191018001"&gt;
<rde:watermark>2019-10-17T23:59:59Z</rde:watermark> &lt;rde:watermark&gt;2019-10-17T23:59:59Z&lt;/rde:watermark&gt;
<rde:rdeMenu> &lt;rde:rdeMenu&gt;
<rde:version>1.0</rde:version> &lt;rde:version&gt;1.0&lt;/rde:version&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
</rde:rdeMenu> &lt;/rde:rdeMenu&gt;
<rde:contents> &lt;rde:contents&gt;
<rdeObj1:rdeObj1> &lt;rdeObj1:rdeObj1&gt;
<rdeObj1:name>EXAMPLE</rdeObj1:name> &lt;rdeObj1:name&gt;EXAMPLE&lt;/rdeObj1:name&gt;
</rdeObj1:rdeObj1> &lt;/rdeObj1:rdeObj1&gt;
<rdeObj2:rdeObj2> &lt;rdeObj2:rdeObj2&gt;
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id> &lt;rdeObj2:id&gt;fsh8013-EXAMPLE&lt;/rdeObj2:id&gt;
</rdeObj2:rdeObj2> &lt;/rdeObj2:rdeObj2&gt;
</rde:contents> &lt;/rde:contents&gt;
</rde:deposit> &lt;/rde:deposit&gt;</sourcecode>
]]></artwork></figure> </section>
</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-12">
<name slugifiedName="name-example-of-a-differential-d">Example of a Differ
</section> ential Deposit</name>
<t indent="0" pn="section-12-1">Example of a Differential Deposit with the
<section title="Example of a Differential Deposit"> two example objects rdeObj1 and rdeObj2:</t>
<sourcecode name="" type="xml" markers="false" pn="section-12-2">
<t>Example of a Differential Deposit with the two example objects rdeObj1 and rd &lt;?xml version="1.0" encoding="UTF-8"?&gt;
eObj2:</t> &lt;rde:deposit
<t>
<figure><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0" xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0" xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
type="DIFF" type="DIFF"
id="20191019001" prevId="20191018001"> id="20191019001" prevId="20191018001"&gt;
<rde:watermark>2019-10-18T23:59:59Z</rde:watermark> &lt;rde:watermark&gt;2019-10-18T23:59:59Z&lt;/rde:watermark&gt;
<rde:rdeMenu> &lt;rde:rdeMenu&gt;
<rde:version>1.0</rde:version> &lt;rde:version&gt;1.0&lt;/rde:version&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
</rde:rdeMenu> &lt;/rde:rdeMenu&gt;
<rde:contents> &lt;rde:contents&gt;
<rdeObj1:rdeObj1> &lt;rdeObj1:rdeObj1&gt;
<rdeObj1:name>EXAMPLE2</rdeObj1:name> &lt;rdeObj1:name&gt;EXAMPLE2&lt;/rdeObj1:name&gt;
</rdeObj1:rdeObj1> &lt;/rdeObj1:rdeObj1&gt;
<rdeObj2:rdeObj2> &lt;rdeObj2:rdeObj2&gt;
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id> &lt;rdeObj2:id&gt;sh8014-EXAMPLE&lt;/rdeObj2:id&gt;
</rdeObj2:rdeObj2> &lt;/rdeObj2:rdeObj2&gt;
</rde:contents> &lt;/rde:contents&gt;
</rde:deposit> &lt;/rde:deposit&gt;</sourcecode>
]]></artwork></figure> </section>
</t> <section numbered="true" toc="include" removeInRFC="false" pn="section-13">
<name slugifiedName="name-example-of-an-incremental-d">Example of an Incre
</section> mental Deposit</name>
<t indent="0" pn="section-13-1">Example of an Incremental Deposit with the
<section title="Example of a Incremental Deposit"> two example objects rdeObj1 and rdeObj2:</t>
<sourcecode name="" type="xml" markers="false" pn="section-13-2">
<t>Example of an Incremental Deposit with the two example objects rdeObj1 and rd &lt;?xml version="1.0" encoding="UTF-8"?&gt;
eObj2:</t> &lt;rde:deposit
<t>
<figure><artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<rde:deposit
xmlns:rde="urn:ietf:params:xml:ns:rde-1.0" xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0" xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0" xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
type="INCR" type="INCR"
id="20200317001" prevId="20200314001"> id="20200317001" prevId="20200314001"&gt;
<rde:watermark>2020-03-16T23:59:59Z</rde:watermark> &lt;rde:watermark&gt;2020-03-16T23:59:59Z&lt;/rde:watermark&gt;
<rde:rdeMenu> &lt;rde:rdeMenu&gt;
<rde:version>1.0</rde:version> &lt;rde:version&gt;1.0&lt;/rde:version&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
<rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI> &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
</rde:rdeMenu> &lt;/rde:rdeMenu&gt;
<rde:deletes> &lt;rde:deletes&gt;
<rdeObj1:delete> &lt;rdeObj1:delete&gt;
<rdeObj1:name>EXAMPLE1</rdeObj1:name> &lt;rdeObj1:name&gt;EXAMPLE1&lt;/rdeObj1:name&gt;
</rdeObj1:delete> &lt;/rdeObj1:delete&gt;
<rdeObj2:delete> &lt;rdeObj2:delete&gt;
<rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id> &lt;rdeObj2:id&gt;fsh8013-EXAMPLE&lt;/rdeObj2:id&gt;
</rdeObj2:delete> &lt;/rdeObj2:delete&gt;
</rde:deletes> &lt;/rde:deletes&gt;
<rde:contents> &lt;rde:contents&gt;
<rdeObj1:rdeObj1> &lt;rdeObj1:rdeObj1&gt;
<rdeObj1:name>EXAMPLE2</rdeObj1:name> &lt;rdeObj1:name&gt;EXAMPLE2&lt;/rdeObj1:name&gt;
</rdeObj1:rdeObj1> &lt;/rdeObj1:rdeObj1&gt;
<rdeObj2:rdeObj2> &lt;rdeObj2:rdeObj2&gt;
<rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id> &lt;rdeObj2:id&gt;sh8014-EXAMPLE&lt;/rdeObj2:id&gt;
</rdeObj2:rdeObj2> &lt;/rdeObj2:rdeObj2&gt;
</rde:contents> &lt;/rde:contents&gt;
</rde:deposit> &lt;/rde:deposit&gt;</sourcecode>
]]></artwork></figure> </section>
</t> </middle>
<back>
</section> <references pn="section-14">
<name slugifiedName="name-references">References</name>
</middle> <references pn="section-14.1">
<name slugifiedName="name-normative-references">Normative References</na
<back> me>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
<references title='Normative References'> 119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<?rfc include="reference.RFC.2119" ?> <title>Key words for use in RFCs to Indicate Requirement Levels</tit
<?rfc include="reference.RFC.3339" ?> le>
<?rfc include="reference.RFC.8174" ?> <author initials="S." surname="Bradner" fullname="S. Bradner">
<?rfc include="reference.RFC.8499" ?> <organization showOnFrontPage="true"/>
</author>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/200 <date year="1997" month="March"/>
8/REC-xml-20081126/"> <abstract>
<front> <t indent="0">In many standards track documents several words are
<title abbrev='Extensible Markup Language (XML) 1.0 (Fifth Edition) RE used to signify the requirements in the specification. These words are often ca
C-xml-20081126'>Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-200 pitalized. This document defines these words as they should be interpreted in IE
81126</title> TF documents. This document specifies an Internet Best Current Practices for th
<author initials="T." surname="Bray" fullname="Tim Bray" /> e Internet Community, and requests discussion and suggestions for improvements.<
<author initials="J." surname="Paoli" fullname="Jean Paoli" /> /t>
<author initials="C. M." surname="Sperberg-McQueen" fullname="C. M. </abstract>
Sperberg-McQueen" /> </front>
<author initials="E." surname="Maler" fullname="Eve Maler" /> <seriesInfo name="BCP" value="14"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau" <seriesInfo name="RFC" value="2119"/>
/> <seriesInfo name="DOI" value="10.17487/RFC2119"/>
<date year='2008' month='November' /> </reference>
<keyword>W3C.xml</keyword> <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3
</front> 339" quoteTitle="true" derivedAnchor="RFC3339">
</reference> <front>
<title>Date and Time on the Internet: Timestamps</title>
<reference anchor="W3C.REC-xmlschema-1-20041028" target="https://www.w3.or <author initials="G." surname="Klyne" fullname="G. Klyne">
g/TR/2004/REC-xmlschema-1-20041028/"> <organization showOnFrontPage="true"/>
<front> </author>
<title abbrev='XML Schema Part 1: Structures Second Edition REC-xmlsch <author initials="C." surname="Newman" fullname="C. Newman">
ema-1-20041028'>XML Schema Part 1: Structures Second Edition REC-xmlschema-1-200 <organization showOnFrontPage="true"/>
41028</title> </author>
<author initials="H. S." surname="Thompson" fullname="Henry S. Thompson <date year="2002" month="July"/>
" /> <abstract>
<author initials="D." surname="Beech" fullname="David Beech" /> <t indent="0">This document defines a date and time format for use
<author initials="M." surname="Maloney" fullname="Murray Maloney" / in Internet protocols that is a profile of the ISO 8601 standard for representa
> tion of dates and times using the Gregorian calendar.</t>
<author initials="N." surname="Mendelsohn" fullname="Noah Mendelsoh </abstract>
n" /> </front>
<date year='2004' month='October' /> <seriesInfo name="RFC" value="3339"/>
<keyword>W3C.xmlschema-1</keyword> <seriesInfo name="DOI" value="10.17487/RFC3339"/>
</front> </reference>
</reference> <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.or <front>
g/TR/2004/REC-xmlschema-2-20041028/"> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
<front> tle>
<title abbrev='XML Schema Part 2: Datatypes Second Edition REC-xmlsche <author initials="B." surname="Leiba" fullname="B. Leiba">
ma-2-20041028'>XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041 <organization showOnFrontPage="true"/>
028</title> </author>
<author initials="P. V." surname="Biron" fullname="Paul V. Biron" /> <date year="2017" month="May"/>
<author initials="A." surname="Malhotra" fullname="Ashok Malhotra" <abstract>
/> <t indent="0">RFC 2119 specifies common key words that may be used
<date year='2004' month='October' /> in protocol specifications. This document aims to reduce the ambiguity by cla
<keyword>W3C.xmlschema-2</keyword> rifying that only UPPERCASE usage of the key words have the defined special mea
</front> nings.</t>
</reference> </abstract>
</front>
</references> <seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<references title='Informative References'> <seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<?rfc include="reference.RFC.3688" ?> <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
<?rfc include="reference.RFC.7525" ?> 499" quoteTitle="true" derivedAnchor="RFC8499">
<?rfc include="reference.RFC.7942" ?> <front>
<title>DNS Terminology</title>
<reference anchor="ICANN-GTLD-RA-20170731" target="https://newgtlds.icann. <author initials="P." surname="Hoffman" fullname="P. Hoffman">
org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf"> <organization showOnFrontPage="true"/>
<front> </author>
<title>Base Registry Agreement 2017-07-31</title> <author initials="A." surname="Sullivan" fullname="A. Sullivan">
<author> <organization showOnFrontPage="true"/>
<organization>ICANN</organization> </author>
</author> <author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
<date day="31" month="July" year="2017" /> <organization showOnFrontPage="true"/>
</front> </author>
</reference> <date year="2019" month="January"/>
<abstract>
</references> <t indent="0">The Domain Name System (DNS) is defined in literally
dozens of different RFCs. The terminology used by implementers and developers
</back> of DNS protocols, and by operators of DNS systems, has sometimes changed in the
decades since the DNS was first defined. This document gives current definition
s for many of the terms used in the DNS in a single document.</t>
<t indent="0">This document obsoletes RFC 7719 and updates RFC 230
8.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="W3C.REC-xml-20081126" target="https://www.w3.org/TR/2
008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fifth Edition)</title>
<author initials="T." surname="Bray" fullname="Tim Bray" role="edito
r"/>
<author initials="J." surname="Paoli" fullname="Jean Paoli" role="ed
itor"/>
<author initials="C.M." surname="Sperberg-McQueen" fullname="C. M. S
perberg-McQueen" role="editor"/>
<author initials="E." surname="Maler" fullname="Eve Maler" role="edi
tor"/>
<author initials="F." surname="Yergeau" fullname="François Yergeau"
role="editor"/>
<date year="2008" month="November"/>
</front>
<refcontent>REC-xml-20081126</refcontent>
</reference>
<reference anchor="W3C.REC-xmlschema-1-20041028" target="https://www.w3.
org/TR/2004/REC-xmlschema-1-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-
xmlschema-1-20041028">
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials="H.S." surname="Thompson" fullname="Henry S. Thomps
on" role="editor"/>
<author initials="D." surname="Beech" fullname="David Beech" role="e
ditor"/>
<author initials="M." surname="Maloney" fullname="Murray Maloney" ro
le="editor"/>
<author initials="N." surname="Mendelsohn" fullname="Noah Mendelsoh
n" role="editor"/>
<date year="2004" month="October"/>
</front>
<refcontent>REC-xmlschema-1-20041028</refcontent>
</reference>
<reference anchor="W3C.REC-xmlschema-2-20041028" target="https://www.w3.
org/TR/2004/REC-xmlschema-2-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-
xmlschema-2-20041028">
<front>
<title>XML Schema Part 2: Datatypes Second Edition</title>
<author initials="P. V." surname="Biron" fullname="Paul V. Biron" ro
le="editor"/>
<author initials="A." surname="Malhotra" fullname="Ashok Malhotra" r
ole="editor"/>
<date year="2004" month="October"/>
</front>
<refcontent>REC-xmlschema-2-20041028</refcontent>
</reference>
</references>
<references pn="section-14.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="ICANN-GTLD-RA-20170731" target="https://newgtlds.ican
n.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf" quoteTit
le="true" derivedAnchor="ICANN-GTLD-RA-20170731">
<front>
<title>Base Registry Agreement</title>
<author>
<organization showOnFrontPage="true">ICANN</organization>
</author>
<date day="31" month="July" year="2017"/>
</front>
</reference>
<reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3
688" quoteTitle="true" derivedAnchor="RFC3688">
<front>
<title>The IETF XML Registry</title>
<author initials="M." surname="Mealling" fullname="M. Mealling">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="January"/>
<abstract>
<t indent="0">This document describes an IANA maintained registry
for IETF standards which use Extensible Markup Language (XML) related items such
as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Descrip
tion Framework (RDF) Schemas.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="81"/>
<seriesInfo name="RFC" value="3688"/>
<seriesInfo name="DOI" value="10.17487/RFC3688"/>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
525" quoteTitle="true" derivedAnchor="RFC7525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Holz" fullname="R. Holz">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="May"/>
<abstract>
<t indent="0">Transport Layer Security (TLS) and Datagram Transpor
t Layer Security (DTLS) are widely used to protect data exchanged over applicati
on protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few ye
ars, several serious attacks on TLS have emerged, including attacks on its most
commonly used cipher suites and their modes of operation. This document provide
s recommendations for improving the security of deployed services that use TLS a
nd DTLS. The recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
</reference>
</references>
</references>
<section numbered="false" toc="include" removeInRFC="false" pn="section-appe
ndix.a">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.a-1">
Special suggestions that were incorporated into this document
were provided by <contact fullname="James Gould"/>, <contact ful
lname="Edward Lewis"/>, <contact fullname="Jaap Akkerhuis"/>, <contact fullname=
"Lawrence Conroy"/>, <contact fullname="Marc Groeneweg"/>,
<contact fullname="Michael Young"/>, <contact fullname="Chris Wr
ight"/>, <contact fullname="Patrick Mevzek"/>, <contact fullname="Stephen Morris
"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Stephane Bortzme
yer"/>,
<contact fullname="Warren Kumari"/>, <contact fullname="Paul Hof
fman"/>, <contact fullname="Vika Mpisane"/>, <contact fullname="Bernie Hoeneisen
"/>, <contact fullname="Jim Galvin"/>, <contact fullname="Andrew Sullivan"/>, <c
ontact fullname="Hiro Hotta"/>,
<contact fullname="Christopher Browne"/>, <contact fullname="Dan
iel Kalchev"/>, <contact fullname="David Conrad"/>, <contact fullname="James Mit
chell"/>, <contact fullname="Francisco Obispo"/>, <contact fullname="Bhadresh Mo
di"/>, and
<contact fullname="Alexander Mayrhofer"/>.
</t>
<t indent="0" pn="section-appendix.a-2"> <contact fullname="S
hoji Noguchi"/> and <contact fullname="Francisco Arias"/> participated
as coauthors through version 07 of
draft-arias-noguchi-registry-data-escrow (the precursor to
this document) and provided invaluable support for this
document.</t>
</section>
<section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
="include" pn="section-appendix.b">
<name slugifiedName="name-authors-address">Author's Address</name>
<author initials="G." surname="Lozano" fullname="Gustavo Lozano">
<organization abbrev="ICANN" showOnFrontPage="true">Internet Corporation
for Assigned Names and Numbers</organization>
<address>
<postal>
<street>12025 Waterfront Drive, Suite 300</street>
<city>Los Angeles</city>
<region>CA</region>
<code>90292</code>
<country>United States of America</country>
</postal>
<phone>+1.310.823.9358</phone>
<email>gustavo.lozano@icann.org</email>
</address>
</author>
</section>
</back>
</rfc> </rfc>
 End of changes. 63 change blocks. 
1111 lines changed or deleted 1111 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/