doc: Add RFC documents

1 files changed, 713 insertions, 0 deletions

diff --git a/doc/rfc/rfc8909.txt b/doc/rfc/rfc8909.txt
new file mode 100644
index 0000000..8acafa8
--- /dev/null
+++ b/doc/rfc/rfc8909.txt
@@ -0,0 +1,713 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         G. Lozano
+Request for Comments: 8909                                         ICANN
+Category: Standards Track                                  November 2020
+ISSN: 2070-1721
+
+
+                   Registry Data Escrow Specification
+
+Abstract
+
+   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.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8909.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) 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.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+   3.  Problem Scope
+   4.  Conventions Used in This Document
+     4.1.  Date and Time
+   5.  Protocol Description
+     5.1.  Root Element <deposit>
+     5.2.  Rebuilding the Registry from Data Escrow Deposits
+   6.  Formal Syntax
+     6.1.  RDE Schema
+   7.  Internationalization Considerations
+   8.  IANA Considerations
+   9.  Security Considerations
+   10. Privacy Considerations
+   11. Example of a Full Deposit
+   12. Example of a Differential Deposit
+   13. Example of an Incremental Deposit
+   14. References
+     14.1.  Normative References
+     14.2.  Informative References
+   Acknowledgments
+   Author's Address
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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
+   [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.
+
+   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.
+
+   The format for data escrow deposits is specified using version 1.0 of
+   the Extensible Markup Language (XML) as described in
+   [W3C.REC-xml-20081126], and XML Schema notation as described in
+   [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
+
+   Readers are advised to read 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.
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   Deposit:  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.
+
+   Differential Deposit:  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.
+
+   Domain Name:  See the definition of "domain name" in [RFC8499].
+
+   Escrow Agent:  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.
+
+   Full Deposit:  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.
+
+   Incremental Deposit:  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 MUST contain all of the transactions of the earlier
+      deposit.
+
+   Registrar:  See the definition of "registrar" in [RFC8499].
+
+   Registry:  See the definition of "registry" in [RFC8499].
+
+   Third-Party Beneficiary:  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.
+
+   Timeline Watermark:  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.
+
+   Top-Level Domain (TLD):  See the definition of "Top-Level Domain" in
+      [RFC8499].
+
+3.  Problem Scope
+
+   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.
+
+   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.
+
+   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.
+
+   It would seem beneficial to have a standardized specification for
+   Registry Data Escrow that can be used by any registry to submit its
+   deposits.
+
+   While the domain name industry has been the main target for this
+   specification, it has been designed to be as general as possible.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   Details that are a matter of policy should be identified as such for
+   the benefit of the implementers.
+
+   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.
+
+   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.
+
+4.  Conventions Used in This Document
+
+   The XML namespace prefix "rde" is used for the namespace
+   "urn:ietf:params:xml:ns:rde-1.0", but implementations MUST NOT depend
+   on it; instead, they should employ a proper namespace-aware XML
+   parser and serializer to interpret and output the XML documents.
+
+   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.
+
+4.1.  Date and Time
+
+   Numerous fields indicate "dates", such as the creation and expiry
+   dates for objects.  These fields SHALL contain timestamps indicating
+   the date and time in UTC, specified in Internet Date/Time Format (see
+   [RFC3339], Section 5.6) with the time-offset parameter specified as
+   "Z".
+
+5.  Protocol Description
+
+   The format for data escrow deposits as produced by a registry is
+   defined below.  The deposits are represented in XML (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.
+
+   The protocol intends to be object agnostic, allowing the "overload"
+   of abstract elements using the "substitutionGroup" attribute
+   [W3C.REC-xmlschema-1-20041028] of the XML Schema element to define
+   the actual elements of an object to be escrowed.
+
+   The specification for each object to be escrowed MUST declare the
+   identifier to be used to reference the object to be deleted or added/
+   modified.
+
+5.1.  Root Element <deposit>
+
+   The container or root element for a Registry Data Escrow deposit is
+   <deposit>.
+
+   The <deposit> element contains the following attributes:
+
+   *  A REQUIRED "type" attribute that is used to identify the kind of
+      deposit:
+
+      -  FULL: Full.
+
+      -  INCR: Incremental.
+
+      -  DIFF: Differential.
+
+   *  A REQUIRED "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.
+
+   *  A "prevId" attribute that can be used to identify the previous
+      Incremental, Differential, or Full Deposit.  This attribute is
+      REQUIRED in Differential Deposits ("DIFF" type), is OPTIONAL in
+      Incremental Deposits ("INCR" type), and is not used in Full
+      Deposits ("FULL" type).
+
+   *  An OPTIONAL "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) MUST be "0".
+      If a deposit needs to be generated again, the attribute MUST be
+      set to "1", and so on.
+
+   The <deposit> element contains the following child elements:
+
+5.1.1.  Child <watermark> Element
+
+   A REQUIRED <watermark> element contains the date-time [RFC3339]
+   corresponding to the Timeline Watermark of the deposit.
+
+5.1.2.  Child <rdeMenu> Element
+
+   This element contains auxiliary information regarding the data escrow
+   deposit.
+
+   A REQUIRED <rdeMenu> element contains the following child elements:
+
+   *  A REQUIRED <version> element that identifies the RDE protocol
+      version.  This value MUST be 1.0.
+
+   *  One or more <objURI> elements that contain namespace URIs
+      representing the <contents> and <deletes> element objects.
+
+5.1.3.  Child <deletes> Element
+
+   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.
+
+   This section of the deposit MUST NOT be present in Full Deposits.
+
+5.1.4.  Child <contents> Element
+
+   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.
+
+5.2.  Rebuilding the Registry from Data Escrow Deposits
+
+   When applying Incremental or Differential Deposits (when rebuilding
+   the registry from data escrow deposits), the relative order of the
+   <deletes> and <contents> elements is important because dependencies
+   may exist between the objects.  All of the <deletes> elements MUST be
+   applied first, in the order in which they appear.  All of the
+   <contents> elements MUST be applied next, in the order in which they
+   appear.
+
+   If an object is present in the <contents> or <deletes> section of
+   several deposits (e.g., Full and Differential), the registry data
+   from the latest deposit (as defined by the Timeline Watermark) SHOULD
+   be used when rebuilding the registry.  An object SHOULD NOT exist
+   multiple times in either the <contents> or <deletes> elements in a
+   single deposit.
+
+   When rebuilding a registry, the <deletes> section MUST be ignored if
+   present in a Full Deposit.
+
+6.  Formal Syntax
+
+   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.
+
+   The <CODE BEGINS> and <CODE ENDS> tags are not part of the schema;
+   they are used to note the beginning and ending of the schema for URI
+   registration purposes.
+
+6.1.  RDE Schema
+
+   <CODE BEGINS>
+   <?xml version="1.0" encoding="UTF-8"?>
+   <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>
+         Registry Data Escrow schema
+       </documentation>
+     </annotation>
+
+     <!-- Root element -->
+     <element name="deposit" type="rde:escrowDepositType"/>
+
+     <!-- RDE types -->
+     <complexType name="escrowDepositType">
+       <sequence>
+         <element name="watermark" type="dateTime"/>
+         <element name="rdeMenu" type="rde:rdeMenuType"/>
+         <element name="deletes" type="rde:deletesType" minOccurs="0"/>
+         <element name="contents" type="rde:contentsType"
+           minOccurs="0"/>
+       </sequence>
+       <attribute name="type" type="rde:depositTypeType"
+         use="required"/>
+       <attribute name="id" type="rde:depositIdType" use="required"/>
+       <attribute name="prevId" type="rde:depositIdType"/>
+       <attribute name="resend" type="unsignedShort" default="0"/>
+     </complexType>
+
+     <!-- Menu type -->
+     <complexType name="rdeMenuType">
+       <sequence>
+         <element name="version" type="rde:versionType"/>
+         <element name="objURI" type="anyURI" maxOccurs="unbounded"/>
+       </sequence>
+     </complexType>
+
+     <!-- Deletes type -->
+     <complexType name="deletesType">
+       <sequence minOccurs="0" maxOccurs="unbounded">
+         <element ref="rde:delete"/>
+       </sequence>
+     </complexType>
+
+     <element name="delete" type="rde:deleteType" abstract="true"/>
+     <complexType name="deleteType">
+       <complexContent>
+         <restriction base="anyType"/>
+       </complexContent>
+     </complexType>
+
+     <!-- Contents type -->
+     <complexType name="contentsType">
+       <sequence minOccurs="0" maxOccurs="unbounded">
+         <element ref="rde:content"/>
+       </sequence>
+     </complexType>
+
+     <element name="content" type="rde:contentType" abstract="true"/>
+     <complexType name="contentType">
+       <complexContent>
+         <restriction base="anyType"/>
+       </complexContent>
+     </complexType>
+
+     <!-- Type of deposit -->
+     <simpleType name="depositTypeType">
+       <restriction base="token">
+         <enumeration value="FULL"/>
+         <enumeration value="INCR"/>
+         <enumeration value="DIFF"/>
+       </restriction>
+     </simpleType>
+
+     <!-- Deposit identifier type -->
+     <simpleType name="depositIdType">
+       <restriction base="token">
+         <pattern value="\w{1,13}"/>
+       </restriction>
+     </simpleType>
+
+     <!-- 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>
+   <CODE ENDS>
+
+7.  Internationalization Considerations
+
+   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 <?xml?> declaration, the use of
+   UTF-8 is RECOMMENDED.
+
+8.  IANA Considerations
+
+   This document uses URNs to describe XML namespaces and XML schemas
+   conforming to a registry mechanism described in [RFC3688].  Two URI
+   assignments have been registered by the IANA.
+
+   Registration for the RDE namespace:
+
+   URI:  urn:ietf:params:xml:ns:rde-1.0
+   Registrant Contact:  IESG
+   XML:  None.  Namespace URIs do not represent an XML specification.
+
+   Registration for the RDE XML schema:
+
+   URI:  urn:ietf:params:xml:schema:rde-1.0
+   Registrant Contact:  IESG
+
+   See Section 6 ("Formal Syntax") of this document.
+
+9.  Security Considerations
+
+   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.
+
+   Depending on local policies, some elements -- or, most likely, the
+   whole deposit -- will be considered confidential.  As such, the
+   parties SHOULD 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
+   MUST NOT be escrowed.
+
+   Authentication of the parties passing data escrow deposit files is
+   also of the utmost importance.  The escrow agent MUST properly
+   authenticate the identity of the registry before accepting data
+   escrow deposits.  Similarly, the registry MUST authenticate the
+   identity of the escrow agent before submitting any data.
+
+   Additionally, the registry and the escrow agent MUST use integrity-
+   checking mechanisms to ensure that the data transmitted is what the
+   source intended.  Validation of the contents by the escrow agent is
+   RECOMMENDED to ensure not only that the file was transmitted
+   correctly from the registry but also that the contents are
+   "meaningful".
+
+      |  Note: If Transport Layer Security (TLS) is used when providing
+      |  an escrow service, the recommendations in [RFC7525] MUST be
+      |  implemented.
+
+10.  Privacy Considerations
+
+   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.
+
+11.  Example of a Full Deposit
+
+   Example of a Full Deposit with the two example objects rdeObj1 and
+   rdeObj2:
+
+   <?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>
+
+12.  Example of a Differential Deposit
+
+   Example of a Differential Deposit with the two example objects
+   rdeObj1 and rdeObj2:
+
+   <?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>
+
+13.  Example of an Incremental Deposit
+
+   Example of an Incremental Deposit with the two example objects
+   rdeObj1 and rdeObj2:
+
+   <?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>
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
+              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
+              <https://www.rfc-editor.org/info/rfc3339>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8499]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
+              Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
+              January 2019, <https://www.rfc-editor.org/info/rfc8499>.
+
+   [W3C.REC-xml-20081126]
+              Bray, T., Ed., Paoli, J., Ed., Sperberg-McQueen, C.M.,
+              Ed., Maler, E., Ed., and F. Yergeau, Ed., "Extensible
+              Markup Language (XML) 1.0 (Fifth Edition)", REC-xml-
+              20081126, November 2008,
+              <https://www.w3.org/TR/2008/REC-xml-20081126/>.
+
+   [W3C.REC-xmlschema-1-20041028]
+              Thompson, H.S., Ed., Beech, D., Ed., Maloney, M., Ed., and
+              N. Mendelsohn, Ed., "XML Schema Part 1: Structures Second
+              Edition", REC-xmlschema-1-20041028, October 2004,
+              <https://www.w3.org/TR/2004/REC-xmlschema-1-20041028/>.
+
+   [W3C.REC-xmlschema-2-20041028]
+              Biron, P. V., Ed. and A. Malhotra, Ed., "XML Schema Part
+              2: Datatypes Second Edition", REC-xmlschema-2-20041028,
+              October 2004,
+              <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
+
+14.2.  Informative References
+
+   [ICANN-GTLD-RA-20170731]
+              ICANN, "Base Registry Agreement", 31 July 2017,
+              <https://newgtlds.icann.org/sites/default/files/
+              agreements/agreement-approved-31jul17-en.pdf>.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
+              "Recommendations for Secure Use of Transport Layer
+              Security (TLS) and Datagram Transport Layer Security
+              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
+              2015, <https://www.rfc-editor.org/info/rfc7525>.
+
+Acknowledgments
+
+   Special suggestions that were 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.
+
+   Shoji Noguchi and 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.
+
+Author's Address
+
+   Gustavo Lozano
+   Internet Corporation for Assigned Names and Numbers
+   12025 Waterfront Drive, Suite 300
+   Los Angeles, CA 90292
+   United States of America
+
+   Phone: +1.310.823.9358
+   Email: gustavo.lozano@icann.org