[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10

Internet Engineering Task Force                                G. Lozano
Internet-Draft                                                E. Alvarez
Intended status: Informational                                     ICANN
Expires: September 23, 2019                               March 22, 2019


                       ICANN Registry Interfaces
               draft-lozano-icann-registry-interfaces-10

Abstract

   This document describes the technical details of the interfaces
   provided by the Internet Corporation for Assigned Names and Numbers
   (ICANN) to its contracted parties in order to fulfill reporting
   requirements.  The interfaces provided by ICANN to Data Escrow Agents
   and Registry Operators to fulfill the requirements of Specifications
   2 and 3 of the gTLD Base Registry Agreement are also described in
   this document.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 23, 2019.

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
   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



Lozano & Alvarez       Expires September 23, 2019               [Page 1]


Internet-Draft          ICANN Registry Interfaces             March 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Date and Time . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Object Description  . . . . . . . . . . . . . . . . . . .   3
   2.  Interfaces for Specification 2 - Data Escrow Reporting  . . .   9
     2.1.  Registry Operator Reporting . . . . . . . . . . . . . . .   9
     2.2.  Data Escrow Agent Reporting . . . . . . . . . . . . . . .  11
   3.  Interfaces of Specification 3 - Registry Operator Monthly
       Reporting . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     3.1.  Per-Registrar Transactions Report . . . . . . . . . . . .  13
     3.2.  Registry Functions Activity Report  . . . . . . . . . . .  13
   4.  Technical details of the interfaces . . . . . . . . . . . . .  14
     4.1.  Response Object . . . . . . . . . . . . . . . . . . . . .  15
   5.  Monitoring the reporting status . . . . . . . . . . . . . . .  21
     5.1.  Monitoring the status of Data Escrow Reports  . . . . . .  21
     5.2.  Monitoring the status of Data Escrow Notifications  . . .  21
     5.3.  Monitoring the status of Registry Functions Activity
           Report  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     5.4.  Monitoring the status of the Per-Registrar Transactions
           Report  . . . . . . . . . . . . . . . . . . . . . . . . .  22
   6.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .  24
     6.1.  IIRDEA Result Schema  . . . . . . . . . . . . . . . . . .  24
     6.2.  Report Object . . . . . . . . . . . . . . . . . . . . . .  25
     6.3.  Notification Object . . . . . . . . . . . . . . . . . . .  26
     6.4.  RRI Reporting Summary Object  . . . . . . . . . . . . . .  28
     6.5.  Notifications Object  . . . . . . . . . . . . . . . . . .  30
     6.6.  Reports Object  . . . . . . . . . . . . . . . . . . . . .  31
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  32
   8.  Change History  . . . . . . . . . . . . . . . . . . . . . . .  32
     8.1.  Version 00  . . . . . . . . . . . . . . . . . . . . . . .  32
     8.2.  Version 01  . . . . . . . . . . . . . . . . . . . . . . .  32
     8.3.  Version 02  . . . . . . . . . . . . . . . . . . . . . . .  33
     8.4.  Version 03  . . . . . . . . . . . . . . . . . . . . . . .  33
     8.5.  Version 04  . . . . . . . . . . . . . . . . . . . . . . .  33
     8.6.  Version 05  . . . . . . . . . . . . . . . . . . . . . . .  34
     8.7.  Version 06  . . . . . . . . . . . . . . . . . . . . . . .  34
     8.8.  Version 07  . . . . . . . . . . . . . . . . . . . . . . .  34
     8.9.  Version 08  . . . . . . . . . . . . . . . . . . . . . . .  34
     8.10. Version 09  . . . . . . . . . . . . . . . . . . . . . . .  34
     8.11. Version 10  . . . . . . . . . . . . . . . . . . . . . . .  35
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  35
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  35



Lozano & Alvarez       Expires September 23, 2019               [Page 2]


Internet-Draft          ICANN Registry Interfaces             March 2019


     11.1.  Normative References . . . . . . . . . . . . . . . . . .  35
     11.2.  Informative References . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  36

1.  Introduction

   This document describes the technical details of the interfaces
   provided by the Internet Corporation for Assigned Names and Numbers
   (ICANN) to other contracted parties in order to fulfill reporting
   requirements.  The interface provided by ICANN to Registry Operators
   and Data Escrow Agents in order to fulfill the requirements of
   Specifications 2 and 3 of the gTLD Base Registry Agreement
   [ICANN-GTLD-BASE-RA] are also described in this document.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   XML is case sensitive.  Unless stated otherwise, XML specifications
   and examples provided in this document MUST be interpreted in the
   character case presented in order to develop a conforming
   implementation.

1.2.  Date and Time

   Numerous fields indicate "date and time", such as the creation and
   receipt dates for data escrow deposits.  These fields SHALL contain
   timestamps indicating the date and time in UTC as specified in
   [RFC3339], with no offset from the zero meridian.

1.3.  Object Description

   This section describes the base objects supported by this
   specification.

1.3.1.  <iirdea:result> object

   The ICANN interfaces for registries and data escrow agents (IIRDEA)
   <iirdea:result> object is used to provide information on the result
   of a verification process when interacting with the interfaces.

   The <iirdea:result> object contains the following attribute and child
   elements:






Lozano & Alvarez       Expires September 23, 2019               [Page 3]


Internet-Draft          ICANN Registry Interfaces             March 2019


   o  A "code" attribute whose value is a four-digit decimal number that
      identifies the result of a process.  Available result code values
      MUST be defined for the corresponding process.

   o  An OPTIONAL "domainCount" attribute to indicate the number of
      domain names related to the reported result.

   o  A <msg> element containing a human-readable description of the
      result code.

   o  An OPTIONAL <description> element that includes additional details
      on the result conditions.

   An example of a <iirdea:result> object is presented below:

   <result code="2001">
       <msg>The structure of the report is invalid.</msg>
       <description>
          'XX' could not be parsed as a number (line: 2 column:3)
       </description>
   </result>

1.3.2.  <rdeReport:report> object

   The contents of a data escrow deposit are described using a
   <rdeReport:report> object.  The <rdeReport:report> object contains
   the following child elements:

   o  An <id> element that contains the identifier assigned to this
      report.  The report identifier MUST be the same as the "id"
      attribute from the <deposit>.  If the data escrow deposit does not
      include a unique identifer, the Data Escrow Agent MUST generate a
      unique identifier to reference the data escrow deposit and use it
      in the <id> element.

   o  A <version> element contains the version of the specification
      used.  This value MUST be 1.

   o  A <rydeSpecEscrow> element contains the version of the Data Escrow
      Specification (e.g. draft-arias-noguchi-registry-data-escrow-06)
      used to create the deposit.  After the specification is published
      as an RFC, the value MUST be the RFC number assigned by IANA.

   o  An OPTIONAL <rydeSpecMapping> element contains the version of the
      Domain Name Registration Data (DNRD) Objects Mapping (e.g. draft-
      arias-noguchi-dnrd-objects-mapping-05) used to create the deposit.
      After the specification is published as an RFC, the value MUST be
      the RFC number assigned by IANA.  The <rydeSpecMapping> element



Lozano & Alvarez       Expires September 23, 2019               [Page 4]


Internet-Draft          ICANN Registry Interfaces             March 2019


      MUST be included if the deposit was created using any version of
      the DNRD objects mapping specification (see,
      [I-D.arias-noguchi-dnrd-objects-mapping]).

   o  A <resend> element contains the value of the "resend" attribute of
      the <deposit>.

   o  A <crDate> element contains the date and time that the deposit was
      created by the Registry Operator.

   o  A <kind> element is used to identify the kind of deposit: FULL,
      INCR (Incremental) or DIFF (Differential).

   o  A <watermark> element contains the date and time corresponding to
      the Timeline Watermark (<watermark> element) of the <deposit>.

   o  A <rdeHeader:header> element contains the header of the <deposit>
      as defined in [I-D.arias-noguchi-dnrd-objects-mapping]

   An example of a <rdeReport:report> object is available in
   Section 2.1.

1.3.3.  <rdeNotification:notification> object

   The <rdeNotification:notification> object is used by Data Escrow
   Agents to document the result of the data escrow deposit verification
   process.  The <rdeNotification:notification> object contains the
   following child elements:

   o  A <deaName> element contains the name of the Data Escrow Agent.

   o  A <version> element contains the version of the specification
      used.  This value MUST be 1.

   o  A <repDate> element contains the reported date.  In case of a DVPN
      or DVFN notification this value MUST be the date of the
      <watermark> element of the <deposit>.  In case of a DRFN deposit
      notification, this value MUST be the date for which no deposit was
      received from the Registrar or Registry Operator.

   o  A <status> element is used to specify the status of <repDate>.
      The possible values of status are: DVPN, DVFN and DRFN.  The value
      for the <status> element is determined by the three types of
      notices:

      *  Deposit Receipt Failure Notice (DRFN): generated by the Data
         Escrow Agent when no deposit is received pursuant to the data
         escrow deposit schedule.



Lozano & Alvarez       Expires September 23, 2019               [Page 5]


Internet-Draft          ICANN Registry Interfaces             March 2019


      *  Deposit Verification Failure Notice (DVFN): generated by the
         Data Escrow Agent when a deposit is received, but the final
         result of the verification process is failure.

      *  Deposit Verification Pass Notice (DVPN): generated by the Data
         Escrow Agent when a deposit is received and the final result of
         the verification process is success.

   o  An OPTIONAL <results> element contains the errors detected during
      the data escrow deposit verification process performed by the Data
      Escrow Agent.  The <results> element includes one or more
      <iirdea:result> elements as defined in Section 1.3.1.  In case of
      a DRFN or DVPN deposit notification the <results> element MUST NOT
      be present.

   o  An OPTIONAL <reDate> element contains the date and time that the
      deposit was successfully received by the Data Escrow Agent.  In
      case of a DRFN deposit notification this element MUST NOT be
      present.

   o  An OPTIONAL <vaDate> element contains the date and time that the
      deposit was processed for validation by the Data Escrow Agent.  In
      case of a DRFN deposit notification this element MUST NOT be
      present.

   o  An OPTIONAL <lastFullDate> element contains the date of the
      Timeline Watermark (<watermark> element) of the most recent FULL
      deposit that was successfully validated by the Data Escrow Agent.
      This element MUST NOT be present if a successfully validated full
      deposit has never been deposited.

   o  An OPTIONAL <rdeReport:report> element is used by the Data Escrow
      Agent to provide extended information about the deposit.  In case
      of a DRFN deposit notification this element MUST NOT be present.
      In case of a DVPN or DVFN deposit notification this element MUST
      be present.  When this element is present, the <rdeHeader:header>
      element MUST be generated by the Data Escrow Agent for the
      Timeline Watermark (<watermark> element) of the deposit being
      processed.  If the deposit being processed is a differential or
      incremental deposit, the Data Escrow Agent MUST process the last
      full plus all differentials or last full plus last incremental
      escrow deposits from the same repository (e.g.  TLD) to generate
      the <rdeHeader:header> element.

   o  Note: In case of a DVPN or DVFN deposit notification, the <id> is
      used as unique identifier.





Lozano & Alvarez       Expires September 23, 2019               [Page 6]


Internet-Draft          ICANN Registry Interfaces             March 2019


   An example of a <rdeNotification:notification> object is available in
   Section 2.2.

1.3.4.  <rriReporting:summary> Object

   Interfaces that support monitoring the reporting status for a
   specific repository, provide a <rriReporting:summary> object as
   defined by the schema in Section 6 in the HTTP Entity-body when a
   HTTP/200 code is sent by the interface.

   The <rriReporting:summary> element includes the following child
   elements:

   o  A choice of one of the elements as defined in the
      "rdeHeader:repositoryTypeGroup" (see
      [I-D.arias-noguchi-dnrd-objects-mapping]) that indicates the
      unique identifier for the repository being escrowed.

   o  A <creationDate> element with the date and time in which the
      queried repository was created in the system.

   o  A <depositSchedule> OPTIONAL element indicating the current Data
      Escrow Deposit schedule for the queried repository.  Possible
      values are "None", "Weekly", and "Daily".

   o  An OPTIONAL <lastFullDate> element indicating the date of the
      Timeline Watermark (<watermark> element) of the most recent FULL
      deposit that was successfully validated for the queried repository
      as notified by the Data Escrow Agent.

   o  A <statusReports> element with a <statusReport> element for each
      report type for the queried repository.  Each <statusReport>
      element includes the following child elements:

      *  <type> : a string value indicating the report type to which the
         information provided pertains.

      *  <enabled> : a boolean value indicating if the report type is
         enabled for the repository.

      *  <status> : a string value indicating the reporting status.  A
         value of "ok" indicates there are no reporting issues in the
         corresponding report type, otherwise the value of
         "unsatisfactory" is shown.

      *  An OPTIONAL <issues> element included only when the <status>
         element has a value of "unsatisfactory", and includes an empty
         <issue> element for each date with a reporting problem found in



Lozano & Alvarez       Expires September 23, 2019               [Page 7]


Internet-Draft          ICANN Registry Interfaces             March 2019


         the corresponding report type.  Each <issue> element includes a
         REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED
         "description" attribute to describe the issue.  The possible
         values to describe each reporting issue are:

         +  "Missing_Deposit_Full": If the latest notification received
            from the Data Escrow Agent for the date indicates that a
            scheduled "Full" deposit was not submitted by the repository
            owner.

         +  "Missing_Deposit_Diff": If the latest notification received
            from the Data Escrow Agent for the date indicates that a
            scheduled "Differential" deposit was not submitted by the
            repository owner.

         +  "Invalid_Deposit_Full": If the latest notification received
            from the Data Escrow Agent for the date indicates that a
            "Full" deposit was received by the Data Escrow Agent, but
            failed the verification process.

         +  "Invalid_Deposit_Diff": If the latest notification received
            from the Data Escrow Agent for the date indicates that a
            "Differential" deposit was received by the Data Escrow
            Agent, but failed the verification process.

         +  "No_Report_Received" If no report has been received for the
            date.

   o  A <timestamp> element to indicate the date and time in which the
      reporting status response was created.

1.3.5.  <rdeReports:reports> Object

   Interfaces that support monitoring and retrieving Data Escrow Reports
   received, provide a <rdeReports:reports> object as defined by the
   schema in Section 6 in the HTTP Entity-body when a HTTP/200 code is
   sent by the interface.

   The <rdeReports:reports> element includes a list of
   <rdeReports:receivedReport> objects, one for each <rdeReport:report>
   successfully received by ICANN.  Each <rdeReports:receivedReport>
   object includes the following child elements:

   o  A <received> element to indicate the date and time in which the
      report was received by ICANN.

   o  A <rdeReport:report> element as defined in Section 1.3.2 as
      received by ICANN.



Lozano & Alvarez       Expires September 23, 2019               [Page 8]


Internet-Draft          ICANN Registry Interfaces             March 2019


1.3.6.  <rdeNotifications:notifications> Object

   Interfaces that support monitoring and retrieving Data Escrow
   Notifications received from Data Escrow Agents, provide a
   <rdeNotifications:notifications> object as defined by the schema in
   Section 6 in the HTTP Entity-body when a HTTP/200 code is sent by the
   interface.

   The <rdeNotifications:notifications> element includes a list of
   <rdeNotifications:receivedNotification> objects, one for each
   <rdeNotification:notification> successfully received by ICANN.  Each
   <rdeNotifications:receivedNotification> object includes the following
   child elements:

   o  A <received> element to indicate the date and time in which the
      notification was received by ICANN.

   o  A <rdeNotification:notification> element as defined in
      Section 1.3.3 as received by ICANN.

2.  Interfaces for Specification 2 - Data Escrow Reporting

   This section describes the interfaces provided by ICANN to Registry
   Operators and Data Escrow Agents in order to fulfill the reporting
   requirements detailed in Specification 2 of the gTLD Base Registry
   Agreement [ICANN-GTLD-BASE-RA].

2.1.  Registry Operator Reporting

   The gTLD Base Registry Agreement [ICANN-GTLD-BASE-RA], Specification
   2, Part A, Section 7 requires Registry Operators to provide ICANN
   with a written statement that includes a copy of the report generated
   upon creation of a deposit and a statement that the deposit has been
   inspected by the Registry Operator and is complete and accurate.

   In order to satisfy this requirement, the Registry Operator sends to
   ICANN a <rdeReport:report> object as defined in Section 1.3.2 for
   each deposit successfully sent to the Data Escrow Agent, using the
   PUT HTTP verb in the interface provided by ICANN at:

      https://ry-api.icann.org/report/registry-escrow-report/<tld>/<id>

      Where:

      *  <tld> MUST be substituted by the TLD for which the report is
         being provided.  In case of an IDN TLD, the A-label (see
         [RFC5890]) MUST be used.




Lozano & Alvarez       Expires September 23, 2019               [Page 9]


Internet-Draft          ICANN Registry Interfaces             March 2019


      *  <id> MUST be substituted by the identifier assigned to this
         report, which MUST be the same as the "id" attribute from the
         <deposit>.

      Note: the interface supports overwriting the information of a
      particular report <id> to support asynchronous interfaces between
      Registry Operators and Data Escrow Agents.

   Example of a <rdeReport:report> object for a data escrow deposit
   corresponding to a TLD Registry repository:

   <?xml version="1.0" encoding="UTF-8"?>
   <rdeReport:report
     xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
     xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0">
     <rdeReport:id>20101017001</rdeReport:id>
     <rdeReport:version>1</rdeReport:version>
     <rdeReport:rydeSpecEscrow>
       draft-arias-noguchi-registry-data-escrow-06
     </rdeReport:rydeSpecEscrow>
     <rdeReport:rydeSpecMapping>
       draft-arias-noguchi-dnrd-objects-mapping-05
     </rdeReport:rydeSpecMapping>
     <rdeReport:resend>0</rdeReport:resend>
     <rdeReport:crDate>2010-10-17T00:15:00.0Z</rdeReport:crDate>
     <rdeReport:kind>FULL</rdeReport:kind>
     <rdeReport:watermark>2010-10-17T00:00:00Z</rdeReport:watermark>
     <rdeHeader:header>
       <rdeHeader:tld>test</rdeHeader:tld>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeDomain-1.0">2</rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeHost-1.0">1</rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeRegistrar-1.0">1
       </rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">1</rdeHeader:count>
       <rdeHeader:count
         uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">1
       </rdeHeader:count>
     </rdeHeader:header>
   </rdeReport:report>




Lozano & Alvarez       Expires September 23, 2019              [Page 10]


Internet-Draft          ICANN Registry Interfaces             March 2019


2.2.  Data Escrow Agent Reporting

   The gTLD Base Registry Agreement [ICANN-GTLD-BASE-RA], Specification
   2, Part B, Section 7 requires Data Escrow Agents, to deliver ICANN
   with a notification object every time a successfully processed
   deposit is received from the Registry Operator regardless of the
   final status of the verification process.

   In order to satisfy this requirement, the Data Escrow Agent sends to
   ICANN a <rdeNotification:notification> object as defined in
   Section 1.3.3, using the POST HTTP verb in the interface provided by
   ICANN at:

      https://ry-api.icann.org/report/escrow-agent-notification/<tld>

      Where:

      *  <tld> MUST be substituted by the TLD for which the notification
         is being provided.  In case of an IDN TLD, the A-label (see
         [RFC5890]) MUST be used.

   If by 23:59:59 UTC, a deposit has not been successfully processed
   regardless of the final status of the verification process, a
   <rdeNotification:notification> object with DRFN status MUST be send
   to ICANN.

   Example of a <rdeNotification:notification> object of a Data Escrow
   Agent notification corresponding to a Registry repository Data Escrow
   Deposit:

  <?xml version="1.0" encoding="UTF-8"?>
  <rdeNotification:notification
   xmlns:rdeNotification="urn:ietf:params:xml:ns:rdeNotification-1.0"
   xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
   xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0">
   <rdeNotification:deaName>Escrow Agent Inc.</rdeNotification:deaName>
   <rdeNotification:version>1</rdeNotification:version>
   <rdeNotification:repDate>2010-10-17</rdeNotification:repDate>
   <rdeNotification:status>DVPN</rdeNotification:status>
   <rdeNotification:reDate>
     2010-10-17T03:15:00.0Z
   </rdeNotification:reDate>
   <rdeNotification:vaDate>
     2010-10-17T05:15:00.0Z
   </rdeNotification:vaDate>
   <rdeNotification:lastFullDate>
     2010-10-14
   </rdeNotification:lastFullDate>



Lozano & Alvarez       Expires September 23, 2019              [Page 11]


Internet-Draft          ICANN Registry Interfaces             March 2019


   <rdeReport:report>
     <rdeReport:id>20101017001</rdeReport:id>
     <rdeReport:version>1</rdeReport:version>
     <rdeReport:rydeSpecEscrow>
       draft-arias-noguchi-registry-data-escrow-06
     </rdeReport:rydeSpecEscrow>
     <rdeReport:rydeSpecMapping>
       draft-arias-noguchi-dnrd-objects-mapping-03
     </rdeReport:rydeSpecMapping>
     <rdeReport:resend>0</rdeReport:resend>
     <rdeReport:crDate>2010-10-17T00:15:00.0Z</rdeReport:crDate>
     <rdeReport:kind>FULL</rdeReport:kind>
     <rdeReport:watermark>2010-10-17T00:00:00Z</rdeReport:watermark>
     <rdeHeader:header>
      <rdeHeader:tld>test</rdeHeader:tld>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeDomain-1.0">1</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeHost-1.0">3</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeContact-1.0">1</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeRegistrar-1.0">3</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeIDN-1.0">1</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeNNDN-1.0">10</rdeHeader:count>
      <rdeHeader:count
       uri="urn:ietf:params:xml:ns:rdeEppParams-1.0">0</rdeHeader:count>
     </rdeHeader:header>
   </rdeReport:report>
  </rdeNotification:notification>


3.  Interfaces of Specification 3 - Registry Operator Monthly Reporting

   Specification 3 of the gTLD Base Registry Agreement
   [ICANN-GTLD-BASE-RA] requires Registry Operators to provide a set of
   monthly reports per gTLD.  Two type of reports are required to be
   sent by Registries: Per-Registrar Transactions Report and Registry
   Functions Activity Report.  This section specifies the interfaces
   provided by ICANN to automate the upload of these reports by Registry
   Operators.

   The cut-off date for the reception of the reports specified in
   specification 3 is defined in the gTLD Base Registry Agreement
   [ICANN-GTLD-BASE-RA].  Before the cut-off date the Registry Operator




Lozano & Alvarez       Expires September 23, 2019              [Page 12]


Internet-Draft          ICANN Registry Interfaces             March 2019


   could replace a successfully validated report as many times as it
   needs.

3.1.  Per-Registrar Transactions Report

   The Per-Registrar Transactions Report is a CSV report described in
   Section 1 of Specification 3.

   In order to satisfy this requirement, the Registry Operator sends a
   CSV report on a monthly basis as described in the gTLD Base Registry
   Agreement [ICANN-GTLD-BASE-RA], using the PUT HTTP verb in the
   interface provided by ICANN at:

      https://ry-api.icann.org/report/registrar-
      transactions/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD for which the reports is
         being provided.  In case of an IDN TLD, the A-label (see
         [RFC5890]) MUST be used.

      *  <date> MUST be substituted by the month for which the reports
         is being provided in the form of YYYY-MM.  Where 'YYYY' is the
         year and 'MM' is the two digit month number.  For example:
         2013-03

3.2.  Registry Functions Activity Report

   The Registry Functions Activity Report is a CSV report described in
   Section 2 of Specification 3 of the gTLD Base Registry Agreement
   [ICANN-GTLD-BASE-RA].

   In order to satisfy this requirement, the Registry Operator sends a
   CSV report on a monthly basis as described in the gTLD Base Registry
   Agreement [ICANN-GTLD-BASE-RA], using the PUT HTTP verb in the
   interface provided by ICANN at:

      https://ry-api.icann.org/report/registry-functions-
      activity/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD for which the report is
         being provided.  In case of an IDN TLD, the A-label (see
         [RFC5890]) MUST be used.





Lozano & Alvarez       Expires September 23, 2019              [Page 13]


Internet-Draft          ICANN Registry Interfaces             March 2019


      *  <date> MUST be substituted by the month for which the reports
         is being provided in the form of YYYY-MM.  Where 'YYYY' is the
         year and 'MM' is the two digit month number.  For example:
         2013-03

4.  Technical details of the interfaces

   Content-type value in the HTTP header:

   o  The client MUST set "text/xml" in the HTTP header Content-type
      when using the Data Escrow Agent Reporting and Registry Operator
      Reporting interfaces described in Section 2.

   o  The client MUST set "text/csv" in the HTTP header Content-type
      when using the Per-Registrar Transactions Report Registry
      Functions Activity Report interfaces described in Section 3.

   The interfaces support HTTP streams only (HTTP multi-part forms are
   not supported).

   After successfully receiving an input in any of the interfaces, ICANN
   validates it and provides a <response> object with an result element
   in the same HTTP transaction.

   The following HTTP status codes are standard across all interfaces:

   o  The interface provides a HTTP/200 status code and sets the HTTP
      header Content-type: text/xml, if the interface was able to
      receive the input sucessfully, the client MUST review the response
      object to verify the result code after processing the input.

   o  The interface provides a HTTP/400 status code and sets the HTTP
      header Content-type: text/xml, if the input is incorrect or the
      syntax of the input is invalid.  A response object is included
      with the input validation failure details.

   o  The interface provides a HTTP/401 status code and sets the HTTP
      header Content-type: text/plain, if the credentials provided does
      not authorize the Registry Operator to upload a report for that
      <tld>.

   o  The interface provides a HTTP/403 status code and sets the HTTP
      header Content-type: text/plain, if the credentials provided are
      valid but are being used to access a resource that permission is
      not granted for or the connecting IP address is not whitelisted
      for the <tld>.





Lozano & Alvarez       Expires September 23, 2019              [Page 14]


Internet-Draft          ICANN Registry Interfaces             March 2019


   o  The interface provides a HTTP/405 status code if the interface
      does not support the request method.

   o  The interface provides a HTTP/500 status code and sets the HTTP
      header Content-type: text/plain, if the system is experiencing a
      general failure.  The sending party is responsible to send the
      input again.

   o  The interface provides a HTTP/501 status code and sets the HTTP
      header Content-type: text/plain, if the functionality has not yet
      been implemented.

   After sending the response, the interfaces closes the TCP connection.

4.1.  Response Object

   After processing the input provided in any of the interfaces, a
   response object as defined by the schema in Section 6 is provided in
   the HTTP Entity-body when an HTTP/200 or HTTP/400 status code is sent
   by the interface.

   An example of a response object upon successful input receipt is
   presented below:

   HTTP/1.1 200 OK
   Content-Type: text/xml
   Content-Length: 248

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <response xmlns="urn:ietf:params:xml:ns:iirdea-1.0">
     <result code="1000">
        <msg>No ERRORs were found and the report has been
             accepted by ICANN.</msg>
        <description></description>
     </result>
   </response>

   An example of a response object in the event of input error is
   presented below:












Lozano & Alvarez       Expires September 23, 2019              [Page 15]


Internet-Draft          ICANN Registry Interfaces             March 2019


   HTTP/1.1 400 Bad Request
   Content-Type: text/xml
   Content-Length: 279

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
   <response xmlns="urn:ietf:params:xml:ns:iirdea-1.0">
       <result code="2001">
           <msg>The structure of the report is invalid.</msg>
           <description>
              'XX' could not be parsed as a number (line: 2 column:3)
           </description>
       </result>
   </response>

   The following sections provide the IIRDEA Result Codes per interface:




































Lozano & Alvarez       Expires September 23, 2019              [Page 16]


Internet-Draft          ICANN Registry Interfaces             March 2019


4.1.1.  Registry Operator Reporting

   The following table lists the result codes of the interface:

   +--------+----------------------------------------------------------+
   | Result | Message                                                  |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | No ERRORs were found and the report has been accepted by |
   |        | ICANN.                                                   |
   | 2001   | The request did not validate against the schema.         |
   | 2004   | Report for a date in the future. The <crDate> and        |
   |        | <watermark> date should not be in the future.            |
   | 2005   | Version is not supported.                                |
   | 2006   | The <id> in the <report> element and the <id> in the URL |
   |        | path do not match.                                       |
   | 2007   | Interface is disabled for this TLD.                      |
   | 2008   | The <crDate> and <watermark> date should not be before   |
   |        | the creation date of the TLD in the system.              |
   | 2202   | The <tld> in the <header> and the TLD in the URL path do |
   |        | not match.                                               |
   | 2205   | Report regarding a differential deposit received for a   |
   |        | Sunday (<watermark>).                                    |
   | 2206   | csvDomain and rdeDomain count provided in the <header>.  |
   | 2209   | Missing required <tld> element in the <header>.          |
   | 2210   | The value of the "rcdn" attribute in the <count> element |
   |        | does not match the same or lower level names in the      |
   |        | <tld> in the URL path.                                   |
   | 2211   | Multiple count elements with the same "uri", "rcdn", and |
   |        | "registrarId" attribute values provided in the <header>. |
   | 2212   | An invalid NR-LDH label or A-label was found or the      |
   |        | domain name syntax is invalid in the "rcdn" attribute.   |
   +--------+----------------------------------------------------------+

                    Data Escrow Reporting Result Codes
















Lozano & Alvarez       Expires September 23, 2019              [Page 17]


Internet-Draft          ICANN Registry Interfaces             March 2019


4.1.2.  Data Escrow Agent Reporting

   The following table lists the result codes of the interface:

   +--------+----------------------------------------------------------+
   | Result | Message                                                  |
   | Code   |                                                          |
   +--------+----------------------------------------------------------+
   | 1000   | No ERRORs were found and the notification has been       |
   |        | accepted by ICANN.                                       |
   | 2001   | The request did not validate against the schema.         |
   | 2002   | A DVPN notification exists for that date (<repDate>).    |
   | 2004   | Notification for a date in the future. The <crDate> and  |
   |        | <watermark> and <repDate> date should not be in the      |
   |        | future.                                                  |
   | 2005   | Version is not supported.                                |
   | 2007   | Interface is disabled for this TLD.                      |
   | 2008   | The <crDate> and <watermark> and <repDate> date should   |
   |        | not be before the creation date of the TLD in the        |
   |        | system.                                                  |
   | 2201   | The <repDate> and <watermark> in the notification do not |
   |        | match.                                                   |
   | 2202   | The <tld> in the <header> and the TLD in the URL path do |
   |        | not match.                                               |
   | 2203   | A Deposit Verification Pass Notice (DVPN) notification   |
   |        | was received, but the Domain Name count is missing in    |
   |        | the <header>.                                            |
   | 2204   | The notification for the report "id" already exists.     |
   | 2205   | Notification regarding a differential deposit received   |
   |        | for a Sunday (<repDate>).                                |
   | 2206   | csvDomain and rdeDomain count provided in the <header>.  |
   | 2207   | A DVPN or DVFN was received, but the <report> element is |
   |        | missing in the notification.                             |
   | 2208   | A DRFN was received, but a <report> element exists in    |
   |        | the notification.                                        |
   | 2209   | Missing required <tld> element in the <header>.          |
   | 2210   | The value of the "rcdn" attribute in the <count> element |
   |        | does not match the same or lower level names in the      |
   |        | <tld> in the URL path.                                   |
   | 2211   | Multiple count elements with the same "uri", "rcdn", and |
   |        | "registrarId" attribute values provided in the <header>. |
   | 2212   | An invalid NR-LDH label or A-label was found or the      |
   |        | domain name syntax is invalid in the "rcdn" attribute.   |
   +--------+----------------------------------------------------------+

                    Data Escrow Reporting Result Codes





Lozano & Alvarez       Expires September 23, 2019              [Page 18]


Internet-Draft          ICANN Registry Interfaces             March 2019


4.1.3.  Per-Registrar Transactions Report

   The following table lists the result codes of the interface:

   +----------+--------------------------------------------------------+
   | Result   | Message                                                |
   | Code     |                                                        |
   +----------+--------------------------------------------------------+
   | 1000     | No ERRORs were found and the report has been accepted  |
   |          | by ICANN.                                              |
   | 2001     | The structure of the report is invalid.                |
   | 2002     | A report for that month already exists, the cut-off    |
   |          | date already passed.                                   |
   | 2003     | Negative numeric value present in the report.          |
   | 2004     | Report for a month in the future.                      |
   | 2007     | Interface is disabled for this TLD.                    |
   | 2008     | Reported month before the creation date of the TLD in  |
   |          | the system.                                            |
   | 2101     | Incorrect totals present in the report.                |
   | 2102     | A non ICANN-accredited registrar is present in the     |
   |          | report.                                                |
   | 2103     | Values found in the second field of the totals line.   |
   | 2105     | The report is not encoded in UTF-8. Note: reports      |
   |          | encoded in US-ASCII are accepted.                      |
   +----------+--------------------------------------------------------+

              Per-Registrar Transactions Report Result Codes
























Lozano & Alvarez       Expires September 23, 2019              [Page 19]


Internet-Draft          ICANN Registry Interfaces             March 2019


4.1.4.  Registry Functions Activity Report

   The following table lists the result codes of the interface:

   +----------+--------------------------------------------------------+
   | Result   | Message                                                |
   | Code     |                                                        |
   +----------+--------------------------------------------------------+
   | 1000     | No ERRORs were found and the report has been accepted  |
   |          | by ICANN.                                              |
   | 2001     | The structure of the report is invalid.                |
   | 2002     | A report for that month already exists, the cut-off    |
   |          | date already passed.                                   |
   | 2003     | Negative numeric value present in the report.          |
   | 2004     | Report for a month in the future.                      |
   | 2007     | Interface is disabled for this TLD.                    |
   | 2008     | Reported month before the creation date of the TLD in  |
   |          | the system.                                            |
   | 2105     | The report is not encoded in UTF-8. Note: reports      |
   |          | encoded in US-ASCII are accepted.                      |
   +----------+--------------------------------------------------------+

              Registry Functions Activity Report Result Codes




























Lozano & Alvarez       Expires September 23, 2019              [Page 20]


Internet-Draft          ICANN Registry Interfaces             March 2019


5.  Monitoring the reporting status

   Registries MAY monitor the status of the reports described in
   Specification 2 and Specification 3 of the gTLD Base Registry
   Agreement [ICANN-GTLD-BASE-RA] using the following interfaces that
   supports the HEAD HTTP verb:

5.1.  Monitoring the status of Data Escrow Reports

   Registries MAY monitor the status of Data Escrow Reports using the
   following interface:

      https://ry-api.icann.org/info/report/registry-escrow-
      report/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD being queried.  In case of
         an IDN TLD, the A-label (see [RFC5890]) MUST be used.

      *  <date> MUST be substituted by the day being queried.  For
         example: 2013-03-02

      Possible results are:

      *  The interface provides a HTTP/200 status code, if a
         syntactically valid data escrow report was received for the
         queried date.

      *  The interface provides a HTTP/404 status code, if a
         syntactically valid data escrow report has not been received
         for the queried date.

5.2.  Monitoring the status of Data Escrow Notifications

   Registries and Data Escrow Agents MAY monitor the status of Data
   Escrow Notifications using the following interface:

      https://ry-api.icann.org/info/report/escrow-agent-
      notification/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD being queried.  In case of
         an IDN TLD, the A-label (see [RFC5890]) MUST be used.

      *  <date> MUST be substituted by the day being queried.  For
         example: 2013-03-02



Lozano & Alvarez       Expires September 23, 2019              [Page 21]


Internet-Draft          ICANN Registry Interfaces             March 2019


      Possible results are:

      *  The interface provides a HTTP/200 status code, if a
         syntactically valid data escrow notification was received for
         the queried date.

      *  The interface provides a HTTP/404 status code, if a
         syntactically valid data escrow notification has not been
         received for the queried date.

5.3.  Monitoring the status of Registry Functions Activity Report

   Registries MAY monitor the status of Registry Functions Activity
   Report using the following interface:

      https://ry-api.icann.org/info/report/registry-functions-
      activity/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD being queried.  In case of
         an IDN TLD, the A-label (see [RFC5890]) MUST be used.

      *  <date> MUST be substituted by the month being queried.  For
         example: 2013-03

      Possible results are:

      *  The interface provides a HTTP/200 status code, if a
         syntactically valid registry functions activity report was
         received for the queried month.

      *  The interface provides a HTTP/404 status code, if a
         syntactically valid registry functions activity report has not
         been received for the queried month.

5.4.  Monitoring the status of the Per-Registrar Transactions Report

   Registries MAY monitor the status of Per-Registrar Transactions
   Report using the following interface:

      https://ry-api.icann.org/info/report/registrar-
      transactions/<tld>/<date>

      Where:

      *  <tld> MUST be substituted by the TLD being queried.  In case of
         an IDN TLD, the A-label (see [RFC5890]) MUST be used.



Lozano & Alvarez       Expires September 23, 2019              [Page 22]


Internet-Draft          ICANN Registry Interfaces             March 2019


      *  <date> MUST be substituted by the month being queried.  For
         example: 2013-03

      Possible results are:

      *  The interface provides a HTTP/200 status code, if a
         syntactically valid per-registrar transactions report was
         received for the queried month.

      *  The interface provides a HTTP/404 status code, if a
         syntactically valid per-registrar transactions report has not
         been received for the queried month.







































Lozano & Alvarez       Expires September 23, 2019              [Page 23]


Internet-Draft          ICANN Registry Interfaces             March 2019


6.  Formal Syntax

   The schema of the IIRDEA Result, Report, Notification, RRI Reporting,
   Notifications, and Reports objects described in Section 1.3 are
   presented here.

   The BEGIN and END 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.  IIRDEA Result Schema

   Copyright (c) 2017 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).































