<?xmlversion="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 DataEscrow"> RegistryEscrow">Registry Data EscrowSpecification </title>Specification</title> <seriesInfo name="RFC" value="8909" stream="IETF"/> <author initials="G." surname="Lozano" fullname="Gustavo Lozano"> <organizationabbrev="ICANN"> Internetabbrev="ICANN" showOnFrontPage="true">Internet Corporation for Assigned Names andNumbers </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> <dateday="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 beingescrowedescrowed, 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 <deposit></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> <sectiontitle="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 athird-partythird party called an escrow agent. These deposits comprise the minimum data needed by athird-partythird 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, nameservers, 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 informationthere,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 generictop-level domainsTop-Level Domains (gTLDs) (e.g., Specification 2 of the ICANN Base RegistryAgreement,Agreement; see <xreftarget='ICANN-GTLD-RA-20170731' />)target="ICANN-GTLD-RA-20170731" format="default" sectionFormat="of" derivedContent="ICANN-GTLD-RA-20170731"/>), and some country codetop-level domainTLD (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.0as described in <xreftarget='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 <xreftarget='W3C.REC-xmlschema-1-20041028' />target="W3C.REC-xmlschema-1-20041028" format="default" sectionFormat="of" derivedContent="W3C.REC-xmlschema-1-20041028"/> and <xreftarget='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 readthe terminology section<xref target="terms" format="default" sectionFormat="of" derivedContent="Section 2"/> ("Terminology") carefully to understand the precise meanings of Differential and IncrementalDepositsDeposits, as the definitions used in this document are different from the definitions typically used in the domain of data backups. </t> </section> <sectiontitle="Terminology"> <t> Theanchor="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 inBCP 14BCP 14 <xreftarget="RFC2119"/>target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xreftarget="RFC8174"/>target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as shownhere. </t> <t> Deposit. Deposits can be ofhere.</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 threekinds:kinds of deposits: Full,Differential orDifferential, and Incremental. For all three kinds of deposits, the universe of registry objects to be considered for data escroware thoseis comprised of any objectsnecessary in orderrequired to offer the registryservices. </t> <t>services.</dd> <dt pn="section-2-2.3">Differential Deposit:</dt> <dd pn="section-2-2.4">A DifferentialDeposit. ContainsDeposit contains data that reflects all transactions involving the database that were not reflected in the last previous Full,IncrementalIncremental, or Differential Deposit, as the case may be. Differential Deposit files will contain information from all database objects that were added,modifiedmodified, or deleted since the previous deposit was completed as of its defined TimelineWatermark. </t> <t> Domain Name. SeeWatermark.</dd> <dt pn="section-2-2.5">Domain Name:</dt> <dd pn="section-2-2.6">See the definition ofDomain name"domain name" in <xreftarget='RFC8499' />. </t> <t> Escrow Agent. Thetarget="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 theregistry. </t> <t>registry.</dd> <dt pn="section-2-2.9">Full Deposit:</dt> <dd pn="section-2-2.10">A FullDeposit. ContainsDeposit 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 thedeposit. </t> <t>deposit.</dd> <dt pn="section-2-2.11">Incremental Deposit:</dt> <dd pn="section-2-2.12">An IncrementalDeposit. ContainsDeposit 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,modifiedmodified, 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 DifferentialDeposit) the Timeline Watermark of another Incremental or Differential Deposit since the last Full Deposit,Deposit), the more recent depositMUST<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 ofRegistrar"registrar" in <xreftarget='RFC8499' />. </t> <t> Registry. Seetarget="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 ofRegistry"registry" in <xreftarget='RFC8499' />. </t> <t> Third-Party Beneficiary. Istarget="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 TimelineWatermark. PointWatermark is the point in time on which to base the collecting of database objects for a deposit. Deposits are expected to be consistenttowith that point intime. </t> <t> Top-Level Domain. Seetime.</dd> <dt pn="section-2-2.21">Top-Level Domain (TLD):</dt> <dd pn="section-2-2.22">See the definition ofTop-Level Domain (TLD)"Top-Level Domain" in <xreftarget='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 ccTLDspace.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 implementingescrowescrow, 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 timelymanner,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 allowitsextensibility to accommodate variations and extensions of the registrationservices. </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 andunder whichfor what purposes the data may be used, are outsideofthe 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,receptionreception, and validation of data escrow deposits. The definition of such a signaling mechanism isout ofoutside the scope of this document. </t> </section> <sectiontitle="Conventionsnumbered="true" toc="include" removeInRFC="false" pn="section-4"> <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in ThisDocument"> <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 implementationsMUST 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 namespaceprefixprefixes "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> <sectiontitle="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 fieldsSHALL<bcp14>SHALL</bcp14> contain timestamps indicating the date and time in UTC, specified in Internet Date/Time Format (see <xreftarget="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> <sectiontitle="Protocol Description"> <t> The following is anumbered="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 aregistry.registry is defined below. The deposits are represented inXML.XML (<xref target="formalSyntax" format="default" sectionFormat="of" derivedContent="Section 6"/>). Only the format of the objects deposited is defined.Nothing is prescribed aboutThis document does not prescribe the method used to transfer such deposits between the registry and the escrow agent or viceversa. </t> <t> Theversa.</t> <t indent="0" pn="section-5-2">The protocol intends to be objectagnosticagnostic, 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 beescrowed. </t> <t>escrowed.</t> <t indent="0" pn="section-5-3"> The specification for each object to be escrowedMUST<bcp14>MUST</bcp14> declare the identifier to be used to reference the object to be deleted or added/modified. </t> <sectiontitle="Root element <deposit>" 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 <deposit></name> <t indent="0" pn="section-5.1-1"> The container or root element for a Registry Data Escrow deposit is <deposit>. </t><t><t indent="0" pn="section-5.1-2"> The <deposit> 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"> AREQUIRED "type"<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"> AREQUIRED "id"<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"prevId""prevId" attribute that can be used to identify the previous Incremental,DifferentialDifferential, or Full Deposit. This attribute isREQUIRED<bcp14>REQUIRED</bcp14> in Differential Deposits("DIFF"("DIFF" type), isOPTIONAL<bcp14>OPTIONAL</bcp14> in Incremental Deposits("INCR"("INCR" type), and is not used in Full Deposits("FULL"("FULL" type).</t> <!-- Review FA --> <t></li> <li pn="section-5.1-3.4"> AnOPTIONAL "resend"<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 isgeneratedgenerated, the attributeiseither (1) is omitted orMUST(2) <bcp14>MUST</bcp14> be "0". If a deposit needs to be generated again, the attributeMUST<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 <deposit> element contains the followingthechild elements: </t> <sectiontitle="Childanchor="watermark" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.1"> <name slugifiedName="name-child-watermark-element">Child <watermark>element" anchor="watermark"> <t>Element</name> <t indent="0" pn="section-5.1.1-1"> AREQUIRED<bcp14>REQUIRED</bcp14> <watermark> element contains the date-time <xref target="RFC3339" format="default" sectionFormat="of" derivedContent="RFC3339"/> corresponding to the Timeline Watermark of thedeposit. </t>deposit.</t> </section> <sectiontitle="Childanchor="rdeMenu" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.2"> <name slugifiedName="name-child-rdemenu-element">Child <rdeMenu>element" anchor="rdeMenu"> <t>Element</name> <t indent="0" pn="section-5.1.2-1"> This element contains auxiliary informationofregarding the data escrow deposit. </t><t><t indent="0" pn="section-5.1.2-2"> AREQUIRED<bcp14>REQUIRED</bcp14> <rdeMenu> 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"> AREQUIRED<bcp14>REQUIRED</bcp14> <version> element that identifies the RDE protocolversion, thisversion. This valueMUST<bcp14>MUST</bcp14> be 1.0.</t> <t></li> <li pn="section-5.1.2-3.2"> One or more <objURI> elements that contain namespace URIs representing the <contents> and <deletes> element objects.</t> </list> </t></li> </ul> </section> <sectiontitle="Childanchor="deletes" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.3"> <name slugifiedName="name-child-deletes-element">Child <deletes>element" anchor="deletes"> <t>ForElement</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 depositMUST NOT<bcp14>MUST NOT</bcp14> be present in Full Deposits. </t> </section> <sectiontitle="Childanchor="contents" numbered="true" toc="exclude" removeInRFC="false" pn="section-5.1.4"> <name slugifiedName="name-child-contents-element">Child <contents>element" anchor="contents"> <t>ForElement</name> <t indent="0" pn="section-5.1.4-1">For FullDepositsDeposits, 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> <sectiontitle="Rebuildinganchor="rebuilding" numbered="true" toc="include" removeInRFC="false" pn="section-5.2"> <name slugifiedName="name-rebuilding-the-registry-fro">Rebuilding theregistryRegistry fromdata 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 <deletes> and <contents> elements is important because dependencies may exist between the objects. All of the <deletes> elementsMUST<bcp14>MUST</bcp14> be applied first, in the orderthatin which they appear. All of the <contents> elementsMUST<bcp14>MUST</bcp14> be applied next, in the orderthatin which they appear. </t><t><t indent="0" pn="section-5.2-2"> If an object is present in the <contents> or <deletes> section of several deposits(e.g.(e.g., Full andDifferential)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 objectSHOULD NOT<bcp14>SHOULD NOT</bcp14> exist multiple timeseitherin either the <contents> or <deletes> elements in a singledeposit. </t> <t>Whendeposit.</t> <t indent="0" pn="section-5.2-3">When rebuilding a registry, the <deletes> sectionMUST<bcp14>MUST</bcp14> be ignored if present in a Full Deposit.</t> </section> </section> <sectiontitle="Formal Syntax" anchor="formalSyntax"> <t>RDEanchor="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 <CODE BEGINS> andEND<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.</t> <sectiontitle="RDE Schema"> <t> <figure><artwork><![CDATA[BEGIN <?xmlnumbered="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"> <?xml version="1.0"encoding="UTF-8"?> <schemaencoding="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>elementFormDefault="qualified"> <annotation> <documentation> Registry Data Escrow schema</documentation> </annotation> <!--</documentation> </annotation> <!-- Root element--> <element--> <element name="deposit"type="rde:escrowDepositType"/> <!--type="rde:escrowDepositType"/> <!-- RDE types--> <complexType name="escrowDepositType"> <sequence> <element--> <complexType name="escrowDepositType"> <sequence> <element name="watermark"type="dateTime"/> <elementtype="dateTime"/> <element name="rdeMenu"type="rde:rdeMenuType"/> <elementtype="rde:rdeMenuType"/> <element name="deletes" type="rde:deletesType"minOccurs="0"/> <elementminOccurs="0"/> <element name="contents" type="rde:contentsType"minOccurs="0"/> </sequence> <attributeminOccurs="0"/> </sequence> <attribute name="type" type="rde:depositTypeType"use="required"/> <attributeuse="required"/> <attribute name="id" type="rde:depositIdType"use="required"/> <attributeuse="required"/> <attribute name="prevId"type="rde:depositIdType"/> <attributetype="rde:depositIdType"/> <attribute name="resend" type="unsignedShort"default="0"/> </complexType> <!--default="0"/> </complexType> <!-- Menu type--> <complexType name="rdeMenuType"> <sequence> <element--> <complexType name="rdeMenuType"> <sequence> <element name="version"type="rde:versionType"/> <elementtype="rde:versionType"/> <element name="objURI" type="anyURI"maxOccurs="unbounded"/> </sequence> </complexType> <!--maxOccurs="unbounded"/> </sequence> </complexType> <!-- DeletesType --> <complexType name="deletesType"> <sequencetype --> <complexType name="deletesType"> <sequence minOccurs="0"maxOccurs="unbounded"> <element ref="rde:delete"/> </sequence> </complexType> <elementmaxOccurs="unbounded"> <element ref="rde:delete"/> </sequence> </complexType> <element name="delete" type="rde:deleteType"abstract="true" /> <complexType name="deleteType"> <complexContent> <restriction base="anyType"/> </complexContent> </complexType> <!--abstract="true"/> <complexType name="deleteType"> <complexContent> <restriction base="anyType"/> </complexContent> </complexType> <!-- ContentsType --> <complexType name="contentsType"> <sequencetype --> <complexType name="contentsType"> <sequence minOccurs="0"maxOccurs="unbounded"> <element ref="rde:content"/> </sequence> </complexType> <elementmaxOccurs="unbounded"> <element ref="rde:content"/> </sequence> </complexType> <element name="content" type="rde:contentType"abstract="true" /> <complexType name="contentType"> <complexContent> <restriction base="anyType"/> </complexContent> </complexType> <!--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> <!----> <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> <!----> <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> END]]></artwork></figure> </t>--> <simpleType name="versionType"> <restriction base="token"> <pattern value="[1-9]+\.[0-9]+"/> <enumeration value="1.0"/> </restriction> </simpleType> </schema></sourcecode> </section> </section> <sectiontitle="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 compactrepresentationsrepresentations, 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 isRECOMMENDED.<bcp14>RECOMMENDED</bcp14>. </t> </section> <sectiontitle="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 <xreftarget="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 RDEnamespace: <list> <t>URI: urn:ietf:params:xml:ns:rde-1.0</t> <t>Registrant Contact: IESG <regext@ietf.org></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 XMLspecification.</t> </list> </t> <t>Registration requestspecification.</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 <regext@ietf.org></t> <t>Note to RFC Editor: Please remove the email address from the RFC after IANA records it.</t> <t>See the "Formal Syntax" 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> <sectionanchor="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"> Thissection records the status of known implementations of the protocol defined by thisspecificationatdoes not define thetime 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 intendedsecurity mechanisms toassist the IETF in its decision processesbe used inprogressing drafts to RFCs. Please note thatthelistingtransmission ofany individual implementation here does not imply endorsement bytheIETF. Furthermore, no effort has been spent to verifydata escrow deposits, since it only specifies theinformation presented here that was supplied by IETF contributors. This is not intended as, and must not be construedminimum necessary tobe, 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 rebuildingenable 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, someelements,elements -- or, most likely, the whole deposit -- will be considered confidential. As such, the partiesSHOULD<bcp14>SHOULD</bcp14> take allthenecessaryprecautionsprecautions, 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 credentialsMUST 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 agentMUST<bcp14>MUST</bcp14> properly authenticate the identity of the registry before accepting data escrow deposits.In a similar manner,Similarly, the registryMUST<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 agentMUST<bcp14>MUST</bcp14> useintegrity checkingintegrity-checking mechanisms to ensure that the data transmitted is what the source intended. Validation of the contents by the escrow agent isRECOMMENDED<bcp14>RECOMMENDED</bcp14> to ensure not only that the file was transmitted correctly from theregistry,registry but also that the contents are"meaningful"."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 escrowservices,service, the recommendations in <xreftarget="RFC7525"/> MUSTtarget="RFC7525" format="default" sectionFormat="of" derivedContent="RFC7525"/> <bcp14>MUST</bcp14> be implemented.</t> </aside> </section> <sectiontitle="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> <sectiontitle="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 partnumbered="true" toc="include" removeInRFC="false" pn="section-11"> <name slugifiedName="name-example-of-a-full-deposit">Example ofthe basic <domain> element as defined in RFC 5910.</t> <t>Included RGP elements as parta Full Deposit</name> <t indent="0" pn="section-11-1">Example of a Full Deposit with thebasic <domain> element as defined in RFC 3915.</t> <t>Added support for IDNs and IDN variants.</t> <t>Eliminated the <summary> element and all its subordinate objects, except <watermarkDate>.</t> <t>Renamed <watermarkDate> to <watermark>two example objects rdeObj1 andincluded it directly under root element.</t> <t>Renamed root element to <deposit>.</t> <t>Added <authinfo> element under <registrar> element.</t> <t>Added <roid> element under <registrar> element.</t> <t>Reversed the orderrdeObj2:</t> <sourcecode name="" type="xml" markers="false" pn="section-11-2"> <?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></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<deletes>two example objects rdeObj1 and<contents> elements.</t> <t>Removed <rdeDomain:status> minOccurs="0".</t> <t>Added <extension> element under root element.</t> <t>Added <extension> element under <contact> element.</t> <t>Removed <period> element from <domain> element.</t> <t>Populated the "Security Considerations" section.</t> <t>Populated the "Internationalization Considerations" section.</t> <t>Populated the "Extension Example" section.</t> <t>Added <deDate> element under <domain> element.</t> <t>Added <icannID> element under <registrar> element.</t> <t>Added <eppParams> element under root element.</t> <t>Fixed some typographical errorsrdeObj2:</t> <sourcecode name="" type="xml" markers="false" pn="section-12-2"> <?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></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 andomissions.</t> </list> </t>rdeObj2:</t> <sourcecode name="" type="xml" markers="false" pn="section-13-2"> <?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></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 inthe "IDN variants Handling" section.</t> <t>Clarified that "blocked" and "reserved" IDN variantsRFCs 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 areoptional.</t> <t>Made <rdeRegistrar:authInfo> optional.</t> <t>Introduced substitutionGroup asused to signify themechanism for extendingrequirements in theprotocol.</t> <t>Moved <eppParams> element tospecification. These words are often capitalized. This document defines these words as they should bechild of <contents>.</t> <t>Text improvementsinterpreted in IETF documents. This document specifies an Internet Best Current Practices for theIntroduction, Terminology, and Problem Scope per Jay's suggestion.</t> <t>Removed <trDate> from <rdeDomain>Internet Community, andadded <trnData> instead, which include all the data from the last (pending/processed) transfer request.</t> <t>Removed <trDate> from <rdeContact>requests discussion andadded <trnData> instead, which include all the data fromsuggestions 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 thelast (pending/processed) transfer request.</t> <t>Fixed some typographical errorsInternet: 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 andomissions.</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 <extension> elements to be childtime format for use in Internet protocols that is a profile of<deletes> and <contents>, additionally removed <extension> element from <rdeDomain>,<rdeHost>, <rdeContact>,<rdeRegistrar> and <rdeIDN> elements.</t> <t>ModifiedthedefinitionISO 8601 standard for representation of<rde:id> and <rde:prevId>.</t> <t>Added <rdeMenu> element under <deposit> 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 <eppParams> objects.</t> <t>Populated the "Extension Guidelines" 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 errorsdates andomissions.</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>Removetimes using thereference to RFC 5730.</t> <t>Added complete examplesGregorian 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 ofdeposits.</t> </list> </t> </section> <section title="Changes from version REGEXT 02 to REGEXT 03"> <t> <list style="numbers"> <t>The <contents> section changed from MUST to SHOULD,Uppercase vs Lowercase inorder 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><deposit> 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 defineRFC 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 thatversion MUSTmay be1.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 changedused insection 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 08protocol specifications. This document aims toREGEXT 09"> <t> <list style="numbers"> <t>Changes based onreduce thefeedback provided here: https://mailarchive.ietf.org/arch/msg/regext/x_8twvi-MS4dDDRfAZfNJH92UaQ</t> <t>Changes based onambiguity by clarifying that only UPPERCASE usage of thefeedback 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 onkey words have thefeedback provided here: https://mailarchive.ietf.org/arch/msg/regext/UaMNvl1xh60ldjpqHHYc3TNsfhg</t> </list> </t> </section> </section> <section title="Example of a Full Deposit"> <t>Exampledefined 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 ofa Full Deposit with the two example objects rdeObj1different RFCs. The terminology used by implementers andrdeObj2:</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>Exampledevelopers ofa Differential Deposit with the two example objects rdeObj1DNS protocols, andrdeObj2:</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="Exampleby operators ofa Incremental Deposit"> <t>ExampleDNS systems, has sometimes changed in the decades since the DNS was first defined. This document gives current definitions for many ofan Incremental Deposit withthetwo example objects rdeObj1terms used in the DNS in a single document.</t> <t indent="0">This document obsoletes RFC 7719 andrdeObj2:</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 (FifthEdition) 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"/> <authorinitials="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"/> <dateyear='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 SecondEdition REC-xmlschema-1-20041028</title>Edition</title> <authorinitials="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"/> <dateyear='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 SecondEdition 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"/> <dateyear='2004' month='October' /> <keyword>W3C.xmlschema-2</keyword>year="2004" month="October"/> </front> <refcontent>REC-xmlschema-2-20041028</refcontent> </reference> </references> <referencestitle='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 RegistryAgreement 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>