Internet Engineering Task Force                                G. Lozano
Internet-Draft                                                   B. Carr
Intended status: Informational                                     ICANN
Expires: March 12, 2015                                     Sep 08, 2014


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

Abstract

   This document describes the interfaces provided by ICANN to Registry
   Operators in order to fulfill the requirements of Specification 2 and
   3 of the New gTLD Base Agreement.  The interface provided by ICANN to
   Data Escrow Agents in order to fulfill the requirements of
   Specification 2 of the New gTLD Base Agreement is 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 http://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 March 12, 2015.

Copyright Notice

   Copyright (c) 2014 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
   (http://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



Lozano & Carr            Expires March 12, 2015                 [Page 1]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Interfaces for Specification 2 - Data Escrow Reporting . . . .  3
     2.1.  Registry Operator Reporting  . . . . . . . . . . . . . . .  3
     2.2.  Data Escrow Agent Reporting  . . . . . . . . . . . . . . .  6
   3.  Interfaces of Specification 3 - Registry Operator Monthly
       Reporting  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Per-Registrar Transactions Report  . . . . . . . . . . . .  9
     3.2.  Registry Functions Activity Report . . . . . . . . . . . . 10
   4.  Interface details  . . . . . . . . . . . . . . . . . . . . . . 10
     4.1.  IIRDEA Result Object . . . . . . . . . . . . . . . . . . . 11
   5.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 14
     5.1.  IIRDEA Result Schema . . . . . . . . . . . . . . . . . . . 14
     5.2.  Report Object  . . . . . . . . . . . . . . . . . . . . . . 16
     5.3.  Notification Object  . . . . . . . . . . . . . . . . . . . 18
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Change History . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.1.  Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.2.  Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 20
     7.3.  Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.4.  Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.5.  Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     10.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22


















Lozano & Carr            Expires March 12, 2015                 [Page 2]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


1.  Introduction

   This document describes the interfaces provided by ICANN to Registry
   Operators in order to fulfill the requirements of Specification 2 and
   3 of the New gTLD Base Agreement.  The interface provided by ICANN to
   Data Escrow Agents in order to fulfill the requirements of
   Specification 2 of the New gTLD Base Agreement is also described in
   this document.

   Authentication credentials for the interfaces are provided by ICANN
   to the Registry Operator per TLD.  The Registry Operator receives a
   set of credentials to be used by the Registry Operator and by the
   Data Escrow Agent for authentication to the after-mentioned
   interfaces.

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.


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 comply with the
   reporting provisions detailed in Specification 2 of the New gTLD Base
   Agreement of the new gTLD Applicant Guidebook
   [ICANN-GTLD-AGB-20120604].

2.1.  Registry Operator Reporting

   The New gTLD Base Agreement, 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 comply with this provision, the Registry Operator sends a
   <rdeReport:report> element to ICANN for each deposit successfully
   sent to the Data Escrow Agent, using the PUT HTTP verb in the
   interface provided by ICANN at:




Lozano & Carr            Expires March 12, 2015                 [Page 3]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


      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 MUST be
         used.

      *  <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 async interfaces between
      Registry Operators and Data Escrow Agents.

2.1.1.  <report> object

   The <report> element contains the following child elements:

   o  An <id> element contains the identifier assigned to this report.
      The report identifier MUST be the same as the "id" attribute from
      the <deposit>.

   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 Registry
      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  A <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.

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




Lozano & Carr            Expires March 12, 2015                 [Page 4]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


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

   o  A <header> element contains the header of the <deposit>.

   Example <report> object:


 <?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 & Carr            Expires March 12, 2015                 [Page 5]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


2.2.  Data Escrow Agent Reporting

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

   There are three types of notices:

      Deposit Receipt Failure Notice (DRFN): generated by the Escrow
      Agent when no deposit is received pursuant to the schedule
      specified in Specification 2.

      Deposit Verification Failure Notice (DVFN): generated by the
      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 Escrow
      Agent when a deposit is received and the final result of the
      verification process is success.

   In order to comply with this provision, the Data Escrow Agent sends a
   <rdeNotification:notification> element to ICANN, 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 MUST be
         used.

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

2.2.1.  <notification> object

   The <notification> element 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.





Lozano & Carr            Expires March 12, 2015                 [Page 6]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   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 Registry Operator.

   o  A <status> element is used to specify the status of <repDate>.
      The possible values of status are: DVPN, DVFN and DRFN.

      *  DVPN

      *  DVFN

      *  DRFN

   o  An OPTIONAL <reDate> element contains the date and time that the
      deposit was successful 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 successfully validated 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 <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
      to generate the <rdeHeader:header> element.

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

   Example <notification> object:





Lozano & Carr            Expires March 12, 2015                 [Page 7]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


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



Lozano & Carr            Expires March 12, 2015                 [Page 8]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


             </rdeHeader:count>
     </rdeHeader:header>
   </rdeReport:report>
 </rdeNotification:notification>



3.  Interfaces of Specification 3 - Registry Operator Monthly Reporting

   Specification 3 of the New gTLD Base Agreement 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 New gTLD Base Agreement of the new
   gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604].  Before the cut-
   off date the Registry Operator 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 comply with this provision, the Registry Operator sends a
   CSV report on a monthly basis as described in the New gTLD Base
   Agreement, 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 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






