<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>

<?rfc toc="yes"?>
<?rfc strict="yes"?>
<?rfc tocompact="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc tocdepth="2"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes" ?>
<?rfc sortrefs="yes" ?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-regext-data-escrow-10" indexInclude="true" ipr="trust200902" docName="draft-ietf-regext-data-escrow-10"> number="8909" prepTime="2020-11-13T16:10:15" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="2" tocInclude="true" xml:lang="en">
  <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"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Registry Data Escrow">

            Registry Escrow">Registry Data Escrow Specification

        </title> Specification</title>
    <seriesInfo name="RFC" value="8909" stream="IETF"/>
    <author initials="G." surname="Lozano" fullname="Gustavo Lozano">
      <organization abbrev="ICANN">
                Internet abbrev="ICANN" showOnFrontPage="true">Internet Corporation for Assigned Names and Numbers
            </organization> 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>
                    <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" month="11" year="2020"/>

        <area> Applications </area>
    <keyword>data escrow</keyword>
    <keyword>registry</keyword>

        <abstract>
            <t>This
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document specifies the format and contents of data escrow
       deposits targeted primarily for domain name registries.   The
       specification is designed to be independent of the underlying
       objects that are being escrowed escrowed, and therefore it could also be used for
       purposes other than domain name registries.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            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="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" 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" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="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 derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="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" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-conventions-used-in-this-do">Conventions Used in This Document</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" format="title" sectionFormat="of" target="name-date-and-time">Date and 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" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-description">Protocol Description</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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 derivedContent="" format="title" sectionFormat="of" target="name-rebuilding-the-registry-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" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-formal-syntax">Formal Syntax</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-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 derivedContent="" 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" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-internationalization-consid">Internationalization Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="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" format="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" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-a-full-deposit">Example 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" format="counter" sectionFormat="of" target="section-12"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-a-differential-d">Example 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" format="counter" sectionFormat="of" target="section-13"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-example-of-an-incremental-d">Example 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" format="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="section-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 derivedContent="" format="title" sectionFormat="of" target="name-normative-references">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 derivedContent="" format="title" sectionFormat="of" target="name-informative-references">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="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.16">
            <t indent="0" pn="section-toc.1-1.16.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section title="Introduction">

            <t> 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 periodically submits data
                deposits to a third-party third party called an escrow agent. These deposits comprise the
                minimum data needed by a third-party third party to resume operations if the registry
                cannot function and is unable or unwilling to facilitate an
                orderly transfer of service.
                For example, for a domain name registry or registrar, the data to be deposited
                would include all of the objects related to registered domain names, e.g.,
                names, contacts, name servers, etc. servers.
      </t>
            <t>
      <t indent="0" pn="section-1-2">
The goal of data escrow is higher resiliency of registration services, for the benefit of Internet users.  The beneficiaries of a registry are not just those registering information there, there but also the users of services relying on the registry data.

      </t>
            <t>
      <t indent="0" pn="section-1-3">
                In the context of domain name registries, registration data escrow is
                a requirement for generic top-level domains Top-Level Domains (gTLDs) (e.g.,
                Specification 2 of the ICANN Base Registry Agreement, Agreement; see
                <xref
              target='ICANN-GTLD-RA-20170731' />) target="ICANN-GTLD-RA-20170731" format="default" sectionFormat="of" derivedContent="ICANN-GTLD-RA-20170731"/>), and
                some country code top-level
                domain TLD (ccTLD)
                managers are also currently escrowing data.
                There is also a similar requirement for ICANN-accredited
                domain registrars.
      </t>
            <t>
      <t indent="0" pn="section-1-4">
                This document specifies a format for data escrow deposits independent of the objects being escrowed. An independent specification is required for each type of registry/set of objects that is expected to be escrowed.
      </t>

                <t>
      <t indent="0" pn="section-1-5">
                The format for data escrow deposits is specified using version
                1.0 of the Extensible Markup Language (XML) 1.0 as described in <xref target='W3C.REC-xml-20081126' /> target="W3C.REC-xml-20081126" format="default" sectionFormat="of" derivedContent="W3C.REC-xml-20081126"/>, and XML Schema notation as described in <xref target='W3C.REC-xmlschema-1-20041028' /> target="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-1-20041028"/> and <xref target='W3C.REC-xmlschema-2-20041028' />.
            </t>

            <t> target="W3C.REC-xmlschema-2-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-2-20041028"/>.
      </t>
      <t indent="0" pn="section-1-6">
            Readers are advised to read the terminology section <xref target="terms" format="default" sectionFormat="of" derivedContent="Section 2"/> ("Terminology") carefully to understand the precise meanings of Differential and Incremental Deposits Deposits, as the definitions used in this document are different from the definitions typically used in the domain of data backups.
      </t>
    </section>
    <section title="Terminology">

    <t>
      The anchor="terms" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP 14
       <xref target="RFC2119"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174"/> target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.
    </t>
            <t>
                Deposit.
                Deposits can be of here.</t>
      <dl newline="false" spacing="normal" indent="3" pn="section-2-2">
        <dt pn="section-2-2.1">Deposit:</dt>
        <dd pn="section-2-2.2">There are three kinds: kinds of deposits: Full, Differential or Differential, and
         Incremental. For all three kinds of deposits, the
                universe of registry objects to be considered for data escrow are those
                is comprised of any objects necessary in order required to offer the registry services.
            </t>
            <t> services.</dd>
        <dt pn="section-2-2.3">Differential Deposit:</dt>
        <dd pn="section-2-2.4">A Differential Deposit. Contains Deposit contains data that reflects all transactions involving the database
                that were not reflected in the last previous Full, Incremental Incremental, or Differential Deposit, as the case may
                be. Differential Deposit files will contain information from all database objects that were added,
                modified
                modified, or deleted since the previous deposit was completed as of its defined Timeline Watermark.
            </t>
            <t>
                Domain Name. See Watermark.</dd>
        <dt pn="section-2-2.5">Domain Name:</dt>
        <dd pn="section-2-2.6">See the definition of Domain name "domain name" in <xref target='RFC8499' />.
            </t>
            <t>
                Escrow Agent. The target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-2-2.7">Escrow Agent:</dt>
        <dd pn="section-2-2.8">An escrow agent is the organization designated by the registry or the third-party beneficiary to receive and
                guard data escrow deposits from the registry.
            </t>
            <t> registry.</dd>
        <dt pn="section-2-2.9">Full Deposit:</dt>
        <dd pn="section-2-2.10">A Full Deposit. Contains Deposit contains the registry data that reflects the current and complete registry
                database and will consist of data that reflects the state of the registry as of a defined
                Timeline Watermark for the deposit.
            </t>
            <t> deposit.</dd>
        <dt pn="section-2-2.11">Incremental Deposit:</dt>
        <dd pn="section-2-2.12">An Incremental Deposit. Contains Deposit contains data that reflects all transactions involving the database that were not
                reflected in the last previous Full Deposit. Incremental Deposit files will contain information from
                all database objects that were added, modified modified, or deleted since the previous Full Deposit was completed
                as of its defined Timeline Watermark. If the Timeline Watermark of an
 Incremental Deposit were to cover the Timeline Watermark of another
 Incremental or Differential Deposit since the last Full Deposit
 (i.e., one or more Incremental or Differential Deposits exist for
 the period between the Timeline Watermark of a Full Deposit and an
 Incremental or Differential Deposit) the Timeline Watermark of another Incremental or Differential Deposit since the last Full Deposit, Deposit), the more recent deposit MUST <bcp14>MUST</bcp14>
 contain all of the transactions of the earlier deposit.
            </t>
            <t>
                Registrar. See