Lozano & Alvarez       Expires September 23, 2019              [Page 24]


Internet-Draft          ICANN Registry Interfaces             March 2019


   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:iirdea-1.0"
     xmlns:iirdea="urn:ietf:params:xml:ns:iirdea-1.0"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <annotation>
       <documentation>
         ICANN interfaces for registries and data escrow agents
       </documentation>
     </annotation>

     <element name="response" type="iirdea:responseType"/>
     <element name="result" type="iirdea:resultType"/>

     <complexType name="responseType">
       <sequence>
         <element ref="iirdea:result" />
       </sequence>
     </complexType>

     <complexType name="resultType">
       <sequence>
         <element name="msg" type="token"/>
         <element name="description" type="string"
          minOccurs="0"/>
       </sequence>
       <attribute name="code" type="iirdea:codeType"
        use="required"/>
       <attribute name="domainCount" type="unsignedInt"/>
     </complexType>

     <simpleType name="codeType">
       <restriction base="unsignedShort">
         <minInclusive value="1000"/>
         <maxInclusive value="9999"/>
       </restriction>
     </simpleType>

   </schema>
   END

6.2.  Report Object

   Copyright (c) 2017 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.




Lozano & Alvarez       Expires September 23, 2019              [Page 25]


Internet-Draft          ICANN Registry Interfaces             March 2019


   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).

   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:rdeReport-1.0"
     xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
     xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
     xmlns:rde="urn:ietf:params:xml:ns:rde-1.0"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

       <import namespace="urn:ietf:params:xml:ns:rde-1.0" />
       <import namespace="urn:ietf:params:xml:ns:rdeHeader-1.0" />

     <annotation>
       <documentation>
         Data Escrow Report schema
       </documentation>
     </annotation>

     <element name="report" type="rdeReport:reportType"/>

     <complexType name="reportType">
       <sequence>
         <element name="id" type="rde:depositIdType"/>
         <element name="version" type="unsignedShort"/>
         <element name="rydeSpecEscrow" type="token"/>
         <element name="rydeSpecMapping" type="token" minOccurs="0"/>
         <element name="resend" type="unsignedShort"/>
         <element name="crDate" type="dateTime"/>
         <element name="kind" type="rde:depositTypeType"/>
         <element name="watermark" type="dateTime"/>
         <element ref="rdeHeader:header"/>
       </sequence>
     </complexType>
   </schema>
   END