Lozano & Carr            Expires March 12, 2015                 [Page 9]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


3.2.  Registry Functions Activity Report

   The Registry Functions Activity Report is a CSV report described in
   Section 2 of Specification 3 of the New gTLD Base Agreement of the
   new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604].

   In order to comply with this provision, the Registry Operator sends a
   CSV report on a monthly basis as described in the New gTLD Base
   Agreement, 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 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


4.  Interface details

   The client MUST set "text/xml" in the HTTP header Content-type when
   using the Data Escrow Agent Reporting and Registry Operator Reporting
   interfaces.  The client MUST set "text/csv" in the HTTP header
   Content-type when using the Per-Registrar Transactions Report
   Registry Functions Activity Report interfaces.

   The Data Escrow Agent Reporting and Registry Operator Reporting
   interfaces support HTTP streams only (HTTP multi-part forms are not
   supported).

   After successfully receiving an input in any of the interfaces
   described above, ICANN validates it and provides a result code in the
   same HTTP transaction.  The interface set the HTTP header Content-
   type: text/xml, when sending the IIRDEA result.

   o  The interface provides a HTTP/200 status code if the interface was
      able to receive the input and no problem was found in the input.

   o  The interface provides a HTTP/400 if the input is incorrect or the
      syntax of the input is invalid.



Lozano & Carr            Expires March 12, 2015                [Page 10]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   o  The interface provides a HTTP/401 status code 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 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>.

   o  The interface provides a HTTP/500 status code if the system is
      experiencing a general failure.  The sending party is responsible
      to send the input again.

   After sending the result code, the interface closes the TCP
   connection.

4.1.  IIRDEA Result Object

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

   An example of a response object is presented below:

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

4.1.1.  Registry Operator Reporting

   The following table lists the result codes of the interface:











Lozano & Carr            Expires March 12, 2015                [Page 11]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   +---------+---------------------------------------------------------+
   | Result  | Message                                                 |
   | Code    |                                                         |
   +---------+---------------------------------------------------------+
   | 1000    | No ERRORs were found and the report has been accepted   |
   |         | by ICANN.                                               |
   | 2001    | The report 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>. |
   +---------+---------------------------------------------------------+

                    Data Escrow Reporting Result Codes

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



Lozano & Carr            Expires March 12, 2015                [Page 12]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


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

                    Data Escrow Reporting Result Codes

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      | Non ICANN accredited registrar present in the report. |
   | 2103      | Values found in the second field of the totals line.  |
   +-----------+-------------------------------------------------------+

              Per-Registrar Transactions Report Result Codes

4.1.4.  Registry Functions Activity Report

   The following table lists the result codes of the interface:








Lozano & Carr            Expires March 12, 2015                [Page 13]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


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

              Registry Functions Activity Report Result Codes