</dd>
        <dt pn="section-2-2.13">Registrar:</dt>
        <dd pn="section-2-2.14">See the definition of Registrar "registrar" in <xref target='RFC8499' />.
            </t>
            <t>
                Registry. See target="RFC8499" format="default" sectionFormat="of" derivedContent="RFC8499"/>.</dd>
        <dt pn="section-2-2.15">Registry:</dt>
        <dd pn="section-2-2.16">See the definition of Registry "registry" in <xref target='RFC8499' />.
            </t>
            <t>
                Third-Party Beneficiary. Is 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 that, under extraordinary circumstances, would receive the
                escrow deposits the registry transferred to the escrow agent. This organization could be a backup
                registry, registry regulator, contracting party of the registry, etc.
            </t>
            <t> etc.</dd>
        <dt pn="section-2-2.19">Timeline Watermark:</dt>
        <dd pn="section-2-2.20">The Timeline Watermark. Point Watermark is the point in time on which to base the collecting of database objects for a deposit.
                Deposits are expected to be consistent to with that point in time.
            </t>
            <t>
                Top-Level Domain. See 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 (TLD) "Top-Level Domain" in <xref target='RFC8499' />.
            </t>

        </section>

        <section title="Problem Scope">

            <t> 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 space. spaces. Various organizations have carried out risk analyses and developed business continuity plans to
                deal with those risks, should they materialize.
      </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
                way to ensure the continuity of registry services in the extreme case of registry failure.
      </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
                anticipated that more registries will be implementing escrow escrow, especially with an increasing number of domain
                registries coming into service, adding complexity to this issue.
      </t>
            <t>
      <t indent="0" pn="section-3-4">
                It would seem beneficial to have a standardized specification for Registry Data Escrow that can be used
                by any registry to submit its deposits.
      </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.
      </t>
            <t>
      <t indent="0" pn="section-3-6">
                Specifications covering the objects used by registration organizations shall identify the format and contents of the deposits a
                registry has to make, such that a different registry would be able to rebuild the registration
                services of the former, without its help, in a timely manner, manner and with minimum disruption to its users.
      </t>
            <t>
      <t indent="0" pn="section-3-7">
                Since the details of the registration services provided vary from registry to registry, specifications covering the objects
                used by registration organizations shall provide mechanisms that allow its extensibility to accommodate variations and
                extensions of the registration services.
            </t>
            <t> services.</t>
      <t indent="0" pn="section-3-8">
                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 define confidentiality and integrity mechanisms for handling
                the registration data.
      </t>
            <t>
      <t indent="0" pn="section-3-9">
                Specifications covering the objects used by registration organizations shall not include in the specification
                transient objects that can be recreated by the new registry, particularly those of delicate confidentiality,
                e.g., DNSSEC KSK/ZSK (Key Signing Key / Zone Signing Key) private 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.
      </t>
            <t>
      <t indent="0" pn="section-3-11">
                Non-technical issues concerning data escrow, such as whether
                to escrow data and under which for what purposes the data may
                be used, are outside of the scope of this document.
      </t>
            <t>
      <t indent="0" pn="section-3-12">
            Parties using this specification shall use a signaling mechanism to control the transmission, reception reception, and validation of data escrow deposits. The definition of such a signaling mechanism is out of outside the scope of this document.
      </t>
    </section>
    <section title="Conventions numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This Document">

            <t> Document</name>
      <t indent="0" pn="section-4-1">
            The XML namespace prefix "rde" is used for the namespace
            "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT <bcp14>MUST NOT</bcp14> depend on it;
            instead, they should employ a proper namespace-aware XML parser
            and serializer to interpret and output the XML documents.
      </t>
            <t>
      <t indent="0" pn="section-4-2">
            The XML namespace prefix prefixes "rdeObj1" and "rdeObj2" "rdeObj2", with the corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and
            "urn:example:params:xml:ns:rdeObj2-1.0"
            "urn:example:params:xml:ns:rdeObj2-1.0", are used as example data escrow objects.
      </t>
      <section title="Date and Time">
                <t> numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-date-and-time">Date and Time</name>
        <t indent="0" pn="section-4.1-1">
                    Numerous fields indicate "dates", such as the creation and expiry
                    dates for objects.  These fields SHALL <bcp14>SHALL</bcp14> contain timestamps indicating
                    the date and time in UTC, specified in Internet Date/Time Format
                    (see <xref target="RFC3339"/>, Section 5.6) target="RFC3339" sectionFormat="comma" section="5.6" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3339#section-5.6" derivedContent="RFC3339"/>) with the time-offset parameter specified as "Z".
        </t>
      </section>
    </section>
    <section title="Protocol Description">

            <t>
                The following is a numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-protocol-description">Protocol Description</name>
      <t indent="0" pn="section-5-1">The format for data escrow deposits as produced by a
                registry. registry is
 defined below.  The deposits are represented in XML. XML (<xref target="formalSyntax" format="default" sectionFormat="of" derivedContent="Section 6"/>).
 Only the format of the objects deposited is defined. Nothing is prescribed about  This document
 does not prescribe the method used to transfer such deposits between
 the registry and the escrow agent or vice versa.
            </t>
            <t>
                The versa.</t>
      <t indent="0" pn="section-5-2">The protocol intends to be object agnostic agnostic, allowing the "overload"
 of abstract elements using the "substitutionGroup" attribute
 <xref target="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-1-20041028"/> of the XML Schema element to define
 the actual elements of an object to be escrowed.
            </t>

            <t> escrowed.</t>
      <t indent="0" pn="section-5-3">
               The specification for each object to be escrowed MUST <bcp14>MUST</bcp14> declare the identifier to be
               used to reference the object to be deleted or added/modified.
      </t>
      <section title="Root element &lt;deposit&gt;" anchor="root_element">
                <t> anchor="root_element" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <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 deposit is &lt;deposit&gt;.
        </t>

                <t>
        <t indent="0" pn="section-5.1-2">
                    The &lt;deposit&gt; element contains the following attributes:
        </t>

                <t>
                  <list style="symbols">
                  <t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-3">
          <li pn="section-5.1-3.1">
            <t indent="0" pn="section-5.1-3.1.1">
                     A REQUIRED &quot;type&quot; <bcp14>REQUIRED</bcp14> "type" attribute that is used to identify the kind of deposit:

                            <list style="symbols">
                            <t>

            </t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1-3.1.2">
              <li pn="section-5.1-3.1.2.1">
                                    FULL: Full.
                            </t>
                            <t>
                            </li>
              <li pn="section-5.1-3.1.2.2">
                                    INCR: Incremental.
                            </t>
                            <t>
                            </li>
              <li pn="section-5.1-3.1.2.3">
                                    DIFF: Differential.
                            </t>
                    		</list>
                        </t>
                        <t>
                            </li>
            </ul>
          </li>
          <li pn="section-5.1-3.2">
                            A REQUIRED &quot;id&quot; <bcp14>REQUIRED</bcp14> "id" attribute that is used to uniquely identify the escrow deposit.
                            Each registry is responsible for maintaining its own escrow deposits' identifier
                            space to ensure uniqueness.
                        </t>
                        <t>
                        </li>
          <li pn="section-5.1-3.3">
                            A &quot;prevId&quot; "prevId" attribute that can be used to identify the previous
                            Incremental, Differential Differential, or Full Deposit.  This attribute is REQUIRED <bcp14>REQUIRED</bcp14>
                            in Differential Deposits (&quot;DIFF&quot; ("DIFF" type), is OPTIONAL <bcp14>OPTIONAL</bcp14> in Incremental
                            Deposits (&quot;INCR&quot; ("INCR" type), and is not used in Full Deposits (&quot;FULL&quot; ("FULL"
                            type).

                        </t>
                        <!-- Review FA -->
                        <t>

                        </li>
          <li pn="section-5.1-3.4">
                            An OPTIONAL &quot;resend&quot; <bcp14>OPTIONAL</bcp14> "resend" attribute that is incremented
                            each time the escrow deposit failed the verification procedure at the receiving party
                            and a new escrow deposit needs to be generated by the registry for that specific date.
                            The first time a deposit is generated generated, the
                            attribute is either (1) is omitted or MUST (2) <bcp14>MUST</bcp14> be "0".
                            If a deposit needs to be generated again, the attribute MUST <bcp14>MUST</bcp14> be set to "1", and so on.
                        </t>
                        <!-- End Review FA -->
                    </list>
                </t>

                <t>
                        </li>
        </ul>
        <t indent="0" pn="section-5.1-4">
                        The &lt;deposit&gt; element contains the following the child elements:
        </t>
        <section title="Child anchor="watermark" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-child-watermark-element">Child &lt;watermark&gt; element" anchor="watermark">
                <t> Element</name>
          <t indent="0" pn="section-5.1.1-1">
                    A REQUIRED <bcp14>REQUIRED</bcp14> &lt;watermark&gt; element
                    contains the date-time <xref target="RFC3339" format="default" sectionFormat="of" derivedContent="RFC3339"/> corresponding to
                    the Timeline Watermark of the deposit.
                </t> deposit.</t>
        </section>
        <section title="Child anchor="rdeMenu" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-child-rdemenu-element">Child &lt;rdeMenu&gt; element" anchor="rdeMenu">
                <t> Element</name>
          <t indent="0" pn="section-5.1.2-1">
                    This element contains auxiliary information of regarding the data escrow deposit.
          </t>

                <t>
          <t indent="0" pn="section-5.1.2-2">
                    A REQUIRED <bcp14>REQUIRED</bcp14> &lt;rdeMenu&gt; element contains the following child elements:
          </t>
                <t>
                    <list style="symbols">
                        <t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-5.1.2-3">
            <li pn="section-5.1.2-3.1">
                            A REQUIRED <bcp14>REQUIRED</bcp14> &lt;version&gt; element that identifies the RDE protocol version, this version. This value MUST <bcp14>MUST</bcp14> be 1.0.
                        </t>
                        <t>
                        </li>
            <li pn="section-5.1.2-3.2">
                            One or more &lt;objURI&gt; elements that contain namespace URIs
                            representing the &lt;contents&gt; and &lt;deletes&gt; element objects.
                        </t>
                    </list>
                </t>
                        </li>
          </ul>
        </section>
        <section title="Child anchor="deletes" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-child-deletes-element">Child &lt;deletes&gt; element" anchor="deletes">
                <t>For Element</name>
          <t indent="0" pn="section-5.1.3-1">For Differential Deposits, this element contains the list of objects that have
    been deleted since the previous deposit of any type.  For Incremental
    Deposits, this element contains the list of objects that have been deleted
    since the previous Full Deposit.
          </t>
                <t>
          <t indent="0" pn="section-5.1.3-2">
                    This section of the deposit MUST NOT <bcp14>MUST NOT</bcp14> be present in Full Deposits.
          </t>
        </section>
        <section title="Child anchor="contents" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.4">
          <name slugifiedName="name-child-contents-element">Child &lt;contents&gt; element" anchor="contents">
                <t>For Element</name>
          <t indent="0" pn="section-5.1.4-1">For Full Deposits Deposits, this element contains all objects.  For Differential
    Deposits, this element contains the list of objects that have been added or
    modified since the previous deposit of any type.  For Incremental Deposits,
    this element contains the list of objects that have been added or modified
    since the previous Full Deposit.
          </t>
        </section>
      </section>
      <section title="Rebuilding anchor="rebuilding" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-rebuilding-the-registry-fro">Rebuilding the registry Registry from data escrow deposits" anchor="rebuilding">

                <t> Data Escrow Deposits</name>
        <t indent="0" pn="section-5.2-1">
                    When applying Incremental or Differential Deposits (when rebuilding
                    the registry from data escrow deposits), the relative order of the
                    &lt;deletes&gt; and &lt;contents&gt; elements is important because dependencies
                    may exist between the objects.  All of the &lt;deletes&gt; elements MUST <bcp14>MUST</bcp14> be applied
                    first, in the order that in which they appear.  All of the &lt;contents&gt; elements
                    MUST
                    <bcp14>MUST</bcp14> be applied next, in the order that in which
 they appear.
        </t>

                <t>
        <t indent="0" pn="section-5.2-2">
                    If an object is present in the &lt;contents&gt; or
                    &lt;deletes&gt; section of several deposits (e.g. (e.g., Full
                    and Differential) Differential), the registry data from the latest
                    deposit (as defined by the Timeline Watermark) SHOULD
                    <bcp14>SHOULD</bcp14> be used when rebuilding the
                    registry. An object SHOULD NOT <bcp14>SHOULD NOT</bcp14> exist
                    multiple times either in either the &lt;contents&gt; or
                    &lt;deletes&gt; elements in a single deposit.
                </t>

                <t>When deposit.</t>
        <t indent="0" pn="section-5.2-3">When rebuilding a
                    registry, the
                    &lt;deletes&gt; section MUST <bcp14>MUST</bcp14> be ignored if present in a Full Deposit.</t>
      </section>
    </section>
    <section title="Formal Syntax" anchor="formalSyntax">

		 <t>RDE anchor="formalSyntax" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-formal-syntax">Formal Syntax</name>
      <t indent="0" pn="section-6-1">RDE is specified in XML Schema notation.  The formal syntax presented
                        here is a complete schema representation of RDE suitable for
                        automated validation of RDE XML instances.</t>
		 <t>The BEGIN
      <t indent="0" pn="section-6-2">The &lt;CODE BEGINS&gt; and END &lt;CODE ENDS&gt; tags are not part of the schema; they are used to note
                        the beginning and ending of the schema for URI registration purposes.</t>
      <section title="RDE Schema">

                <t>
                    <figure><artwork><![CDATA[BEGIN
<?xml numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-rde-schema">RDE Schema</name>
        <sourcecode markers="true" name="" type="xml" pn="section-6.1-1">
&lt;?xml version="1.0" encoding="UTF-8"?>
<schema encoding="UTF-8"?&gt;
&lt;schema targetNamespace="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"
  elementFormDefault="qualified">

  <annotation>
    <documentation>
  elementFormDefault="qualified"&gt;

  &lt;annotation&gt;
    &lt;documentation&gt;
      Registry Data Escrow schema
    </documentation>
  </annotation>

  <!--
    &lt;/documentation&gt;
  &lt;/annotation&gt;

  &lt;!-- Root element -->
  <element --&gt;
  &lt;element name="deposit" type="rde:escrowDepositType"/>

  <!-- type="rde:escrowDepositType"/&gt;

  &lt;!-- RDE types -->
  <complexType name="escrowDepositType">
    <sequence>
      <element --&gt;
  &lt;complexType name="escrowDepositType"&gt;
    &lt;sequence&gt;
      &lt;element name="watermark" type="dateTime"/>
      <element type="dateTime"/&gt;
      &lt;element name="rdeMenu" type="rde:rdeMenuType"/>
      <element type="rde:rdeMenuType"/&gt;
      &lt;element name="deletes" type="rde:deletesType" minOccurs="0"/>
      <element minOccurs="0"/&gt;
      &lt;element name="contents" type="rde:contentsType" minOccurs="0"/>
    </sequence>
    <attribute
        minOccurs="0"/&gt;
    &lt;/sequence&gt;
    &lt;attribute name="type" type="rde:depositTypeType" use="required"/>
    <attribute
      use="required"/&gt;
    &lt;attribute name="id" type="rde:depositIdType" use="required"/>
    <attribute use="required"/&gt;
    &lt;attribute name="prevId" type="rde:depositIdType"/>
    <attribute type="rde:depositIdType"/&gt;
    &lt;attribute name="resend" type="unsignedShort" default="0"/>
  </complexType>

  <!-- default="0"/&gt;
  &lt;/complexType&gt;

  &lt;!-- Menu type -->
  <complexType name="rdeMenuType">
    <sequence>
      <element --&gt;
  &lt;complexType name="rdeMenuType"&gt;
    &lt;sequence&gt;
      &lt;element name="version" type="rde:versionType"/>
      <element type="rde:versionType"/&gt;
      &lt;element name="objURI" type="anyURI" maxOccurs="unbounded"/>
    </sequence>
  </complexType>

  <!-- maxOccurs="unbounded"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;

  &lt;!-- Deletes Type -->
  <complexType name="deletesType">
    <sequence type --&gt;
  &lt;complexType name="deletesType"&gt;
    &lt;sequence minOccurs="0" maxOccurs="unbounded">
      <element ref="rde:delete"/>
    </sequence>
  </complexType>

  <element maxOccurs="unbounded"&gt;
      &lt;element ref="rde:delete"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;

  &lt;element name="delete" type="rde:deleteType" abstract="true" />
  <complexType name="deleteType">
    <complexContent>
      <restriction base="anyType"/>
    </complexContent>
  </complexType>

  <!-- abstract="true"/&gt;
  &lt;complexType name="deleteType"&gt;
    &lt;complexContent&gt;
      &lt;restriction base="anyType"/&gt;
    &lt;/complexContent&gt;
  &lt;/complexType&gt;

  &lt;!-- Contents Type -->
  <complexType name="contentsType">
    <sequence type --&gt;
  &lt;complexType name="contentsType"&gt;
    &lt;sequence minOccurs="0" maxOccurs="unbounded">
      <element ref="rde:content"/>
    </sequence>
  </complexType>

  <element maxOccurs="unbounded"&gt;
      &lt;element ref="rde:content"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;

  &lt;element name="content" type="rde:contentType" abstract="true" />
  <complexType name="contentType">
    <complexContent>
      <restriction base="anyType"/>
    </complexContent>
  </complexType>

  <!-- abstract="true"/&gt;
  &lt;complexType name="contentType"&gt;
    &lt;complexContent&gt;
      &lt;restriction base="anyType"/&gt;
    &lt;/complexContent&gt;
  &lt;/complexType&gt;

  &lt;!-- Type of deposit -->
  <simpleType name="depositTypeType">
    <restriction base="token">
      <enumeration value="FULL"/>
      <enumeration value="INCR"/>
      <enumeration value="DIFF"/>
    </restriction>
  </simpleType>

  <!-- --&gt;
  &lt;simpleType name="depositTypeType"&gt;
    &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;

  &lt;!-- Deposit identifier type -->
  <simpleType name="depositIdType">
    <restriction base="token">
      <pattern value="\w{1,13}"/>
    </restriction>
  </simpleType>

  <!-- --&gt;
  &lt;simpleType name="depositIdType"&gt;
    &lt;restriction base="token"&gt;
      &lt;pattern value="\w{1,13}"/&gt;
    &lt;/restriction&gt;
  &lt;/simpleType&gt;

  &lt;!-- A RDE version number is a dotted pair of decimal numbers -->
  <simpleType name="versionType">
    <restriction base="token">
      <pattern value="[1-9]+\.[0-9]+"/>
      <enumeration value="1.0"/>
    </restriction>
  </simpleType>

</schema>
END]]></artwork></figure>
                </t> --&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;

&lt;/schema&gt;</sourcecode>
      </section>
    </section>
    <section title="Internationalization Considerations">
            <t> numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-internationalization-consid">Internationalization Considerations</name>
      <t indent="0" pn="section-7-1">
                Data escrow deposits are represented in XML, which provides native support for encoding information
                using the Unicode character set and its more compact representations representations, including UTF-8. Conformant XML
                processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other
                character encodings through the use of an "encoding" attribute
                in an &lt;?xml?&gt; declaration, the use of UTF-8
                is RECOMMENDED. <bcp14>RECOMMENDED</bcp14>.
      </t>
    </section>
    <section title="IANA Considerations">
            <t> numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">
                This document uses URNs to describe XML namespaces and XML schemas
                conforming to a registry mechanism described in <xref target="RFC3688"/>. target="RFC3688" format="default" sectionFormat="of" derivedContent="RFC3688"/>.
                Two URI assignments have been registered by the IANA.
      </t>

            <t>Registration request
      <t indent="0" pn="section-8-2">Registration for the RDE namespace:
                <list>
                    <t>URI: urn:ietf:params:xml:ns:rde-1.0</t>

          			<t>Registrant Contact: IESG &lt;regext@ietf.org&gt;</t>

          			<t>Note to RFC Editor: Please remove the email address from the RFC after IANA records it.</t>

                    <t>XML: None. namespace:</t>
      <dl newline="false" spacing="compact" indent="3" pn="section-8-3">
        <dt pn="section-8-3.1">URI:</dt>
        <dd pn="section-8-3.2">urn:ietf:params:xml:ns:rde-1.0</dd>
        <dt pn="section-8-3.3">Registrant Contact:</dt>
        <dd pn="section-8-3.4">IESG</dd>
        <dt pn="section-8-3.5">XML:</dt>
        <dd pn="section-8-3.6">None.  Namespace URIs do not represent an XML specification.</t>
                </list>
            </t>
            <t>Registration request specification.</dd>
      </dl>
      <t indent="0" pn="section-8-4">Registration for the RDE XML schema:
                <list>
                    <t>URI: urn:ietf:params:xml:schema:rde-1.0</t>

          			<t>Registrant Contact: IESG &lt;regext@ietf.org&gt;</t>

          			<t>Note to RFC Editor: Please remove the email address from the RFC after IANA records it.</t>

                    <t>See the &quot;Formal Syntax&quot; section
      </t>
      <dl newline="false" spacing="compact" indent="3" pn="section-8-5">
        <dt pn="section-8-5.1">URI:</dt>
        <dd pn="section-8-5.2">urn:ietf:params:xml:schema:rde-1.0</dd>
        <dt pn="section-8-5.3">Registrant Contact:</dt>
        <dd pn="section-8-5.4">IESG</dd>
      </dl>
      <t indent="0" pn="section-8-6">See <xref target="formalSyntax" format="default" sectionFormat="of" derivedContent="Section 6"/> ("Formal Syntax") of this document.</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> numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-9-1">
                This section records the status of known implementations of the protocol defined by this specification at does not define the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 <xref target="RFC7942"/>.  The description of implementations in this section is intended security mechanisms to assist the IETF in its decision processes be used in progressing drafts to RFCs.  Please note that the listing transmission of any individual implementation here does not imply endorsement by the IETF.  Furthermore, no effort has been spent to verify data escrow
                deposits, since it only specifies the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed minimum necessary to be, a catalog of available implementations or their features.  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 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".
            </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 Registries, 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.</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 implemented.</t>
                <t>Contact: gustavo.lozano@icann.org</t>
                <t>URL: https://www.icann.org/resources/pages/registries/registries-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
                deposits, since it only specifies the minimum necessary to enable the rebuilding enable the rebuilding of a registry from
                deposits without intervention from the original registry.
      </t>
            <t>
      <t indent="0" pn="section-9-2">
                Depending on local policies, some elements, elements -- or, most likely,
                the whole deposit -- will be considered confidential. As such, the parties SHOULD <bcp14>SHOULD</bcp14> take all the necessary precautions precautions, such as encrypting the data at rest and in transit to avoid inadvertent disclosure of private data. Regardless of the precautions taken by the parties regarding data at rest and in transit, authentication credentials MUST NOT <bcp14>MUST NOT</bcp14> be escrowed.
      </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
                escrow agent MUST <bcp14>MUST</bcp14> properly authenticate the identity of the registry before accepting data escrow
                deposits. In a similar manner, Similarly, the registry MUST <bcp14>MUST</bcp14> authenticate the identity of the escrow agent
                before submitting any data.
      </t>
            <t>
      <t indent="0" pn="section-9-4">
                Additionally, the registry and the escrow agent MUST
                <bcp14>MUST</bcp14> use integrity checking integrity-checking mechanisms to
                ensure that the
                data transmitted is what the source intended. Validation of the contents by the escrow agent is RECOMMENDED <bcp14>RECOMMENDED</bcp14>
                to ensure not only that the file was transmitted correctly from the registry, registry but also that the contents are
                &quot;meaningful&quot;.
                "meaningful".
      </t>
            <t>Note: if
      <aside pn="section-9-5">
        <t indent="0" pn="section-9-5.1">Note: If Transport Layer Security (TLS) is used when providing
      an escrow services, service, the recommendations in <xref target="RFC7525"/> MUST target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/> <bcp14>MUST</bcp14> be implemented.</t>
      </aside>
    </section>
    <section title="Privacy Considerations">
            <t> numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
      <t indent="0" pn="section-10-1">
This specification defines a format that may be used to escrow personal data.
The process of data escrow is governed by a legal document agreed upon by the
parties, and such a legal document must ensure that privacy-sensitive and/or personal data receives the required protection.
      </t>
    </section>
    <section title="Acknowledgments">
            <t>
                Special suggestions that have been incorporated into this document
                were provided by James Gould, Edward Lewis, Jaap Akkerhuis, Lawrence Conroy, Marc Groeneweg,
                Michael Young, Chris Wright, Patrick Mevzek, Stephen Morris, Scott Hollenbeck, Stephane Bortzmeyer,
                Warren Kumari, Paul Hoffman, Vika Mpisane, Bernie Hoeneisen, Jim Galvin, Andrew Sullivan, Hiro Hotta,
                Christopher Browne, Daniel Kalchev, David Conrad, James Mitchell, Francisco Obispo, Bhadresh Modi and
                Alexander Mayrhofer.
            </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 numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-example-of-a-full-deposit">Example of the basic &lt;domain&gt; element as defined in RFC 5910.</t>
                        <t>Included RGP elements as part a Full Deposit</name>
      <t indent="0" pn="section-11-1">Example of a Full Deposit with 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 subordinate objects, except &lt;watermarkDate&gt;.</t>
                        <t>Renamed &lt;watermarkDate&gt; to &lt;watermark&gt; two example objects rdeObj1 and 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; element.</t>
                        <t>Reversed the order rdeObj2:</t>
      <sourcecode name="" type="xml" markers="false" pn="section-11-2">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="FULL"
  id="20191018001"&gt;
  &lt;rde:watermark&gt;2019-10-17T23:59:59Z&lt;/rde:watermark&gt;
  &lt;rde:rdeMenu&gt;
    &lt;rde:version&gt;1.0&lt;/rde:version&gt;
    &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
    &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
  &lt;/rde:rdeMenu&gt;
  &lt;rde:contents&gt;
    &lt;rdeObj1:rdeObj1&gt;
      &lt;rdeObj1:name&gt;EXAMPLE&lt;/rdeObj1:name&gt;
    &lt;/rdeObj1:rdeObj1&gt;
    &lt;rdeObj2:rdeObj2&gt;
      &lt;rdeObj2:id&gt;fsh8013-EXAMPLE&lt;/rdeObj2:id&gt;
    &lt;/rdeObj2:rdeObj2&gt;
  &lt;/rde:contents&gt;
&lt;/rde:deposit&gt;</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-12">
      <name slugifiedName="name-example-of-a-differential-d">Example of a Differential Deposit</name>
      <t indent="0" pn="section-12-1">Example of a Differential Deposit with the &lt;deletes&gt; two example objects rdeObj1 and &lt;contents&gt; elements.</t>
                        <t>Removed &lt;rdeDomain:status&gt; minOccurs=&quot;0&quot;.</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; element.</t>
                        <t>Populated the &quot;Security Considerations&quot; section.</t>
                        <t>Populated the &quot;Internationalization Considerations&quot; section.</t>
                        <t>Populated the &quot;Extension Example&quot; section.</t>
                        <t>Added &lt;deDate&gt; element under &lt;domain&gt; element.</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 rdeObj2:</t>
      <sourcecode name="" type="xml" markers="false" pn="section-12-2">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="DIFF"
  id="20191019001" prevId="20191018001"&gt;
  &lt;rde:watermark&gt;2019-10-18T23:59:59Z&lt;/rde:watermark&gt;
  &lt;rde:rdeMenu&gt;
    &lt;rde:version&gt;1.0&lt;/rde:version&gt;
      &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
      &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
  &lt;/rde:rdeMenu&gt;
  &lt;rde:contents&gt;
    &lt;rdeObj1:rdeObj1&gt;
      &lt;rdeObj1:name&gt;EXAMPLE2&lt;/rdeObj1:name&gt;
    &lt;/rdeObj1:rdeObj1&gt;
    &lt;rdeObj2:rdeObj2&gt;
      &lt;rdeObj2:id&gt;sh8014-EXAMPLE&lt;/rdeObj2:id&gt;
    &lt;/rdeObj2:rdeObj2&gt;
  &lt;/rde:contents&gt;
&lt;/rde:deposit&gt;</sourcecode>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-13">
      <name slugifiedName="name-example-of-an-incremental-d">Example of an Incremental Deposit</name>
      <t indent="0" pn="section-13-1">Example of an Incremental Deposit with the two example objects rdeObj1 and omissions.</t>
                    </list>
                </t> rdeObj2:</t>
      <sourcecode name="" type="xml" markers="false" pn="section-13-2">
&lt;?xml version="1.0" encoding="UTF-8"?&gt;
&lt;rde:deposit
  xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
  xmlns:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="INCR"
  id="20200317001" prevId="20200314001"&gt;
  &lt;rde:watermark&gt;2020-03-16T23:59:59Z&lt;/rde:watermark&gt;
  &lt;rde:rdeMenu&gt;
    &lt;rde:version&gt;1.0&lt;/rde:version&gt;
    &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj1-1.0&lt;/rde:objURI&gt;
    &lt;rde:objURI&gt;urn:example:params:xml:ns:rdeObj2-1.0&lt;/rde:objURI&gt;
  &lt;/rde:rdeMenu&gt;
  &lt;rde:deletes&gt;
    &lt;rdeObj1:delete&gt;
      &lt;rdeObj1:name&gt;EXAMPLE1&lt;/rdeObj1:name&gt;
    &lt;/rdeObj1:delete&gt;
    &lt;rdeObj2:delete&gt;
      &lt;rdeObj2:id&gt;fsh8013-EXAMPLE&lt;/rdeObj2:id&gt;
    &lt;/rdeObj2:delete&gt;
  &lt;/rde:deletes&gt;
  &lt;rde:contents&gt;
    &lt;rdeObj1:rdeObj1&gt;
      &lt;rdeObj1:name&gt;EXAMPLE2&lt;/rdeObj1:name&gt;
    &lt;/rdeObj1:rdeObj1&gt;
    &lt;rdeObj2:rdeObj2&gt;
      &lt;rdeObj2:id&gt;sh8014-EXAMPLE&lt;/rdeObj2:id&gt;
    &lt;/rdeObj2:rdeObj2&gt;
  &lt;/rde:contents&gt;
&lt;/rde:deposit&gt;</sourcecode>
    </section>
            <section title="Changes from 01 to 02">
                <t>
                    <list style="numbers">
                        <t>Added definition
  </middle>
  <back>
    <references pn="section-14">
      <name slugifiedName="name-references">References</name>
      <references pn="section-14.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for "canonical" use in the "IDN variants Handling" section.</t>
                        <t>Clarified that "blocked" and "reserved" IDN variants RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are optional.</t>
                        <t>Made &lt;rdeRegistrar:authInfo&gt; optional.</t>
                        <t>Introduced substitutionGroup as used to signify the mechanism for extending requirements in the protocol.</t>
                        <t>Moved &lt;eppParams&gt; element to specification.  These words are often capitalized. This document defines these words as they should be child of &lt;contents&gt;.</t>
                        <t>Text improvements interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Introduction, Terminology, and Problem Scope per Jay's suggestion.</t>
                        <t>Removed &lt;trDate&gt; from &lt;rdeDomain&gt; Internet Community, and added &lt;trnData&gt; instead, which
                            include all the data from the last (pending/processed) transfer request.</t>
                        <t>Removed &lt;trDate&gt; from &lt;rdeContact&gt; requests discussion and added &lt;trnData&gt; instead, which
                            include all the data from suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3339" target="https://www.rfc-editor.org/info/rfc3339" quoteTitle="true" derivedAnchor="RFC3339">
          <front>
            <title>Date and Time on the last (pending/processed) transfer request.</t>
                        <t>Fixed some typographical errors Internet: Timestamps</title>
            <author initials="G." surname="Klyne" fullname="G. Klyne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Newman" fullname="C. Newman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="July"/>
            <abstract>
              <t indent="0">This document defines a date 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 time format for use in Internet protocols that is a profile of &lt;deletes&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;rdeIDN&gt; elements.</t>
                        <t>Modified the definition ISO 8601 standard for representation of &lt;rde:id&gt; and &lt;rde:prevId&gt;.</t>
                        <t>Added &lt;rdeMenu&gt; element under &lt;deposit&gt; element.</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; section.</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 dates 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 the language normative.</t>
                        <t>Updated the rde XML schema to remove the dependency with the eppcom namespace reference.</t>
                        <t>Editorial updates.</t>
                        <t>Remove times using the reference to RFC 5730.</t>
                        <t>Added complete examples Gregorian calendar.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3339"/>
          <seriesInfo name="DOI" value="10.17487/RFC3339"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity 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 SHOULD, Uppercase vs Lowercase in order to accommodate an Incremental or Differential Deposit that only includes 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 References 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 own sections.</t>
                   		<t>&lt;deposit&gt; elements definition moved to section 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 RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that version MUST may 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 used 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 protocol  specifications.  This document aims to REGEXT 09">
                <t>
                    <list style="numbers">
                        <t>Changes based on reduce the feedback provided here: https://mailarchive.ietf.org/arch/msg/regext/x_8twvi-MS4dDDRfAZfNJH92UaQ</t>
                        <t>Changes based on ambiguity by clarifying that only UPPERCASE usage of 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 key words have 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  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8499" quoteTitle="true" derivedAnchor="RFC8499">
          <front>
            <title>DNS Terminology</title>
            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Sullivan" fullname="A. Sullivan">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="January"/>
            <abstract>
              <t indent="0">The Domain Name System (DNS) is defined in literally dozens of a Full Deposit with the two example objects rdeObj1 different RFCs.  The terminology used by implementers 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:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="FULL"
  id="20191018001">
  <rde:watermark>2019-10-17T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
    <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
    <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>
]]></artwork></figure>
</t>

</section>

<section title="Example of a Differential Deposit">

<t>Example developers of a Differential Deposit with the two example objects rdeObj1 DNS protocols, 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:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="DIFF"
  id="20191019001" prevId="20191018001">
  <rde:watermark>2019-10-18T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
      <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
      <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE2</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>
]]></artwork></figure>
</t>