6.3.  Notification Object

   Copyright (c) 2017 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.





Lozano & Alvarez       Expires September 23, 2019              [Page 26]


Internet-Draft          ICANN Registry Interfaces             March 2019


   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).

   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:rdeNotification-1.0"
     xmlns:rdeNotification="urn:ietf:params:xml:ns:rdeNotification-1.0"
     xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
     xmlns:iirdea="urn:ietf:params:xml:ns:iirdea-1.0"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <import namespace="urn:ietf:params:xml:ns:rdeReport-1.0"/>
     <import namespace="urn:ietf:params:xml:ns:iirdea-1.0"/>

     <annotation>
       <documentation>
         Data Escrow Notification schema
       </documentation>
     </annotation>

     <element name="notification"
     type="rdeNotification:notificationType"/>

     <complexType name="notificationType">
       <sequence>
         <element name="deaName" type="rdeNotification:nameType"/>
         <element name="version" type="unsignedShort"/>
         <element name="repDate" type="date"/>
         <element name="status" type="rdeNotification:statusType"/>
         <element name="results" type="rdeNotification:resultsType"
           minOccurs="0" />
         <element name="reDate" type="dateTime" minOccurs="0"/>
         <element name="vaDate" type="dateTime" minOccurs="0"/>
         <element name="lastFullDate" type="date" minOccurs="0"/>
         <element ref="rdeReport:report" minOccurs="0"/>
       </sequence>
     </complexType>

     <simpleType name="nameType">
       <restriction base="normalizedString">
         <minLength value="1" />
         <maxLength value="255" />
       </restriction>
     </simpleType>



