idnits 2.17.1 draft-lozano-icann-registry-interfaces-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Sep 03, 2013) is 3888 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.arias-noguchi-dnrd-objects-mapping' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 888, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-arias-noguchi-dnrd-objects-mapping-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft ICANN 4 Intended status: Informational Sep 03, 2013 5 Expires: March 7, 2014 7 ICANN Registry Interfaces 8 draft-lozano-icann-registry-interfaces-02 10 Abstract 12 This document describes the interfaces provided by ICANN to Registry 13 Operators in order to fulfill the requirements of Specification 2 and 14 3 of the New gTLD Base Agreement. The interface provided by ICANN to 15 Data Escrow Agents in order to fulfill the requirements of 16 Specification 2 of the New gTLD Base Agreement is also described in 17 this document. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 7, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Interfaces for Specification 2 - Data Escrow Reporting . . . . 3 56 2.1. Registry Operator Reporting . . . . . . . . . . . . . . . 3 57 2.2. Data Escrow Agent Reporting . . . . . . . . . . . . . . . 6 58 3. Interfaces of Specification 3 - Registry Operator Monthly 59 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 3.1. Per-Registrar Transactions Report . . . . . . . . . . . . 9 61 3.2. Registry Functions Activity Report . . . . . . . . . . . . 10 62 4. Interface details . . . . . . . . . . . . . . . . . . . . . . 10 63 4.1. IIRDEA Result Object . . . . . . . . . . . . . . . . . . . 11 64 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.1. IIRDEA Result Schema . . . . . . . . . . . . . . . . . . . 13 66 5.2. Report Object . . . . . . . . . . . . . . . . . . . . . . 15 67 5.3. Notification Object . . . . . . . . . . . . . . . . . . . 16 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 69 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 18 70 7.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 18 71 7.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 72 7.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 20 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 This document describes the interfaces provided by ICANN to Registry 83 Operators in order to fulfill the requirements of Specification 2 and 84 3 of the New gTLD Base Agreement. The interface provided by ICANN to 85 Data Escrow Agents in order to fulfill the requirements of 86 Specification 2 of the New gTLD Base Agreement is also described in 87 this document. 89 Authentication credentials for the interfaces are provided by ICANN 90 to the Registry Operator per TLD. The Registry Operator receives a 91 set of credentials to be used by the Registry Operator and by the 92 Data Escrow Agent for authentication to the after-mentioned 93 interfaces. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 XML is case sensitive. Unless stated otherwise, XML specifications 102 and examples provided in this document MUST be interpreted in the 103 character case presented in order to develop a conforming 104 implementation. 106 2. Interfaces for Specification 2 - Data Escrow Reporting 108 This section describes the interfaces provided by ICANN to Registry 109 Operators and Data Escrow Agents in order to comply with the 110 reporting provisions detailed in Specification 2 of the New gTLD Base 111 Agreement of the new gTLD Applicant Guidebook 112 [ICANN-GTLD-AGB-20120604]. 114 2.1. Registry Operator Reporting 116 The New gTLD Base Agreement, Specification 2, Part A, Section 7 117 requires Registry Operators to provide ICANN with a written statement 118 that includes a copy of the report generated upon creation of a 119 deposit and a statement that the deposit has been inspected by the 120 Registry Operator and is complete and accurate. 122 In order to comply with this provision, the Registry Operator sends a 123 element to ICANN for each deposit successfully 124 sent to the Data Escrow Agent, using the PUT HTTP verb in the 125 interface provided by ICANN at: 127 https://ry-api.icann.org/report/registry-escrow-report// 129 Where: 131 * MUST be substituted by the TLD for which the report is 132 being provided. In case of an IDN TLD, the A-label MUST be 133 used. 135 * MUST be substituted by the identifier assigned to this 136 report, which MUST be the same as the "id" attribute from the 137 . 139 Note: The interface supports overwriting the information of a 140 particular report "id" to support async interfaces between 141 Registry Operators and Data Escrow Agents. 143 2.1.1. object 145 The element contains the following child elements: 147 o An element contains the identifier assigned to this report. 148 The report identifier MUST be the same as the "id" attribute from 149 the . 151 o An element contains the version of the specification 152 used. This value MUST be 1. 154 o An element contains the version of the Registry 155 Data Escrow Specification (e.g. 156 draft-arias-noguchi-registry-data-escrow-06) used to create the 157 deposit. After the specification is published as an RFC, the 158 value MUST be the RFC number assigned by IANA. 160 o An element contains the version of the Domain 161 Name Registration Data (DNRD) Objects Mapping (e.g. 162 draft-arias-noguchi-dnrd-objects-mapping-03) used to create the 163 deposit. After the specification is published as an RFC, the 164 value MUST be the RFC number assigned by IANA. 166 o A element contains the value of the "resend" attribute of 167 the . 169 o A element contains the date and time that the deposit was 170 created by the Registry Operator. 172 o A element is used to identify the kind of deposit: FULL, 173 INCR (Incremental) or DIFF (Differential). 175 o A element contains the data and time corresponding to 176 the Timeline Watermark ( element) of the . 178 o A
element contains the header of the . 180 Example object: 182 183 186 20101017001 187 1 188 189 draft-arias-noguchi-registry-data-escrow-06 190 191 192 draft-arias-noguchi-dnrd-objects-mapping-03 193 194 0 195 2010-10-17T00:15:00.0Z 196 FULL 197 2010-10-17T00:00:00Z 198 199 test 200 2 202 1 204 1 206 1 208 209 1 211 1 213 1 215 216 217 219 2.2. Data Escrow Agent Reporting 221 The New gTLD Base Agreement, Specification 2, Part B, Section 7 222 requires Data Escrow Agents, to deliver to ICANN a notification every 223 time a successfully processed deposit is received from the Registry 224 Operator regardless of the final status of the verification process. 226 There are three types of notices: 228 Deposit Receipt Failure Notice (DRFN): generated by the Escrow 229 Agent when no deposit is received pursuant to the schedule 230 specified in Specification 2. 232 Deposit Verification Failure Notice (DVFN): generated by the 233 Escrow Agent when a deposit is received, but the final result of 234 the verification process is failure. 236 Deposit Verification Pass Notice (DVPN): generated by the Escrow 237 Agent when a deposit is received and the final result of the 238 verification process is success. 240 In order to comply with this provision, the Data Escrow Agent sends a 241 element to ICANN, using the POST HTTP 242 verb in the interface provided by ICANN at: 244 https://ry-api.icann.org/report/escrow-agent-notification/ 246 Where: 248 * MUST be substituted by the TLD for which the notification 249 is being provided. In case of an IDN TLD, the A-label MUST be 250 used. 252 If by 23:59 UTC, a deposit has not been successfully processed 253 regardless of the final status of the verification process, a 254 with DRFN status MUST be send to 255 ICANN. 257 2.2.1. object 259 The element contains the following child elements: 261 o A element contains the name of the Data Escrow Agent. 263 o An element contains the version of the specification 264 used. This value MUST be 1. 266 o An element contains the reported date. In case of a 267 DVPN or DVFN notification this value MUST be the date of the 268 element of the . In case of a DRFN deposit 269 notification, this value MUST be the date for which no deposit was 270 received from the Registry Operator. 272 o A element is used to specify the status of . 273 The possible values of status are: DVPN, DVFN and DRFN. 275 * DVPN 277 * DVFN 279 * DRFN 281 o An OPTIONAL element contains the date and time that the 282 deposit was successful received by the Data Escrow Agent. In case 283 of a DRFN deposit notification this element MUST NOT be present. 285 o An OPTIONAL element contains the date and time that the 286 deposit was successfully validated by the Data Escrow Agent. In 287 case of a DRFN deposit notification this element MUST NOT be 288 present. 290 o An OPTIONAL element contains the date of the 291 Timeline Watermark ( element) of the most recent FULL 292 deposit that was successfully validated by the Data Escrow Agent. 293 This element MUST NOT be present if a successfully validated full 294 deposit has never been deposited. 296 o An OPTIONAL element is used by the Data Escrow Agent to 297 provide extended information about the deposit. In case of a DRFN 298 deposit notification this element MUST NOT be present. In case of 299 a DVPN or DVFN deposit notification this element MUST be present. 300 When this element is present, the element MUST 301 be generated by the Data Escrow Agent for the Timeline Watermark 302 ( element) of the deposit being processed. If the 303 deposit being processed is a differential or incremental deposit, 304 the Data Escrow Agent MUST process the last full plus all 305 differentials or last full plus last incremental escrow deposits 306 to generate the element. 308 o Note: In case of a DPVN or DVFN deposit notification, the 309 is used as unique identifier. 311 Example object: 313 314 318 Escrow Agent Inc. 319 1 320 2010-10-17 321 DVPN 322 323 2010-10-17T03:15:00.0Z 324 325 326 2010-10-17T05:15:00.0Z 327 328 329 2010-10-14 330 331 332 20101017001 333 1 334 335 draft-arias-noguchi-registry-data-escrow-06 336 337 338 draft-arias-noguchi-dnrd-objects-mapping-03 339 340 0 341 2010-10-17T00:15:00.0Z 342 FULL 343 2010-10-17T00:00:00Z 344 345 test 346 2 348 1 350 1 352 1 354 355 1 357 1 359 1 361 362 363 364 366 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting 368 Specification 3 of the New gTLD Base Agreement requires Registry 369 Operators to provide a set of monthly reports per gTLD. Two type of 370 reports are required to be sent by Registries: Per-Registrar 371 Transactions Report and Registry Functions Activity Report. This 372 section specifies the interfaces provided by ICANN to automate the 373 upload of these reports by Registry Operators. 375 The cut-off date for the reception of the reports specified in 376 specification 3 is defined in the New gTLD Base Agreement of the new 377 gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. Before the cut- 378 off date the Registry Operator could replace a successfully validated 379 report as many times as it needs. 381 3.1. Per-Registrar Transactions Report 383 The Per-Registrar Transactions Report is a CSV report described in 384 Section 1 of Specification 3. 386 In order to comply with this provision, the Registry Operator sends a 387 CSV report on a monthly basis as described in the New gTLD Base 388 Agreement, using the PUT HTTP verb in the interface provided by ICANN 389 at: 391 https://ry-api.icann.org/report/registrar-transactions// 392 394 Where: 396 * MUST be substituted by the TLD for which the reports is 397 being provided. In case of an IDN TLD, the A-label MUST be 398 used. 400 * MUST be substituted by the month for which the reports 401 is being provided in the form of YYYY-MM. Where 'YYYY' is the 402 year and 'MM' is the two digit month number. For example: 403 2013-03 405 3.2. Registry Functions Activity Report 407 The Registry Functions Activity Report is a CSV report described in 408 Section 2 of Specification 3 of the New gTLD Base Agreement of the 409 new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 411 In order to comply with this provision, the Registry Operator sends a 412 CSV report on a monthly basis as described in the New gTLD Base 413 Agreement, using the PUT HTTP verb in the interface provided by ICANN 414 at: 416 https://ry-api.icann.org/report/registry-functions-activity// 417 419 Where: 421 * MUST be substituted by the TLD for which the report is 422 being provided. In case of an IDN TLD, the A-label MUST be 423 used. 425 * MUST be substituted by the month for which the reports 426 is being provided in the form of YYYY-MM. Where 'YYYY' is the 427 year and 'MM' is the two digit month number. For example: 428 2013-03 430 4. Interface details 432 The client MUST set "text/xml" in the HTTP header Content-type when 433 using the Data Escrow Agent Reporting and Registry Operator Reporting 434 interfaces. The client MUST set "text/csv" in the HTTP header 435 Content-type when using the Per-Registrar Transactions Report 436 Registry Functions Activity Report interfaces. 438 After successfully receiving an input in any of the interfaces 439 described above, ICANN validates it and provides a result code in the 440 same HTTP transaction. The interface set the HTTP header Content- 441 type: text/xml, when sending the IIRDEA result. 443 o The interface provides a HTTP/200 status code if the interface was 444 able to receive the input and no problem was found in the input. 446 o The interface provides a HTTP/400 if the input is incorrect or the 447 syntax of the input is invalid. 449 o The interface provides a HTTP/401 status code if the credentials 450 provided does not authorize the Registry Operator to upload a 451 report for that . 453 o The interface provides a HTTP/500 status code if the system is 454 experiencing a general failure. The sending party is responsible 455 to send the input again. 457 After sending the result code, the interface closes the TCP 458 connection. 460 4.1. IIRDEA Result Object 462 After processing the input provided in any of the interfaces 463 described in this document, a response object as defined by the 464 schema in Section 5 is provided in the HTTP Entity-body when an HTTP/ 465 200 and HTTP/400 status code is sent by the interface. 467 An example of a response object is presented below: 469 470 471 472 No error 473 474 The report has been accepted by ICANN. 475 476 477 479 The following sections provide the IIRDEA Result Codes per interface: 481 4.1.1. Registry Operator Reporting 483 The following table lists the result codes of the interface: 485 +-----------+-------------------------------------------------------+ 486 | Result | Message | 487 | Code | | 488 +-----------+-------------------------------------------------------+ 489 | 1000 | No ERRORs were found and the report has been accepted | 490 | | by ICANN. | 491 | 2001 | The report did not validate against the schema. | 492 | 2004 | Report for a date in the future. | 493 | 2005 | Version is not supported. | 494 | 2006 | The id in the element and the id in the URL | 495 | | path do not match. | 496 | 2202 | The TLD in the
and the TLD in the URL path | 497 | | do not match. | 498 +-----------+-------------------------------------------------------+ 500 Data Escrow Reporting Result Codes 502 4.1.2. Data Escrow Agent Reporting 504 The following table lists the result codes of the interface: 506 +--------+----------------------------------------------------------+ 507 | Result | Message | 508 | Code | | 509 +--------+----------------------------------------------------------+ 510 | 1000 | No ERRORs were found and the notification has been | 511 | | accepted by ICANN. | 512 | 2001 | The notification did not validate against the schema. | 513 | 2002 | A DVPN notification exists for that date (). | 514 | 2004 | Notification for a date in the future. | 515 | 2005 | Version is not supported. | 516 | 2201 | The and in the notification do not | 517 | | match. | 518 | 2202 | The TLD in the
and the TLD in the URL path do | 519 | | not match. | 520 | 2203 | A Deposit Verification Pass Notice (DVPN) notification | 521 | | was received, but the Domain Name count is missing in | 522 | | the
| 523 | 2204 | The notification for the report "id" already exists. | 524 +--------+----------------------------------------------------------+ 526 Data Escrow Reporting Result Codes 528 4.1.3. Per-Registrar Transactions Report 530 The following table lists the result codes of the interface: 532 +-----------+-------------------------------------------------------+ 533 | Result | Message | 534 | Code | | 535 +-----------+-------------------------------------------------------+ 536 | 1000 | No ERRORs were found and the report has been accepted | 537 | | by ICANN. | 538 | 2001 | The structure of the report is invalid. | 539 | 2002 | A report for that month already exists, the cut-off | 540 | | date already passed. | 541 | 2003 | Negative numeric value present in the report. | 542 | 2004 | Report for a month in the future. | 543 | 2101 | Incorrect totals present in the report. | 544 | 2102 | Non ICANN accredited registrar present in the report. | 545 | 2103 | Values found in the second field of the totals line. | 546 +-----------+-------------------------------------------------------+ 548 Per-Registrar Transactions Report Result Codes 550 4.1.4. Registry Functions Activity Report 552 The following table lists the result codes of the interface: 554 +-----------+-------------------------------------------------------+ 555 | Result | Message | 556 | Code | | 557 +-----------+-------------------------------------------------------+ 558 | 1000 | No ERRORs were found and the report has been accepted | 559 | | by ICANN. | 560 | 2001 | The structure of the report is invalid. | 561 | 2002 | A report for that month already exists, the cut-off | 562 | | date already passed. | 563 | 2003 | Negative numeric value present in the report. | 564 | 2004 | Report for a month in the future. | 565 +-----------+-------------------------------------------------------+ 567 Registry Functions Activity Report Result Codes 569 5. Formal Syntax 571 The schema of the IIRDEA, Reports and Notifications are presented 572 here. 574 The BEGIN and END tags are not part of the schema; they are used to 575 note the beginning and ending of the schema for URI registration 576 purposes. 578 5.1. IIRDEA Result Schema 580 Copyright (c) 2012 IETF Trust and the persons identified as authors 581 of the code. All rights reserved. 583 Redistribution and use in source and binary forms, with or without 584 modification, are permitted provided that the following conditions 585 are met: 587 o Redistributions of source code must retain the above copyright 588 notice, this list of conditions and the following disclaimer. 590 o Redistributions in binary form must reproduce the above copyright 591 notice, this list of conditions and the following disclaimer in 592 the documentation and/or other materials provided with the 593 distribution. 595 o Neither the name of Internet Society, IETF or IETF Trust, nor the 596 names of specific contributors, may be used to endorse or promote 597 products derived from this software without specific prior written 598 permission. 600 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 601 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 602 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 603 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 604 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 605 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 606 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 607 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 608 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 609 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 610 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 612 BEGIN 613 614 619 620 621 ICANN interfaces for registries and data escrow agents 622 623 625 627 628 629 630 631 633 634 635 636 637 638 639 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 END 663 5.2. Report Object 665 Copyright (c) 2011 IETF Trust and the persons identified as authors 666 of the code. All rights reserved. 668 Redistribution and use in source and binary forms, with or without 669 modification, are permitted provided that the following conditions 670 are met: 672 o Redistributions of source code must retain the above copyright 673 notice, this list of conditions and the following disclaimer. 675 o Redistributions in binary form must reproduce the above copyright 676 notice, this list of conditions and the following disclaimer in 677 the documentation and/or other materials provided with the 678 distribution. 680 o Neither the name of Internet Society, IETF or IETF Trust, nor the 681 names of specific contributors, may be used to endorse or promote 682 products derived from this software without specific prior written 683 permission. 685 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 686 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 687 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 688 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 689 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 690 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 691 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 692 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 693 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 694 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 695 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 697 BEGIN 698 699 706 708 711 712 713 Registry Data Escrow Report schema 714 715 717 718 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 END 737 5.3. Notification Object 739 Copyright (c) 2011 IETF Trust and the persons identified as authors 740 of the code. All rights reserved. 742 Redistribution and use in source and binary forms, with or without 743 modification, are permitted provided that the following conditions 744 are met: 746 o Redistributions of source code must retain the above copyright 747 notice, this list of conditions and the following disclaimer. 749 o Redistributions in binary form must reproduce the above copyright 750 notice, this list of conditions and the following disclaimer in 751 the documentation and/or other materials provided with the 752 distribution. 754 o Neither the name of Internet Society, IETF or IETF Trust, nor the 755 names of specific contributors, may be used to endorse or promote 756 products derived from this software without specific prior written 757 permission. 759 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 760 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 761 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 762 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 763 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 764 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 765 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 766 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 767 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 768 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 769 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 771 BEGIN 772 773 779 782 783 784 Registry Data Escrow Notification schema 785 786 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 804 805 806 807 808 809 811 812 813 814 815 816 817 818 819 END 821 6. Acknowledgements 823 Special suggestions that have been incorporated into this document 824 were provided by David Kipling, James Gould, Gregory Zaltsman, and 825 Harel Efraim. 827 7. Change History 829 7.1. Version 00 831 Initial version. 833 7.2. Version 01 835 o and moved from 836 escrow drafts to this draft 838 o Added to 840 o element of is now OPTIONAL 842 o Added element to 844 o and added to the draft 846 o Several report elements are OPTIONAL to support async interfaces 847 between Registry Operators and Data Escrow Agents 849 o Added and to registry-escrow-report interface in order 850 to make the interface idempotent and support async RyO-DEA 851 interfaces 853 o Added to escrow-agent-notification interface 855 o The escrow-agent-notification uses POST and not PUT, this has been 856 fixed 858 o Several clarifications 860 7.3. Version 02 862 o Added and updated several result codes. 864 o Added element. 866 o Added Content-type definition. 868 8. IANA Considerations 870 TODO 872 9. Security Considerations 874 TODO 876 10. References 877 10.1. Normative References 879 [I-D.arias-noguchi-dnrd-objects-mapping] 880 Arias, F., Lozano, G., Noguchi, S., Gould, J., and C. 881 Thippeswamy, "Domain Name Registration Data (DNRD) Objects 882 Mapping", draft-arias-noguchi-dnrd-objects-mapping-04 883 (work in progress), July 2013. 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, March 1997. 888 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 889 January 2004. 891 10.2. Informative References 893 [ICANN-GTLD-AGB-20120604] 894 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 895 June 2012, . 898 Author's Address 900 Gustavo Lozano 901 ICANN 902 12025 Waterfront Drive, Suite 300 903 Los Angeles 90292 904 US 906 Phone: +1.3103015800 907 Email: gustavo.lozano@icann.org