</section>

<section title="Example by operators of a Incremental Deposit">

<t>Example DNS systems, has sometimes changed in the decades since the DNS was first defined.  This document gives current definitions for many of an Incremental Deposit with the two example objects rdeObj1 terms used in the DNS in a single document.</t>
              <t indent="0">This document obsoletes RFC 7719 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:rdeObj1="urn:example:params:xml:ns:rdeObj1-1.0"
  xmlns:rdeObj2="urn:example:params:xml:ns:rdeObj2-1.0"
  type="INCR"
  id="20200317001" prevId="20200314001">
  <rde:watermark>2020-03-16T23:59:59Z</rde:watermark>
  <rde:rdeMenu>
    <rde:version>1.0</rde:version>
    <rde:objURI>urn:example:params:xml:ns:rdeObj1-1.0</rde:objURI>
    <rde:objURI>urn:example:params:xml:ns:rdeObj2-1.0</rde:objURI>
  </rde:rdeMenu>
  <rde:deletes>
    <rdeObj1:delete>
      <rdeObj1:name>EXAMPLE1</rdeObj1:name>
    </rdeObj1:delete>
    <rdeObj2:delete>
      <rdeObj2:id>fsh8013-EXAMPLE</rdeObj2:id>
    </rdeObj2:delete>
  </rde:deletes>
  <rde:contents>
    <rdeObj1:rdeObj1>
      <rdeObj1:name>EXAMPLE2</rdeObj1:name>
    </rdeObj1:rdeObj1>
    <rdeObj2:rdeObj2>
      <rdeObj2:id>sh8014-EXAMPLE</rdeObj2:id>
    </rdeObj2:rdeObj2>
  </rde:contents>