Lozano & Alvarez       Expires September 23, 2019              [Page 27]


Internet-Draft          ICANN Registry Interfaces             March 2019


     <complexType name="resultsType">
       <sequence>
         <element ref="iirdea:result" maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <simpleType name="statusType">
       <restriction base="token">
         <enumeration value="DVPN"/>
         <enumeration value="DVFN"/>
         <enumeration value="DRFN"/>
       </restriction>
     </simpleType>
   </schema>
   END

6.4.  RRI Reporting Summary Object

   Copyright (c) 2018 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).

   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:rriReporting-1.0"
     xmlns:rriReporting="urn:ietf:params:xml:ns:rriReporting-1.0"
     xmlns:rdeHeader="urn:ietf:params:xml:ns:rdeHeader-1.0"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <import namespace="urn:ietf:params:xml:ns:rdeHeader-1.0" />

     <element name="summary" type="rriReporting:summaryType"/>

     <complexType name="summaryType">
       <sequence>
         <group ref="rdeHeader:repositoryTypeGroup"/>
         <element name="creationDate" type="dateTime" />
         <element name="depositSchedule"
            type="rriReporting:depositScheduleType" />
         <element name="lastFullDate" type="date" minOccurs="0"/>
         <element name="statusReports"
            type="rriReporting:statusReportsType" />



