idnits 2.17.1 draft-lozano-icann-registry-interfaces-07.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 (Jan 15, 2015) is 3389 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 1039, but no explicit reference was found in the text == Unused Reference: 'RFC3688' is defined on line 1048, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-arias-noguchi-dnrd-objects-mapping-05 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 Jan 15, 2015 5 Expires: July 19, 2015 7 ICANN Registry Interfaces 8 draft-lozano-icann-registry-interfaces-07 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 July 19, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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. Monitoring compliance with the New gTLD Base Agreement . . . . 14 65 5.1. Monitoring compliance with Data Escrow Reports . . . . . . 14 66 5.2. Monitoring compliance with Data Escrow Notifications . . . 15 67 5.3. Monitoring compliance with Registry Functions Activity 68 Report . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 5.4. Monitoring compliance with Per-Registrar Transactions 70 Report . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6.1. IIRDEA Result Schema . . . . . . . . . . . . . . . . . . . 17 73 6.2. Report Object . . . . . . . . . . . . . . . . . . . . . . 18 74 6.3. Notification Object . . . . . . . . . . . . . . . . . . . 20 75 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 76 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 22 77 8.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . . 22 78 8.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . . 22 79 8.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . . 23 81 8.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . . 23 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 89 1. Introduction 91 This document describes the interfaces provided by ICANN to Registry 92 Operators in order to fulfill the requirements of Specification 2 and 93 3 of the New gTLD Base Agreement. The interface provided by ICANN to 94 Data Escrow Agents in order to fulfill the requirements of 95 Specification 2 of the New gTLD Base Agreement is also described in 96 this document. 98 Authentication credentials for the interfaces are provided by ICANN 99 to the Registry Operator per TLD. The Registry Operator receives a 100 set of credentials to be used by the Registry Operator and by the 101 Data Escrow Agent for authentication to the after-mentioned 102 interfaces. 104 1.1. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 XML is case sensitive. Unless stated otherwise, XML specifications 111 and examples provided in this document MUST be interpreted in the 112 character case presented in order to develop a conforming 113 implementation. 115 2. Interfaces for Specification 2 - Data Escrow Reporting 117 This section describes the interfaces provided by ICANN to Registry 118 Operators and Data Escrow Agents in order to comply with the 119 reporting provisions detailed in Specification 2 of the New gTLD Base 120 Agreement of the new gTLD Applicant Guidebook 121 [ICANN-GTLD-AGB-20120604]. 123 2.1. Registry Operator Reporting 125 The New gTLD Base Agreement, Specification 2, Part A, Section 7 126 requires Registry Operators to provide ICANN with a written statement 127 that includes a copy of the report generated upon creation of a 128 deposit and a statement that the deposit has been inspected by the 129 Registry Operator and is complete and accurate. 131 In order to comply with this provision, the Registry Operator sends a 132 element to ICANN for each deposit successfully 133 sent to the Data Escrow Agent, using the PUT HTTP verb in the 134 interface provided by ICANN at: 136 https://ry-api.icann.org/report/registry-escrow-report// 138 Where: 140 * MUST be substituted by the TLD for which the report is 141 being provided. In case of an IDN TLD, the A-label MUST be 142 used. 144 * MUST be substituted by the identifier assigned to this 145 report, which MUST be the same as the "id" attribute from the 146 . 148 Note: The interface supports overwriting the information of a 149 particular report "id" to support async interfaces between 150 Registry Operators and Data Escrow Agents. 152 2.1.1. object 154 The element contains the following child elements: 156 o An element contains the identifier assigned to this report. 157 The report identifier MUST be the same as the "id" attribute from 158 the . 160 o A element contains the version of the specification 161 used. This value MUST be 1. 163 o A element contains the version of the Registry 164 Data Escrow Specification (e.g. 165 draft-arias-noguchi-registry-data-escrow-06) used to create the 166 deposit. After the specification is published as an RFC, the 167 value MUST be the RFC number assigned by IANA. 169 o A element contains the version of the Domain 170 Name Registration Data (DNRD) Objects Mapping (e.g. 171 draft-arias-noguchi-dnrd-objects-mapping-05) used to create the 172 deposit. After the specification is published as an RFC, the 173 value MUST be the RFC number assigned by IANA. 175 o A element contains the value of the "resend" attribute of 176 the . 178 o A element contains the date and time that the deposit was 179 created by the Registry Operator. 181 o A element is used to identify the kind of deposit: FULL, 182 INCR (Incremental) or DIFF (Differential). 184 o A element contains the data and time corresponding to 185 the Timeline Watermark ( element) of the . 187 o A
element contains the header of the . 189 Example object: 191 192 195 20101017001 196 1 197 198 draft-arias-noguchi-registry-data-escrow-06 199 200 201 draft-arias-noguchi-dnrd-objects-mapping-05 202 203 0 204 2010-10-17T00:15:00.0Z 205 FULL 206 2010-10-17T00:00:00Z 207 208 test 209 2 211 1 213 1 215 1 217 218 1 220 1 222 1 224 225 226 228 2.2. Data Escrow Agent Reporting 230 The New gTLD Base Agreement, Specification 2, Part B, Section 7 231 requires Data Escrow Agents, to deliver to ICANN a notification every 232 time a successfully processed deposit is received from the Registry 233 Operator regardless of the final status of the verification process. 235 There are three types of notices: 237 Deposit Receipt Failure Notice (DRFN): generated by the Escrow 238 Agent when no deposit is received pursuant to the schedule 239 specified in Specification 2. 241 Deposit Verification Failure Notice (DVFN): generated by the 242 Escrow Agent when a deposit is received, but the final result of 243 the verification process is failure. 245 Deposit Verification Pass Notice (DVPN): generated by the Escrow 246 Agent when a deposit is received and the final result of the 247 verification process is success. 249 In order to comply with this provision, the Data Escrow Agent sends a 250 element to ICANN, using the POST HTTP 251 verb in the interface provided by ICANN at: 253 https://ry-api.icann.org/report/escrow-agent-notification/ 255 Where: 257 * MUST be substituted by the TLD for which the notification 258 is being provided. In case of an IDN TLD, the A-label MUST be 259 used. 261 If by 23:59 UTC, a deposit has not been successfully processed 262 regardless of the final status of the verification process, a 263 with DRFN status MUST be send to 264 ICANN. 266 2.2.1. object 268 The element contains the following child elements: 270 o A element contains the name of the Data Escrow Agent. 272 o A element contains the version of the specification 273 used. This value MUST be 1. 275 o A element contains the reported date. In case of a DVPN 276 or DVFN notification this value MUST be the date of the 277 element of the . In case of a DRFN deposit 278 notification, this value MUST be the date for which no deposit was 279 received from the Registry Operator. 281 o A element is used to specify the status of . 282 The possible values of status are: DVPN, DVFN and DRFN. 284 * DVPN 286 * DVFN 288 * DRFN 290 o An OPTIONAL element contains the date and time that the 291 deposit was successful received by the Data Escrow Agent. In case 292 of a DRFN deposit notification this element MUST NOT be present. 294 o An OPTIONAL element contains the date and time that the 295 deposit was successfully validated by the Data Escrow Agent. In 296 case of a DRFN deposit notification this element MUST NOT be 297 present. 299 o An OPTIONAL element contains the date of the 300 Timeline Watermark ( element) of the most recent FULL 301 deposit that was successfully validated by the Data Escrow Agent. 302 This element MUST NOT be present if a successfully validated full 303 deposit has never been deposited. 305 o An OPTIONAL element is used by the Data Escrow Agent to 306 provide extended information about the deposit. In case of a DRFN 307 deposit notification this element MUST NOT be present. In case of 308 a DVPN or DVFN deposit notification this element MUST be present. 309 When this element is present, the element MUST 310 be generated by the Data Escrow Agent for the Timeline Watermark 311 ( element) of the deposit being processed. If the 312 deposit being processed is a differential or incremental deposit, 313 the Data Escrow Agent MUST process the last full plus all 314 differentials or last full plus last incremental escrow deposits 315 to generate the element. 317 o Note: In case of a DPVN or DVFN deposit notification, the 318 is used as unique identifier. 320 Example object: 322 323 327 Escrow Agent Inc. 328 1 329 2010-10-17 330 DVPN 331 332 2010-10-17T03:15:00.0Z 333 334 335 2010-10-17T05:15:00.0Z 336 337 338 2010-10-14 339 340 341 20101017001 342 1 343 344 draft-arias-noguchi-registry-data-escrow-06 345 346 347 draft-arias-noguchi-dnrd-objects-mapping-05 348 349 0 350 2010-10-17T00:15:00.0Z 351 FULL 352 2010-10-17T00:00:00Z 353 354 test 355 2 357 1 359 1 361 1 363 364 1 366 1 368 1 370 371 372 373 375 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting 377 Specification 3 of the New gTLD Base Agreement requires Registry 378 Operators to provide a set of monthly reports per gTLD. Two type of 379 reports are required to be sent by Registries: Per-Registrar 380 Transactions Report and Registry Functions Activity Report. This 381 section specifies the interfaces provided by ICANN to automate the 382 upload of these reports by Registry Operators. 384 The cut-off date for the reception of the reports specified in 385 specification 3 is defined in the New gTLD Base Agreement of the new 386 gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. Before the cut- 387 off date the Registry Operator could replace a successfully validated 388 report as many times as it needs. 390 3.1. Per-Registrar Transactions Report 392 The Per-Registrar Transactions Report is a CSV report described in 393 Section 1 of Specification 3. 395 In order to comply with this provision, the Registry Operator sends a 396 CSV report on a monthly basis as described in the New gTLD Base 397 Agreement, using the PUT HTTP verb in the interface provided by ICANN 398 at: 400 https://ry-api.icann.org/report/registrar-transactions// 401 403 Where: 405 * MUST be substituted by the TLD for which the reports is 406 being provided. In case of an IDN TLD, the A-label MUST be 407 used. 409 * MUST be substituted by the month for which the reports 410 is being provided in the form of YYYY-MM. Where 'YYYY' is the 411 year and 'MM' is the two digit month number. For example: 412 2013-03 414 3.2. Registry Functions Activity Report 416 The Registry Functions Activity Report is a CSV report described in 417 Section 2 of Specification 3 of the New gTLD Base Agreement of the 418 new gTLD Applicant Guidebook [ICANN-GTLD-AGB-20120604]. 420 In order to comply with this provision, the Registry Operator sends a 421 CSV report on a monthly basis as described in the New gTLD Base 422 Agreement, using the PUT HTTP verb in the interface provided by ICANN 423 at: 425 https://ry-api.icann.org/report/registry-functions-activity// 426 428 Where: 430 * MUST be substituted by the TLD for which the report is 431 being provided. In case of an IDN TLD, the A-label MUST be 432 used. 434 * MUST be substituted by the month for which the reports 435 is being provided in the form of YYYY-MM. Where 'YYYY' is the 436 year and 'MM' is the two digit month number. For example: 437 2013-03 439 4. Interface details 441 The client MUST set "text/xml" in the HTTP header Content-type when 442 using the Data Escrow Agent Reporting and Registry Operator Reporting 443 interfaces. The client MUST set "text/csv" in the HTTP header 444 Content-type when using the Per-Registrar Transactions Report 445 Registry Functions Activity Report interfaces. 447 The Data Escrow Agent Reporting and Registry Operator Reporting 448 interfaces support HTTP streams only (HTTP multi-part forms are not 449 supported). 451 After successfully receiving an input in any of the interfaces 452 described above, ICANN validates it and provides a result code in the 453 same HTTP transaction. The interface set the HTTP header Content- 454 type: text/xml, when sending the IIRDEA result. 456 o The interface provides a HTTP/200 status code if the interface was 457 able to receive the input and no problem was found in the input. 459 o The interface provides a HTTP/400 if the input is incorrect or the 460 syntax of the input is invalid. 462 o The interface provides a HTTP/401 status code if the credentials 463 provided does not authorize the Registry Operator to upload a 464 report for that . 466 o The interface provides a HTTP/403 status code if the credentials 467 provided are valid but are being used to access a resource that 468 permission is not granted for or the connecting IP address is not 469 whitelisted for the . 471 o The interface provides a HTTP/500 status code if the system is 472 experiencing a general failure. The sending party is responsible 473 to send the input again. 475 After sending the result code, the interface closes the TCP 476 connection. 478 4.1. IIRDEA Result Object 480 After processing the input provided in any of the interfaces 481 described in this document, a response object as defined by the 482 schema in Section 6 is provided in the HTTP Entity-body when an HTTP/ 483 200 and HTTP/400 status code is sent by the interface. 485 An example of a response object is presented below: 487 488 489 490 The structure of the report is invalid. 491 492 'XX' could not be parsed as a number (line: 2 column:3) 493 494 495 497 The following sections provide the IIRDEA Result Codes per interface: 499 4.1.1. Registry Operator Reporting 501 The following table lists the result codes of the interface: 503 +---------+---------------------------------------------------------+ 504 | Result | Message | 505 | Code | | 506 +---------+---------------------------------------------------------+ 507 | 1000 | No ERRORs were found and the report has been accepted | 508 | | by ICANN. | 509 | 2001 | The report did not validate against the schema. | 510 | 2004 | Report for a date in the future. The and | 511 | | date should not be in the future. | 512 | 2005 | Version is not supported. | 513 | 2006 | The in the element and the in the | 514 | | URL path do not match. | 515 | 2007 | Interface is disabled for this TLD. | 516 | 2008 | The and date should not be before | 517 | | the creation date of the TLD in the system. | 518 | 2202 | The in the
and the in the URL path | 519 | | do not match. | 520 | 2205 | Report regarding a differential deposit received for a | 521 | | Sunday (). | 522 | 2206 | csvDomain and rdeDomain count provided in the
. | 523 +---------+---------------------------------------------------------+ 525 Data Escrow Reporting Result Codes 527 4.1.2. Data Escrow Agent Reporting 529 The following table lists the result codes of the interface: 531 +--------+----------------------------------------------------------+ 532 | Result | Message | 533 | Code | | 534 +--------+----------------------------------------------------------+ 535 | 1000 | No ERRORs were found and the notification has been | 536 | | accepted by ICANN. | 537 | 2001 | The notification did not validate against the schema. | 538 | 2002 | A DVPN notification exists for that date (). | 539 | 2004 | Notification for a date in the future. The and | 540 | | and date should not be in the | 541 | | future. | 542 | 2005 | Version is not supported. | 543 | 2007 | Interface is disabled for this TLD. | 544 | 2008 | The and and date should | 545 | | not be before the creation date of the TLD in the | 546 | | system. | 547 | 2201 | The and in the notification do not | 548 | | match. | 549 | 2202 | The in the
and the in the URL path | 550 | | do not match. | 551 | 2203 | A Deposit Verification Pass Notice (DVPN) notification | 552 | | was received, but the Domain Name count is missing in | 553 | | the
. | 554 | 2204 | The notification for the report "id" already exists. | 555 | 2205 | Notification regarding a differential deposit received | 556 | | for a Sunday (). | 557 | 2206 | csvDomain and rdeDomain count provided in the
. | 558 | 2207 | A DVPN or DVFN was received, but the element is | 559 | | missing in the notification. | 560 | 2208 | A DRFN was received, but a element exists in | 561 | | the notification. | 562 +--------+----------------------------------------------------------+ 564 Data Escrow Reporting Result Codes 566 4.1.3. Per-Registrar Transactions Report 568 The following table lists the result codes of the interface: 570 +-----------+-------------------------------------------------------+ 571 | Result | Message | 572 | Code | | 573 +-----------+-------------------------------------------------------+ 574 | 1000 | No ERRORs were found and the report has been accepted | 575 | | by ICANN. | 576 | 2001 | The structure of the report is invalid. | 577 | 2002 | A report for that month already exists, the cut-off | 578 | | date already passed. | 579 | 2003 | Negative numeric value present in the report. | 580 | 2004 | Report for a month in the future. | 581 | 2007 | Interface is disabled for this TLD. | 582 | 2008 | Reported month before the creation date of the TLD in | 583 | | the system. | 584 | 2101 | Incorrect totals present in the report. | 585 | 2102 | Non ICANN accredited registrar present in the report. | 586 | 2103 | Values found in the second field of the totals line. | 587 +-----------+-------------------------------------------------------+ 589 Per-Registrar Transactions Report Result Codes 591 4.1.4. Registry Functions Activity Report 593 The following table lists the result codes of the interface: 595 +-----------+-------------------------------------------------------+ 596 | Result | Message | 597 | Code | | 598 +-----------+-------------------------------------------------------+ 599 | 1000 | No ERRORs were found and the report has been accepted | 600 | | by ICANN. | 601 | 2001 | The structure of the report is invalid. | 602 | 2002 | A report for that month already exists, the cut-off | 603 | | date already passed. | 604 | 2003 | Negative numeric value present in the report. | 605 | 2004 | Report for a month in the future. | 606 | 2007 | Interface is disabled for this TLD. | 607 | 2008 | Reported month before the creation date of the TLD in | 608 | | the system. | 609 +-----------+-------------------------------------------------------+ 611 Registry Functions Activity Report Result Codes 613 5. Monitoring compliance with the New gTLD Base Agreement 615 Registries MAY monitor compliance with Specification 2 and 3 of the 616 New gTLD Base Agreement using the following interfaces that supports 617 the HEAD HTTP verb: 619 5.1. Monitoring compliance with Data Escrow Reports 621 Registries MAY monitor compliance with Specification 2 (Data Escrow 622 Reports) using the following interface: 624 https://ry-api.icann.org/info/report/registry-escrow-report// 625 627 Where: 629 * MUST be substituted by the TLD being queried. In case of 630 an IDN TLD, the A-label MUST be used. 632 * MUST be substituted by the day being queried. For 633 example: 2013-03-02 635 Possible results are: 637 * The interface provides a HTTP/200 status code, if a 638 syntactically valid data escrow report was received for the 639 queried date. 641 * The interface provides a HTTP/404 status code, if a 642 syntactically valid data escrow report has not been received 643 for the queried date. 645 5.2. Monitoring compliance with Data Escrow Notifications 647 Registries and Data Escrow Agents MAY monitor compliance with 648 Specification 2 (Data Escrow Notifications) using the following 649 interface: 651 https://ry-api.icann.org/info/report/escrow-agent-notification/ 652 / 654 Where: 656 * MUST be substituted by the TLD being queried. In case of 657 an IDN TLD, the A-label MUST be used. 659 * MUST be substituted by the day being queried. For 660 example: 2013-03-02 662 Possible results are: 664 * The interface provides a HTTP/200 status code, if a 665 syntactically valid data escrow notification was received for 666 the queried date. 668 * The interface provides a HTTP/404 status code, if a 669 syntactically valid data escrow notification has not been 670 received for the queried date. 672 5.3. Monitoring compliance with Registry Functions Activity Report 674 Registries MAY monitor compliance with Specification 3 (Registry 675 Functions Activity Report) using the following interface: 677 https://ry-api.icann.org/info/report/registry-functions-activity/ 678 / 680 Where: 682 * MUST be substituted by the TLD being queried. In case of 683 an IDN TLD, the A-label MUST be used. 685 * MUST be substituted by the month being queried. For 686 example: 2013-03 688 Possible results are: 690 * The interface provides a HTTP/200 status code, if a 691 syntactically valid registry functions activity report was 692 received for the queried month. 694 * The interface provides a HTTP/404 status code, if a 695 syntactically valid registry functions activity report has not 696 been received for the queried month. 698 5.4. Monitoring compliance with Per-Registrar Transactions Report 700 Registries MAY monitor compliance with Specification 3 (Per-Registrar 701 Transactions Report) using the following interface: 703 https://ry-api.icann.org/info/report/registrar-transactions// 704 706 Where: 708 * MUST be substituted by the TLD being queried. In case of 709 an IDN TLD, the A-label MUST be used. 711 * MUST be substituted by the month being queried. For 712 example: 2013-03 714 Possible results are: 716 * The interface provides a HTTP/200 status code, if a 717 syntactically valid per-registrar transactions report was 718 received for the queried month. 720 * The interface provides a HTTP/404 status code, if a 721 syntactically valid per-registrar transactions report has not 722 been received for the queried month. 724 6. Formal Syntax 726 The schema of the IIRDEA, Reports and Notifications are presented 727 here. 729 The BEGIN and END tags are not part of the schema; they are used to 730 note the beginning and ending of the schema for URI registration 731 purposes. 733 6.1. IIRDEA Result Schema 735 Copyright (c) 2012 IETF Trust and the persons identified as authors 736 of the code. All rights reserved. 738 Redistribution and use in source and binary forms, with or without 739 modification, are permitted provided that the following conditions 740 are met: 742 o Redistributions of source code must retain the above copyright 743 notice, this list of conditions and the following disclaimer. 745 o Redistributions in binary form must reproduce the above copyright 746 notice, this list of conditions and the following disclaimer in 747 the documentation and/or other materials provided with the 748 distribution. 750 o Neither the name of Internet Society, IETF or IETF Trust, nor the 751 names of specific contributors, may be used to endorse or promote 752 products derived from this software without specific prior written 753 permission. 755 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 756 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 757 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 758 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 759 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 760 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 761 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 762 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 763 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 764 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 765 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 767 BEGIN 768 769 774 775 776 ICANN interfaces for registries and data escrow agents 777 778 780 782 783 784 785 786 788 789 790 791 792 793 794 796 797 798 799 800 801 802 803 END 805 6.2. Report Object 807 Copyright (c) 2011 IETF Trust and the persons identified as authors 808 of the code. All rights reserved. 810 Redistribution and use in source and binary forms, with or without 811 modification, are permitted provided that the following conditions 812 are met: 814 o Redistributions of source code must retain the above copyright 815 notice, this list of conditions and the following disclaimer. 817 o Redistributions in binary form must reproduce the above copyright 818 notice, this list of conditions and the following disclaimer in 819 the documentation and/or other materials provided with the 820 distribution. 822 o Neither the name of Internet Society, IETF or IETF Trust, nor the 823 names of specific contributors, may be used to endorse or promote 824 products derived from this software without specific prior written 825 permission. 827 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 828 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 829 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 830 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 831 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 832 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 833 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 834 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 835 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 836 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 837 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 839 BEGIN 840 841 848 850 853 854 855 Registry Data Escrow Report schema 856 857 859 860 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 END 879 6.3. Notification Object 881 Copyright (c) 2011 IETF Trust and the persons identified as authors 882 of the code. All rights reserved. 884 Redistribution and use in source and binary forms, with or without 885 modification, are permitted provided that the following conditions 886 are met: 888 o Redistributions of source code must retain the above copyright 889 notice, this list of conditions and the following disclaimer. 891 o Redistributions in binary form must reproduce the above copyright 892 notice, this list of conditions and the following disclaimer in 893 the documentation and/or other materials provided with the 894 distribution. 896 o Neither the name of Internet Society, IETF or IETF Trust, nor the 897 names of specific contributors, may be used to endorse or promote 898 products derived from this software without specific prior written 899 permission. 901 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 902 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 903 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 904 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 905 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 906 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 907 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 908 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 909 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 910 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 911 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 913 BEGIN 914 915 921 924 925 926 Registry Data Escrow Notification schema 927 928 930 931 933 934 935 936 937 938 939 940 941 942 943 944 945 947 948 949 950 951 952 954 955 956 957 958 959 960 961 962 END 964 7. Acknowledgements 966 Special suggestions that have been incorporated into this document 967 were provided by David Kipling, James Gould, Gregory Zaltsman, Brett 968 Carr and Harel Efraim. 970 8. Change History 972 8.1. Version 00 974 Initial version. 976 8.2. Version 01 978 o and moved from 979 escrow drafts to this draft 981 o Added to 983 o element of is now OPTIONAL 985 o Added element to 987 o and added to the draft 989 o Several report elements are OPTIONAL to support async interfaces 990 between Registry Operators and Data Escrow Agents 992 o Added and to registry-escrow-report interface in order 993 to make the interface idempotent and support async RyO-DEA 994 interfaces 996 o Added to escrow-agent-notification interface 998 o The escrow-agent-notification uses POST and not PUT, this has been 999 fixed 1001 o Several clarifications 1003 8.3. Version 02 1005 o Added and updated several result codes. 1007 o Added element. 1009 o Added Content-type definition. 1011 8.4. Version 03 1013 o Added several result codes. 1015 o unsignedShort is now used for result code in iirdea schema. 1017 o Enumeration was removed from the iirdea schema. 1019 8.5. Version 04 1021 o Added result codes: 2207 and 2208. 1023 o Removed result codes: 2203. 1025 o Added clarification regarding the support of HTTP streams. 1027 9. IANA Considerations 1029 TODO 1031 10. Security Considerations 1033 TODO 1035 11. References 1037 11.1. Normative References 1039 [I-D.arias-noguchi-dnrd-objects-mapping] 1040 Arias, F., Lozano, G., Noguchi, S., Gould, J., and C. 1041 Thippeswamy, "Domain Name Registration Data (DNRD) Objects 1042 Mapping", draft-arias-noguchi-dnrd-objects-mapping-05 1043 (work in progress), September 2013. 1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1046 Requirement Levels", BCP 14, RFC 2119, March 1997. 1048 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1049 January 2004. 1051 11.2. Informative References 1053 [ICANN-GTLD-AGB-20120604] 1054 ICANN, "gTLD Applicant Guidebook Version 2012-06-04", 1055 June 2012, . 1058 Author's Address 1060 Gustavo Lozano 1061 ICANN 1062 12025 Waterfront Drive, Suite 300 1063 Los Angeles 90292 1064 US 1066 Phone: +1.3103015800 1067 Email: gustavo.lozano@icann.org