<?xml 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" 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 Data Escrow Specification</title>
    <seriesInfo name="RFC" value="8909" stream="IETF"/>
    <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>
    <date month="11" year="2020"/>
    <keyword>data escrow</keyword>
    <keyword>registry</keyword>
    <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, 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 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 called an escrow agent. These deposits comprise the 
                minimum data needed by a third party to resume operations if the registry 
                cannot function and is unable or unwilling to facilitate an  
                orderly transfer of service.  
                For example, for a domain name registry or registrar, the data to be deposited
                would include all of the objects related to registered domain names, e.g.,
                names, contacts, name servers.
      </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 but also the users of services relying on the registry data.
                    
      </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 (gTLDs) (e.g.,
                Specification 2 of the ICANN Base Registry Agreement; see
                <xref target="ICANN-GTLD-RA-20170731" format="default" sectionFormat="of" derivedContent="ICANN-GTLD-RA-20170731"/>), and
                some country code TLD (ccTLD)
                managers are also currently escrowing data. 
                There is also a similar requirement for ICANN-accredited 
                domain registrars.            
      </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 indent="0" pn="section-1-5">
                The format for data escrow deposits is specified using version
                1.0 of the Extensible Markup Language (XML) as described in <xref 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" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-1-20041028"/> and <xref 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 <xref target="terms" format="default" sectionFormat="of" derivedContent="Section 2"/> ("Terminology") carefully to understand the precise meanings of Differential and Incremental Deposits, as the definitions used in this document are different from the definitions typically used in the domain of data backups.
      </t>
    </section>
    <section 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 "<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 "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14
       <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only
       when, they appear in all capitals, as shown 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 of deposits: Full, Differential, and
         Incremental. For all three kinds of deposits, the 
                universe of registry objects to be considered for data escrow
                is comprised of any objects required to offer the registry services.</dd>
        <dt pn="section-2-2.3">Differential Deposit:</dt>
        <dd pn="section-2-2.4">A Differential Deposit contains data that reflects 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, 
                modified, or deleted since the previous deposit was completed as of its defined Timeline Watermark.</dd>
        <dt pn="section-2-2.5">Domain Name:</dt>
        <dd pn="section-2-2.6">See the definition of "domain name" in <xref 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.</dd>
        <dt pn="section-2-2.9">Full Deposit:</dt>
        <dd pn="section-2-2.10">A Full 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.</dd>
        <dt pn="section-2-2.11">Incremental Deposit:</dt>
        <dd pn="section-2-2.12">An Incremental 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, 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 more recent deposit <bcp14>MUST</bcp14>
 contain all of the transactions of the earlier deposit.