Lozano & Alvarez       Expires September 23, 2019              [Page 28]


Internet-Draft          ICANN Registry Interfaces             March 2019


         <element name="timestamp" type="dateTime" />
       </sequence>
     </complexType>

     <simpleType name="depositScheduleType">
       <restriction base="token">
         <enumeration value="None" />
         <enumeration value="Weekly" />
         <enumeration value="Daily" />
       </restriction>
     </simpleType>

     <complexType name="statusReportsType">
       <sequence>
         <element name="statusReport"
           type="rriReporting:statusReportType" maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <complexType name="statusReportType">
       <sequence>
        <element name="type" type="rriReporting:statusReportTypeType" />
        <element name="enabled" type="boolean" />
        <element name="status" type="rriReporting:statusType" />
        <element name="issues" type="rriReporting:issuesType"
          minOccurs="0" />
       </sequence>
     </complexType>

     <simpleType name="statusReportTypeType">
      <restriction base="token">
      <enumeration value="DEA_Notification" />
      <enumeration value="Registrar_Escrow_Report" />
      <enumeration value="Registry_Escrow_Report" />
      <enumeration value="PPSP_Escrow_Report" />
      <enumeration value="Registry_Functions_Activity_Report" />
      <enumeration value="Registry_Per_Registrar_Transactions_Report" />
      <enumeration value="PPSP_Per_Registrar_Activity_Report" />
      </restriction>
     </simpleType>

     <simpleType name="statusType">
       <restriction base="token">
         <enumeration value="ok" />
         <enumeration value="unsatisfactory" />
       </restriction>
     </simpleType>




