--- 1/draft-ietf-regext-data-escrow-02.txt	2019-12-16 14:14:23.079435600 -0800
+++ 2/draft-ietf-regext-data-escrow-03.txt	2019-12-16 14:14:23.119436621 -0800
@@ -1,18 +1,18 @@
 
 Network Working Group                                          G. Lozano
 Internet-Draft                                                     ICANN
-Intended status: Standards Track                            Nov 25, 2019
-Expires: May 28, 2020
+Intended status: Standards Track                            Dec 16, 2019
+Expires: June 18, 2020
 
                    Registry Data Escrow Specification
-                    draft-ietf-regext-data-escrow-02
+                    draft-ietf-regext-data-escrow-03
 
 Abstract
 
    This document specifies the format and contents of data escrow
    deposits targeted primarily for domain name registries.  However, the
    specification was designed to be independent of the underlying
    objects that are being escrowed, therefore it could be used for
    purposes other than domain name registries.
 
 Status of This Memo
@@ -23,21 +23,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at https://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on May 28, 2020.
+   This Internet-Draft will expire on June 18, 2020.
 
 Copyright Notice
 
    Copyright (c) 2019 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
@@ -77,20 +77,21 @@
      13.5.  Changes from 04 to 05  . . . . . . . . . . . . . . . . .  18
      13.6.  Changes from 05 to 06  . . . . . . . . . . . . . . . . .  19
      13.7.  Changes from 06 to 07  . . . . . . . . . . . . . . . . .  19
      13.8.  Changes from 07 to 08  . . . . . . . . . . . . . . . . .  19
      13.9.  Changes from 08 to 09  . . . . . . . . . . . . . . . . .  19
      13.10. Changes from 09 to 10  . . . . . . . . . . . . . . . . .  19
      13.11. Changes from 10 to 11  . . . . . . . . . . . . . . . . .  19
      13.12. Changes from 11 to REGEXT 00 . . . . . . . . . . . . . .  19
      13.13. Changes from version REGEXT 00 to REGEXT 01  . . . . . .  19
      13.14. Changes from version REGEXT 01 to REGEXT 02  . . . . . .  19
+     13.15. Changes from version REGEXT 02 to REGEXT 03  . . . . . .  20
    14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
      14.1.  Normative References . . . . . . . . . . . . . . . . . .  20
      14.2.  Informative References . . . . . . . . . . . . . . . . .  20
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20
 
 1.  Introduction
 
    Registry Data Escrow 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
@@ -408,21 +409,21 @@
    This section of the deposit SHOULD NOT be present in Full Deposits.
    When rebuilding a registry it SHOULD be ignored if present in a Full
    Deposit.
 
    The specification for each object to be escrowed MUST declare the
    identifier to be used to reference the object to be deleted.
 
 5.5.  Child <contents> element
 
    This element of the deposit contains the objects in the deposit.  It
-   MUST be present in all type of deposits.  It contains the data for
+   SHOULD be present in all type of deposits.  It contains the data for
    the objects to be escrowed.  The actual objects have to be specified
    individually.
 
    In the case of Incremental or Differential Deposits, the objects
    indicate whether the object was added or modified after the base
    previous deposit.  In order to distinguish between one and the other,
    it will be sufficient to check existence of the referenced object in
    the previous deposit.
 
    When applying Incremental or Differential Deposits (when rebuilding
@@ -488,21 +489,21 @@
 
     <!-- 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"/>
+        <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>
@@ -520,21 +521,21 @@
 
     <element name="delete" type="rde:deleteType" abstract="true" />
     <complexType name="deleteType">
       <complexContent>
         <restriction base="anyType"/>
       </complexContent>
     </complexType>
 
     <!-- Contents Type -->
     <complexType name="contentsType">
-      <sequence maxOccurs="unbounded">
+      <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>
@@ -771,31 +772,32 @@
        section.
 
    2.  Clarified that "blocked" and "reserved" IDN variants are
        optional.
 
    3.  Made <rdeRegistrar:authInfo> optional.
 
    4.  Introduced substitutionGroup as the mechanism for extending the
        protocol.
 
-   5.  Moved <eppParams> element to be child of <contents>
+   5.  Moved <eppParams> element to be child of <contents>.
+
    6.  Text improvements in the Introduction, Terminology, and Problem
        Scope per Jay's suggestion.
 
    7.  Removed <trDate> from <rdeDomain> and added <trnData> instead,
        which include all the data from the last (pending/processed)
-       transfer request
+       transfer request.
 
    8.  Removed <trDate> from <rdeContact> and added <trnData> instead,
        which include all the data from the last (pending/processed)
-       transfer request
+       transfer request.
 
    9.  Fixed some typographical errors and omissions.
 
 13.3.  Changes from 02 to 03
 
    1.  Separated domain name objects from protocol.
 
    2.  Moved <extension> elements to be child of <deletes> and
        <contents>, additionally removed <extension> element from
        <rdeDomain>,<rdeHost>, <rdeContact>,<rdeRegistrar> and <rdeIDN>
@@ -810,73 +812,81 @@
 13.4.  Changes from 03 to 04
 
    1.  Removed <eppParams> objects.
 
    2.  Populated the "Extension Guidelines" section.
 
    3.  Fixed some typographical errors and omissions.
 
 13.5.  Changes from 04 to 05
 
-   1.  Fixes to the XSD
+   1.  Fixes to the XSD.
 
-   2.  Extension Guidelines moved to dnrd-mappings draft
+   2.  Extension Guidelines moved to dnrd-mappings draft.
 
    3.  Fixed some typographical errors and omissions.
 
 13.6.  Changes from 05 to 06
 
    1.  Fix resend definition.
 
 13.7.  Changes from 06 to 07
 
    1.  Editorial updates.
 
    2.  schemaLocation removed from RDE Schema.
 
 13.8.  Changes from 07 to 08
 
-   1.  Ping update
+   1.  Ping update.
 
 13.9.  Changes from 08 to 09
 
    1.  Ping update.
 
 13.10.  Changes from 09 to 10
 
-   1.  Implementation Status section was added
+   1.  Implementation Status section was added.
 
 13.11.  Changes from 10 to 11
 
    1.  Ping update.
 
 13.12.  Changes from 11 to REGEXT 00
 
    1.  Internet Draft (I-D) adopted by the REGEXT WG.
 
 13.13.  Changes from version REGEXT 00 to REGEXT 01
 
-   1.  Privacy consideration section was added
+   1.  Privacy consideration section was added.
 
 13.14.  Changes from version REGEXT 01 to REGEXT 02
 
    1.  Updated the Security Considerations section to make the language
-       normative
+       normative.
 
    2.  Updated the rde XML schema to remove the dependency with the
-       eppcom namespace reference
+       eppcom namespace reference.
 
-   3.  Editorial updates
+   3.  Editorial updates.
 
-   4.  Remove the reference to RFC 5730
+   4.  Remove the reference to RFC 5730.
 
-   5.  Added complete examples of deposits
+   5.  Added complete examples of deposits.
+
+13.15.  Changes from version REGEXT 02 to REGEXT 03
+
+   1.  The <contents> section changed from MUST to SHOULD, in order to
+       accommodate an Incremental or Differential Deposit that only
+       includes deletes.
+
+   2.  Editorial updates.
 
 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>.