</dd>
        <dt pn="section-2-2.13">Registrar:</dt>
        <dd pn="section-2-2.14">See the definition of "registrar" in <xref 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" 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 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.</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 which 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 <xref 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 analyses and developed business continuity plans to 
                deal with those risks, should they materialize.
      </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 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, especially with an increasing number of domain
                registries coming into service, adding complexity to this issue.
      </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 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 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 and with minimum disruption to its users.
      </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 extensibility to accommodate variations and
                extensions of the registration 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 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 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 indent="0" pn="section-3-11">
                Non-technical issues concerning data escrow, such as whether
                to escrow data and for what purposes the data may
                be used, are outside the scope of this document.
      </t>
      <t indent="0" pn="section-3-12">
            Parties using this specification shall use a signaling mechanism to control the transmission, reception, and validation of data escrow deposits. The definition of such a signaling mechanism is outside the scope of this document.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in This 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 <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 indent="0" pn="section-4-2">
            The XML namespace prefixes "rdeObj1" and "rdeObj2", with the corresponding namespaces "urn:example:params:xml:ns:rdeObj1-1.0" and
            "urn:example:params:xml:ns:rdeObj2-1.0", are used as example data escrow objects.
      </t>
      <section 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 <bcp14>SHALL</bcp14> contain timestamps indicating
                    the date and time in UTC, specified in Internet Date/Time Format
                    (see <xref 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 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 is
 defined below.  The deposits are represented in XML (<xref target="formalSyntax" format="default" sectionFormat="of" derivedContent="Section 6"/>).
 Only the format of the objects deposited is defined.  This document
 does not prescribe the method used to transfer such deposits between
 the registry and the escrow agent or vice versa.</t>
      <t indent="0" pn="section-5-2">The protocol intends to be object 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 indent="0" pn="section-5-3">
               The specification for each object to be escrowed <bcp14>MUST</bcp14> declare the identifier to be
               used to reference the object to be deleted or added/modified.
      </t>
      <section 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 indent="0" pn="section-5.1-2">
                    The &lt;deposit&gt; element contains the following attributes:
        </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 <bcp14>REQUIRED</bcp14> "type" attribute that is used to identify the kind of deposit:
                   
            </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.
                            </li>
              <li pn="section-5.1-3.1.2.2">
                                    INCR: Incremental.
                            </li>
              <li pn="section-5.1-3.1.2.3">
                                    DIFF: Differential.
                            </li>
            </ul>
          </li>
          <li pn="section-5.1-3.2">
                            A <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.
                        </li>
          <li pn="section-5.1-3.3">
                            A "prevId" attribute that can be used to identify the previous 
                            Incremental, Differential, or Full Deposit.  This attribute is <bcp14>REQUIRED</bcp14>
                            in Differential Deposits ("DIFF" type), is <bcp14>OPTIONAL</bcp14> in Incremental
                            Deposits ("INCR" type), and is not used in Full Deposits ("FULL"
                            type).

                        </li>
          <li pn="section-5.1-3.4">
                            An <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, the
                            attribute either (1) is omitted or (2) <bcp14>MUST</bcp14> be "0".  
                            If a deposit needs to be generated again, the attribute <bcp14>MUST</bcp14> be set to "1", and so on.
                        </li>
        </ul>
        <t indent="0" pn="section-5.1-4">
                        The &lt;deposit&gt; element contains the following child elements:
        </t>
        <section anchor="watermark" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.1">
          <name slugifiedName="name-child-watermark-element">Child &lt;watermark&gt; Element</name>
          <t indent="0" pn="section-5.1.1-1">
                    A <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>
        </section>
        <section anchor="rdeMenu" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.2">
          <name slugifiedName="name-child-rdemenu-element">Child &lt;rdeMenu&gt; Element</name>
          <t indent="0" pn="section-5.1.2-1">
                    This element contains auxiliary information regarding the data escrow deposit.
          </t>
          <t indent="0" pn="section-5.1.2-2">
                    A <bcp14>REQUIRED</bcp14> &lt;rdeMenu&gt; element contains the following child elements:
          </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 <bcp14>REQUIRED</bcp14> &lt;version&gt; element that identifies the RDE protocol version. This value <bcp14>MUST</bcp14> be 1.0.
                        </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.
                        </li>
          </ul>
        </section>
        <section anchor="deletes" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.3">
          <name slugifiedName="name-child-deletes-element">Child &lt;deletes&gt; 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 indent="0" pn="section-5.1.3-2">
                    This section of the deposit <bcp14>MUST NOT</bcp14> be present in Full Deposits. 
          </t>
        </section>
        <section anchor="contents" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.4">
          <name slugifiedName="name-child-contents-element">Child &lt;contents&gt; Element</name>
          <t indent="0" pn="section-5.1.4-1">For Full 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 anchor="rebuilding" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-rebuilding-the-registry-fro">Rebuilding the Registry from 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 <bcp14>MUST</bcp14> be applied
                    first, in the order in which they appear.  All of the &lt;contents&gt; elements
                    <bcp14>MUST</bcp14> be applied next, in the order in which
 they appear.
        </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., Full
                    and Differential), the registry data from the latest
                    deposit (as defined by the Timeline Watermark)
                    <bcp14>SHOULD</bcp14> be used when rebuilding the
                    registry. An object <bcp14>SHOULD NOT</bcp14> exist
                    multiple times in either the &lt;contents&gt; or
                    &lt;deletes&gt; elements in a single deposit.</t>
        <t indent="0" pn="section-5.2-3">When rebuilding a 
                    registry, the
                    &lt;deletes&gt; section <bcp14>MUST</bcp14> be ignored if present in a Full Deposit.</t>
      </section>
    </section>
    <section 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 indent="0" pn="section-6-2">The &lt;CODE BEGINS&gt; and &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 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"?&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"&gt;

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

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

  &lt;!-- RDE types --&gt;
  &lt;complexType name="escrowDepositType"&gt;
    &lt;sequence&gt;
      &lt;element name="watermark" type="dateTime"/&gt;
      &lt;element name="rdeMenu" type="rde:rdeMenuType"/&gt;
      &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;

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

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

  &lt;element name="delete" type="rde:deleteType" 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 --&gt;
  &lt;complexType name="contentsType"&gt;
    &lt;sequence minOccurs="0" maxOccurs="unbounded"&gt;
      &lt;element ref="rde:content"/&gt;
    &lt;/sequence&gt;
  &lt;/complexType&gt;

  &lt;element name="content" type="rde:contentType" 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 --&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 --&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 --&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 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, 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 <bcp14>RECOMMENDED</bcp14>.
      </t>
    </section>
    <section 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" format="default" sectionFormat="of" derivedContent="RFC3688"/>.
                Two URI assignments have been registered by the IANA.
      </t>
      <t indent="0" pn="section-8-2">Registration for the RDE 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.</dd>
      </dl>
      <t indent="0" pn="section-8-4">Registration for the RDE XML schema:
      </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>
    </section>
    <section 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 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 of a registry from 
                deposits without intervention from the original registry.
      </t>
      <t indent="0" pn="section-9-2">
                Depending on local policies, some elements -- or, most likely,
                the whole deposit -- will be considered confidential. As such, the parties <bcp14>SHOULD</bcp14> take all necessary precautions, such as encrypting the data at rest and in transit to avoid inadvertent disclosure of private data. Regardless of the precautions taken by the parties regarding data at rest and in transit, authentication credentials <bcp14>MUST NOT</bcp14> be escrowed.
      </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 <bcp14>MUST</bcp14> properly authenticate the identity of the registry before accepting data escrow
                deposits. Similarly, the registry <bcp14>MUST</bcp14> authenticate the identity of the escrow agent
                before submitting any data.
      </t>
      <t indent="0" pn="section-9-4">
                Additionally, the registry and the escrow agent
                <bcp14>MUST</bcp14> use integrity-checking mechanisms to
                ensure that the
                data transmitted is what the source intended. Validation of the contents by the escrow agent is <bcp14>RECOMMENDED</bcp14>
                to ensure not only that the file was transmitted correctly from the registry but also that the contents are 
                "meaningful".
      </t>
      <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 service, the recommendations in <xref target="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/> <bcp14>MUST</bcp14> be implemented.</t>
      </aside>
    </section>
    <section 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 numbered="true" toc="include" removeInRFC="false" pn="section-11">
      <name slugifiedName="name-example-of-a-full-deposit">Example of a Full Deposit</name>
      <t indent="0" pn="section-11-1">Example of a Full Deposit with the two example objects rdeObj1 and 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 two example objects rdeObj1 and 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 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>
  </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 use in 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 used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and 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 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 time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the 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 Uppercase vs Lowercase in 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 may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  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 different RFCs.  The terminology used by implementers and developers 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 definitions 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 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/" 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="editor"/>
            <author initials="J." surname="Paoli" fullname="Jean Paoli" role="editor"/>
            <author 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"/>
          </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. 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"/>
          </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" role="editor"/>
            <author initials="A." surname="Malhotra" fullname="Ashok Malhotra" role="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.icann.org/sites/default/files/agreements/agreement-approved-31jul17-en.pdf" quoteTitle="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/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>