Lozano & Alvarez       Expires September 23, 2019              [Page 29]


Internet-Draft          ICANN Registry Interfaces             March 2019


     <complexType name="issuesType">
       <sequence>
         <element name="issue" type="rriReporting:issueType"
           maxOccurs="unbounded" />
       </sequence>
     </complexType>

     <complexType name="issueType">
       <attribute name="date" type="rriReporting:issueDateType"
          use="required" />
       <attribute name="description" type="rriReporting:descriptionType"
          use="required" />
     </complexType>

     <simpleType name="issueDateType">
       <restriction base="token">
         <pattern
           value="\d{4}-(0[1-9]|1[012])(-(0[1-9]|[12][0-9]|3[01]))?" />
       </restriction>
     </simpleType>

     <simpleType name="descriptionType">
       <restriction base="token">
         <enumeration value="Missing_Deposit_Full" />
         <enumeration value="Missing_Deposit_Diff" />
         <enumeration value="Invalid_Deposit_Full" />
         <enumeration value="Invalid_Deposit_Diff" />
         <enumeration value="No_Report_Received" />
       </restriction>
     </simpleType>
   </schema>
   END

6.5.  Notifications Object

   Copyright (c) 2018 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).








Lozano & Alvarez       Expires September 23, 2019              [Page 30]