5.  Formal Syntax

   The schema of the IIRDEA, Reports and Notifications 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.

5.1.  IIRDEA Result Schema

   Copyright (c) 2012 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, are permitted provided that the following conditions
   are met:

   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written



Lozano & Carr            Expires March 12, 2015                [Page 14]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.






































Lozano & Carr            Expires March 12, 2015                [Page 15]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


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

     <complexType name="responseType">
       <sequence>
         <element name="result" type="iirdea:resultType"/>
       </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"/>
     </complexType>

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

5.2.  Report Object

   Copyright (c) 2011 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, are permitted provided that the following conditions
   are met:





Lozano & Carr            Expires March 12, 2015                [Page 16]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.



























Lozano & Carr            Expires March 12, 2015                [Page 17]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   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"
       schemaLocation="rde-1.0.xsd"/>
     <import namespace="urn:ietf:params:xml:ns:rdeHeader-1.0"
       schemaLocation="rde-header-1.0.xsd" />

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

     <!-- Root Element -->
     <element name="report" type="rdeReport:reportType"/>

     <!-- Report Type -->
     <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"/>
         <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

5.3.  Notification Object

   Copyright (c) 2011 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, are permitted provided that the following conditions
   are met:



Lozano & Carr            Expires March 12, 2015                [Page 18]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   o  Redistributions of source code must retain the above copyright
      notice, this list of conditions and the following disclaimer.

   o  Redistributions in binary form must reproduce the above copyright
      notice, this list of conditions and the following disclaimer in
      the documentation and/or other materials provided with the
      distribution.

   o  Neither the name of Internet Society, IETF or IETF Trust, nor the
      names of specific contributors, may be used to endorse or promote
      products derived from this software without specific prior written
      permission.

   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
   "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
   A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE COPYRIGHT
   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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="http://www.w3.org/2001/XMLSchema"
  elementFormDefault="qualified">

  <import namespace="urn:ietf:params:xml:ns:rdeReport-1.0"
    schemaLocation="rde-report-1.0.xsd"/>

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

  <!-- Root Element -->
  <element name="notification" type="rdeNotification:notificationType"/>

  <!-- Notification -->
  <complexType name="notificationType">
    <sequence>



Lozano & Carr            Expires March 12, 2015                [Page 19]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


      <element name="deaName" type="rdeNotification:nameType"/>
      <element name="version" type="unsignedShort"/>
      <element name="repDate" type="date"/>
      <element name="status" type="rdeNotification:statusType"/>
      <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>

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


6.  Acknowledgements

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


7.  Change History

7.1.  Version 00

   Initial version.

7.2.  Version 01

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





Lozano & Carr            Expires March 12, 2015                [Page 20]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   o  Added <crDate> to <rdeReport:report>

   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

7.3.  Version 02

   o  Added and updated several result codes.

   o  Added <version> element.

   o  Added Content-type definition.

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

7.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 & Carr            Expires March 12, 2015                [Page 21]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


8.  IANA Considerations

   TODO


9.  Security Considerations

   TODO


10.  References

10.1.  Normative References

   [I-D.arias-noguchi-dnrd-objects-mapping]
              Arias, F., Lozano, G., Noguchi, S., Gould, J., and C.
              Thippeswamy, "Domain Name Registration Data (DNRD) Objects
              Mapping", draft-arias-noguchi-dnrd-objects-mapping-05
              (work in progress), September 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

10.2.  Informative References

   [ICANN-GTLD-AGB-20120604]
              ICANN, "gTLD Applicant Guidebook Version 2012-06-04",
              June 2012, <http://newgtlds.icann.org/en/applicants/agb/
              guidebook-full-04jun12-en.pdf>.


Authors' Addresses

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

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







Lozano & Carr            Expires March 12, 2015                [Page 22]


Internet-Draft          ICANN Registry Interfaces               Sep 2014


   Brett Carr
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles  90292
   US

   Phone: +1.3103015800
   Email: brett.carr@icann.org











































Lozano & Carr            Expires March 12, 2015                [Page 23]