</rde:deposit>
]]></artwork></figure>
</t>

</section>

    </middle>

    <back>

        <references title='Normative References'>

            <?rfc include="reference.RFC.2119" ?>
            <?rfc include="reference.RFC.3339" ?>
            <?rfc include="reference.RFC.8174" ?>
            <?rfc include="reference.RFC.8499" ?> updates RFC 2308.</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/2008/REC-xml-20081126/"> target="https://www.w3.org/TR/2008/REC-xml-20081126/" quoteTitle="true" derivedAnchor="W3C.REC-xml-20081126">
          <front>
          <title abbrev='Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126'>Extensible
            <title>Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126</title> Edition)</title>
            <author initials="T." surname="Bray" fullname="Tim Bray" /> role="editor"/>
            <author initials="J." surname="Paoli" fullname="Jean Paoli" /> role="editor"/>
            <author initials="C. M." initials="C.M." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen" /> role="editor"/>
            <author initials="E." surname="Maler" fullname="Eve Maler" /> role="editor"/>
            <author initials="F." surname="Yergeau" fullname="François  Yergeau" /> role="editor"/>
            <date year='2008' month='November' />
          <keyword>W3C.xml</keyword> 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/"> target="https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema-1-20041028">
          <front>
          <title abbrev='XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028'>XML
            <title>XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028</title> Edition</title>
            <author initials="H. S." initials="H.S." surname="Thompson" fullname="Henry S. Thompson" /> role="editor"/>
            <author initials="D." surname="Beech" fullname="David Beech" /> role="editor"/>
            <author initials="M." surname="Maloney" fullname="Murray Maloney" /> role="editor"/>
            <author initials="N." surname="Mendelsohn" fullname="Noah  Mendelsohn" /> role="editor"/>
            <date year='2004' month='October' />
          <keyword>W3C.xmlschema-1</keyword> 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/"> target="https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/" quoteTitle="true" derivedAnchor="W3C.REC-xmlschema-2-20041028">
          <front>
          <title abbrev='XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028'>XML
            <title>XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028</title> Edition</title>
            <author initials="P. V." surname="Biron" fullname="Paul V. Biron" /> role="editor"/>
            <author initials="A." surname="Malhotra" fullname="Ashok Malhotra" /> role="editor"/>
            <date year='2004' month='October' />
          <keyword>W3C.xmlschema-2</keyword> year="2004" month="October"/>
          </front>
          <refcontent>REC-xmlschema-2-20041028</refcontent>
        </reference>
      </references>
      <references title='Informative References'>

            <?rfc include="reference.RFC.3688" ?>
            <?rfc include="reference.RFC.7525" ?>
            <?rfc include="reference.RFC.7942" ?> pn="section-14.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="ICANN-GTLD-RA-20170731" target="https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf"> target="https://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf" quoteTitle="true" derivedAnchor="ICANN-GTLD-RA-20170731">
          <front>
            <title>Base Registry Agreement 2017-07-31</title> Agreement</title>
            <author>
            <organization>ICANN</organization>
              <organization showOnFrontPage="true">ICANN</organization>
            </author>
            <date day="31" month="July" year="2017" /> year="2017"/>
          </front>
        </reference>
        <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688" 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 Description 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/rfc7525" quoteTitle="true" derivedAnchor="RFC7525">
          <front>
            <title>Recommendations for Secure Use of Transport Layer Security (TLS) 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 Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation.  This document provides recommendations for improving the security of deployed services that use TLS and 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-appendix.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 fullname="Edward Lewis"/>, <contact fullname="Jaap Akkerhuis"/>, <contact fullname="Lawrence Conroy"/>, <contact fullname="Marc Groeneweg"/>,
                <contact fullname="Michael Young"/>, <contact fullname="Chris Wright"/>, <contact fullname="Patrick Mevzek"/>, <contact fullname="Stephen Morris"/>, <contact fullname="Scott Hollenbeck"/>, <contact fullname="Stephane Bortzmeyer"/>,
                <contact fullname="Warren Kumari"/>, <contact fullname="Paul Hoffman"/>, <contact fullname="Vika Mpisane"/>, <contact fullname="Bernie Hoeneisen"/>, <contact fullname="Jim Galvin"/>, <contact fullname="Andrew Sullivan"/>, <contact fullname="Hiro Hotta"/>,
                <contact fullname="Christopher Browne"/>, <contact fullname="Daniel Kalchev"/>, <contact fullname="David Conrad"/>, <contact fullname="James Mitchell"/>, <contact fullname="Francisco Obispo"/>, <contact fullname="Bhadresh Modi"/>, and
                <contact fullname="Alexander Mayrhofer"/>.
      </t>
      <t indent="0" pn="section-appendix.a-2">              <contact fullname="Shoji 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>