Internet-Draft          ICANN Registry Interfaces             March 2019


   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:rdeNotifications-1.0"
    xmlns:rdeNotifications="urn:ietf:params:xml:ns:rdeNotifications-1.0"
    xmlns:rdeNotification="urn:ietf:params:xml:ns:rdeNotification-1.0"
    xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <import namespace="urn:ietf:params:xml:ns:rdeNotification-1.0" />

     <element name="notifications"
       type="rdeNotifications:notificationsType"/>

     <complexType name="notificationsType">
       <sequence>
         <element name="receivedNotification" maxOccurs="unbounded">
           <complexType>
             <sequence>
               <element name="received" type="dateTime" />
               <element ref="rdeNotification:notification" />
             </sequence>
           </complexType>
         </element>
       </sequence>
     </complexType>
   </schema>
   END

6.6.  Reports Object

   Copyright (c) 2018 IETF Trust and the persons identified as authors
   of the code.  All rights reserved.

   Redistribution and use in source and binary forms, with or without
   modification, is permitted pursuant to, and subject to the license
   terms contained in, the Simplified BSD License set forth in
   Section 4.c of the IETF Trust's Legal Provisions Relating to IETF
   Documents (http://trustee.ietf.org/license-info).













Lozano & Alvarez       Expires September 23, 2019              [Page 31]


Internet-Draft          ICANN Registry Interfaces             March 2019


   BEGIN
   <?xml version="1.0" encoding="UTF-8"?>
   <schema targetNamespace="urn:ietf:params:xml:ns:rdeReports-1.0"
     xmlns:rdeReport="urn:ietf:params:xml:ns:rdeReport-1.0"
     xmlns:rdeReports="urn:ietf:params:xml:ns:rdeReports-1.0"
     xmlns="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified">

     <import namespace="urn:ietf:params:xml:ns:rdeReport-1.0" />

     <element name="reports" type="rdeReports:reportsType"/>

     <complexType name="reportsType">
       <sequence>
         <element name="receivedReport" maxOccurs="unbounded">
           <complexType>
             <sequence>
               <element name="received" type="dateTime" />
               <element ref="rdeReport:report" />
             </sequence>
           </complexType>
         </element>
       </sequence>
     </complexType>
   </schema>
   END

7.  Acknowledgements

   Special suggestions that have been incorporated into this document
   were provided by David Kipling, James Gould, Gregory Zaltsman, Brett
   Carr and Harel Efraim.

8.  Change History

   [[RFC Editor: Please remove this section.]]

8.1.  Version 00

   Initial version.

8.2.  Version 01

   o  <rdeReport:report> and <rdeNotification:notification> moved from
      escrow drafts to this draft

   o  Added <crDate> to <rdeReport:report>




Lozano & Alvarez       Expires September 23, 2019              [Page 32]


Internet-Draft          ICANN Registry Interfaces             March 2019


   o  <reDate> element of <rdeReport:report> is now OPTIONAL

   o  Added <deaName> element to <rdeNotification:notification>

   o  <rydeSpecEscrow> and <rydeSpecMapping> added to the draft

   o  Several report elements are OPTIONAL to support async interfaces
      between Registry Operators and Data Escrow Agents

   o  Added <TLD> and <id> to registry-escrow-report interface in order
      to make the interface idempotent and support async RyO-DEA
      interfaces

   o  Added <TLD> to escrow-agent-notification interface

   o  The escrow-agent-notification uses POST and not PUT, this has been
      fixed

   o  Several clarifications

8.3.  Version 02

   o  Added and updated several result codes.

   o  Added <version> element.

   o  Added Content-type definition.

8.4.  Version 03

   o  Added several result codes.

   o  unsignedShort is now used for result code in iirdea schema.

   o  Enumeration was removed from the iirdea schema.

8.5.  Version 04

   o  Added result codes: 2207 and 2208.

   o  Removed result codes: 2203.

   o  Added clarification regarding the support of HTTP streams.








Lozano & Alvarez       Expires September 23, 2019              [Page 33]


Internet-Draft          ICANN Registry Interfaces             March 2019


8.6.  Version 05

   o  Added result codes: 2007 and 2008.

8.7.  Version 06

   o  Added clarification of error code HTTP/403 in Section 4.

8.8.  Version 07

   o  Added Section 5: "Monitoring compliance with the New gTLD Base
      Agreement".

8.9.  Version 08

   o  Reorganized specification structure to allow easier references
      from new specifications expanding functionality in the ICANN
      Registry Interfaces.

   o  Added Section 1.3 to document object definitions, previously
      defined in other sections.

   o  Added <rriReporting>, <notifications>, and <reports> object
      descriptions to Section 1.3, and schema definitions to Section 6.

   o  Renamed Section 5 title as "Monitoring the reporting status".

   o  Updated element <rydeSpecMapping> as OPTIONAL in the <rdeReport>
      schema.

   o  Added OPTIONAL attribute "domainCount" to the <iirdea:result>
      element.

   o  Added OPTIONAL element <results> to the <rdeNotification> schema.

   o  Added result codes: 2105, 2209, 2210 and 2211.

   o  Added "gTLD Base Registry Agreement" references.

   o  Added clarifications to Section 4.

8.10.  Version 09

   o  Standardized XSD schema validation error message for notifications
      and reports.

   o  Element <lastFullDate> made optional in the <rriReporting> schema.




Lozano & Alvarez       Expires September 23, 2019              [Page 34]


Internet-Draft          ICANN Registry Interfaces             March 2019


   o  Separated example RRI interface responses for successful and
      unsuccessful input.

8.11.  Version 10

   1.  Ping update.

9.  IANA Considerations

   TODO

10.  Security Considerations

   TODO

11.  References

11.1.  Normative References

   [I-D.arias-noguchi-dnrd-objects-mapping]
              Lozano, G., Gould, J., and C. Thippeswamy, "Domain Name
              Registration Data (DNRD) Objects Mapping", draft-arias-
              noguchi-dnrd-objects-mapping-10 (work in progress),
              January 2019.

   [ICANN-GTLD-BASE-RA]
              ICANN, "gTLD Base Registry Agreement", Jan 2014,
              <https://newgtlds.icann.org/sites/default/files/
              agreements/agreement-approved-09jan14-en.pdf>.

   [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>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <https://www.rfc-editor.org/info/rfc3688>.

11.2.  Informative References







Lozano & Alvarez       Expires September 23, 2019              [Page 35]


Internet-Draft          ICANN Registry Interfaces             March 2019


   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

Authors' Addresses

   Gustavo Lozano
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles  90292
   US

   Phone: +1.3103015800
   Email: gustavo.lozano@icann.org


   Eduardo Alvarez
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles  90292
   US

   Phone: +1.3103015800
   Email: eduardo.alvarez@icann.org





















Lozano & Alvarez       Expires September 23, 2019              [Page 36]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/