Registry Data Escrow Specification
RFC 8909

Document Type RFC - Proposed Standard (November 2020; No errata)
Author Gustavo Lozano 
Last updated 2020-11-17
Replaces draft-arias-noguchi-registry-data-escrow
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication (wg milestone: Aug 2019 - Submit for publicati... )
Document shepherd James Gould
Shepherd write-up Show (last changed 2020-01-10)
IESG IESG state RFC 8909 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Barry Leiba
Send notices to James Gould <jgould@verisign.com>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack
IANA expert review state Expert Reviews OK


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
Show full document text