idnits 2.17.1 draft-lozano-icann-registry-interfaces-17.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 (Mar 20, 2022) is 768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Lozano 3 Internet-Draft E. Alvarez 4 Intended status: Informational ICANN 5 Expires: September 21, 2022 Mar 20, 2022 7 ICANN Registry Interfaces 8 draft-lozano-icann-registry-interfaces-17 10 Abstract 12 This document describes the technical details of the interfaces 13 provided by the Internet Corporation for Assigned Names and Numbers 14 (ICANN) to its contracted parties to fulfill reporting requirements. 15 The interfaces provided by ICANN to Data Escrow Agents and Registry 16 Operators to fulfill the requirements of Specifications 2 and 3 of 17 the gTLD Base Registry Agreement are described in this document. 18 Additionally, interfaces for retrieving the IP addresses of the probe 19 nodes used in the SLA Monitoring System (SLAM) and interfaces for 20 supporting maintenance window objects are described in this document. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 21, 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.2. Date and Time . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Common elements used in this specification . . . . . . . 4 60 1.4. Object Description . . . . . . . . . . . . . . . . . . . 4 61 2. Interfaces for Specification 2 - Data Escrow Reporting . . . 11 62 2.1. Registry Operator Reporting . . . . . . . . . . . . . . . 12 63 2.2. Data Escrow Agent Reporting . . . . . . . . . . . . . . . 13 64 2.3. Monitoring the reporting status . . . . . . . . . . . . . 15 65 3. Interfaces of Specification 3 - Registry Operator Monthly 66 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 3.1. Per-Registrar Transactions Report . . . . . . . . . . . . 17 68 3.2. Registry Functions Activity Report . . . . . . . . . . . 17 69 3.3. Monitoring the reporting status . . . . . . . . . . . . . 18 70 4. Maintenance Windows . . . . . . . . . . . . . . . . . . . . . 19 71 4.1. Creating and updating a maintenance window . . . . . . . 19 72 4.2. Deleting a maintenance window . . . . . . . . . . . . . . 19 73 4.3. Getting the persisted data for a maintenance window . . . 20 74 4.4. Getting a list of maintenance windows . . . . . . . . . . 20 75 5. Interfaces for the SLAM Probe Node List . . . . . . . . . . . 21 76 6. Technical details of the interfaces . . . . . . . . . . . . . 22 77 6.1. General technical details . . . . . . . . . . . . . . . . 22 78 6.2. Specific technical details . . . . . . . . . . . . . . . 23 79 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 29 80 7.1. RRI IIRDEA Result Schema . . . . . . . . . . . . . . . . 29 81 7.2. RRI Report Object . . . . . . . . . . . . . . . . . . . . 30 82 7.3. RRI Notification Object . . . . . . . . . . . . . . . . . 31 83 7.4. RRI Reporting Summary Object . . . . . . . . . . . . . . 32 84 7.5. RRI Notifications Object . . . . . . . . . . . . . . . . 34 85 7.6. RRI Reports Object . . . . . . . . . . . . . . . . . . . 35 86 7.7. Maintenance Window . . . . . . . . . . . . . . . . . . . 36 87 7.8. SLAM Probe Node List . . . . . . . . . . . . . . . . . . 38 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 89 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 39 90 9.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 39 91 9.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 39 92 9.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 39 93 9.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 40 94 9.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 40 95 9.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 40 96 9.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 40 97 9.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 40 98 9.9. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 40 99 9.10. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 41 100 9.11. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 41 101 9.12. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 41 102 9.13. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 41 103 9.14. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 41 104 9.15. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 41 105 9.16. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 42 106 9.17. Version 16 . . . . . . . . . . . . . . . . . . . . . . . 42 107 9.18. Version 17 . . . . . . . . . . . . . . . . . . . . . . . 42 108 10. Internationalization Considerations . . . . . . . . . . . . . 42 109 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 110 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 46 111 12.1. Implementation in the gTLD space . . . . . . . . . . . . 47 112 13. Security Considerations . . . . . . . . . . . . . . . . . . . 47 113 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 114 14.1. Normative References . . . . . . . . . . . . . . . . . . 47 115 14.2. Informative References . . . . . . . . . . . . . . . . . 48 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 118 1. Introduction 120 This document describes the technical details of the interfaces 121 provided by the Internet Corporation for Assigned Names and Numbers 122 (ICANN) to other contracted parties to fulfill reporting 123 requirements. The interface provided by ICANN to Registry Operators 124 and Data Escrow Agents to fulfill the requirements of Specifications 125 2 and 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] 126 are described in this document. Additionally, interfaces for 127 retrieving the IP addresses of the probe nodes used in the SLA 128 Monitoring System (SLAM) and interfaces for supporting maintenance 129 window objects are described in this document. 131 Extensible Markup Language (XML) 1.0 as described in 132 [W3C.REC-xml-20081126] and XML Schema notation as described in 133 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are 134 used in this specification. 136 The provisioning of credentials and authentication methods used in 137 the interfaces are outside of this document's scope. 139 1.1. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 XML is case sensitive. Unless stated otherwise, XML specifications 148 and examples provided in this document MUST be interpreted in the 149 character case presented to develop a conforming implementation. 151 1.2. Date and Time 153 Numerous fields indicate "date and time", such as the creation and 154 receipt dates for data escrow deposits. These fields SHALL contain 155 timestamps indicating the date and time in UTC as specified in 156 [RFC3339], with no offset from the zero meridian. 158 1.3. Common elements used in this specification 160 Common elements used in this specification are explained in this 161 section. 163 o : The base URL used in the reporting interfaces examples 164 must be replaced with the URL indicated by ICANN. 166 1.4. Object Description 168 This section describes the base objects supported by this 169 specification. 171 1.4.1. object 173 The ICANN interfaces for registries and data escrow agents (IIRDEA) 174 object is used to provide information on the result 175 of a verification process when interacting with the interfaces. The 176 XML Schema for the object can be found in 177 Section 7.1. 179 The object contains the following attributes and 180 child elements: 182 o A "code" attribute whose value is a four-digit decimal number that 183 identifies the result of a process. Available result code values 184 MUST be defined for the corresponding process. 186 o An OPTIONAL "domainCount" attribute indicates the number of domain 187 names related to the reported result. 189 o A element contains a human-readable description of the 190 result code. 192 o An OPTIONAL element that includes additional details 193 on the result conditions. 195 An example of a object is presented below: 197 198 The structure of the report is invalid. 199 200 'XX' could not be parsed as a number (line: 2 column:3) 201 202 204 1.4.2. object 206 The contents of a data escrow deposit are described using a 207 object. The XML Schema for the 208 object can be found in Section 7.2. 210 The object contains the following child elements: 212 o An element that contains the identifier assigned to this 213 report. The report identifier MUST be the same as the "id" 214 attribute from the . If the data escrow deposit does not 215 include a unique identifier, the Data Escrow Agent MUST generate a 216 unique identifier to reference the data escrow deposit and use it 217 in the element. 219 o A element contains the version of the specification 220 used. This value MUST be 1. 222 o A element contains the version of the Data Escrow 223 Specification (e.g., RFC8909) used to create the deposit. After 224 the specification is published as an RFC, the value MUST be the 225 RFC number assigned by IANA. 227 o An OPTIONAL element contains the version of the 228 Domain Name Registration Data (DNRD) Objects Mapping (e.g., 229 RFC9022) used to create the deposit. After the specification is 230 published as an RFC, the value MUST be the RFC number assigned by 231 IANA. The element MUST be included if the 232 deposit was created using any version of the DNRD objects mapping 233 specification (see [RFC9022]). 235 o A element contains the value of the "resend" attribute of 236 the . 238 o A element contains the date and time that the Registry 239 Operator created the deposit. 241 o A element is used to identify the kind of deposit: FULL, 242 INCR (Incremental), or DIFF (Differential). 244 o A element contains the date and time corresponding to 245 the Timeline Watermark ( element) of the . 247 o A element contains the header of the 248 as defined in [RFC9022]. 250 An example of a object is available in 251 Section 2.1. 253 1.4.3. object 255 The object is used by Data Escrow 256 Agents to document the result of the data escrow deposit verification 257 process. The XML Schema for the 258 object can be found in Section 7.3. 260 The object contains the following 261 child elements: 263 o A element contains the name of the Data Escrow Agent. 265 o A element contains the version of the specification 266 used. This value MUST be 1. 268 o A element contains the reported date. In the case of a 269 DVPN or DVFN notification, this value MUST be the date of the 270 element of the . In the case of a DRFN 271 deposit notification, this value MUST be the date for which no 272 deposit was received from the Registrar or Registry Operator. 274 o A element is used to specify the status of . 275 The possible values of status are DVPN, DVFN, and DRFN. The three 276 types of notices determine the value for the element: 278 * Deposit Receipt Failure Notice (DRFN): generated by the Data 279 Escrow Agent when no deposit is received according to the data 280 escrow deposit schedule. 282 * Deposit Verification Failure Notice (DVFN): generated by the 283 Data Escrow Agent when a deposit is received, but the final 284 result of the verification process is a failure. 286 * Deposit Verification Pass Notice (DVPN): generated by the Data 287 Escrow Agent when a deposit is received, and the final result 288 of the verification process is a success. 290 o An OPTIONAL element contains the errors detected during 291 the data escrow deposit verification process performed by the Data 292 Escrow Agent. The element includes one or more 293 elements as defined in Section 1.4.1. In the case 294 of a DRFN or DVPN deposit notification, the element MUST 295 NOT be present. 297 o An OPTIONAL element contains the date and time that the 298 Data Escrow Agent successfully received the deposit. In the case 299 of a DRFN deposit notification, this element MUST NOT be present. 301 o An OPTIONAL element contains the date and time that the 302 Data Escrow Agent processed the deposit for validation. In the 303 case of a DRFN deposit notification, this element MUST NOT be 304 present. 306 o An OPTIONAL element contains the date of the 307 Timeline Watermark ( element) of the most recent FULL 308 deposit that the Data Escrow Agent successfully validated. This 309 element MUST NOT be present if a successfully validated full 310 deposit has never been deposited. 312 o An OPTIONAL element is used by the Data Escrow 313 Agent to provide extended information about the deposit. In the 314 case of a DRFN deposit notification, this element MUST NOT be 315 present. In the case of a DVPN or DVFN deposit notification, this 316 element MUST be present. When this element is present, the 317 element MUST be generated by the Data Escrow 318 Agent for the Timeline Watermark ( element) of the 319 deposit being processed. If the deposit being processed is a 320 differential or incremental deposit, the Data Escrow Agent MUST 321 create a dataset by following Section 5.2 of [RFC8909] to generate 322 the element. 324 o Note: In the case of a DVPN or DVFN deposit notification, the 325 is used as a unique identifier. 327 An example of a object is available in 328 Section 2.2. 330 1.4.4. Object 332 Interfaces that support monitoring the reporting status for a 333 specific repository provide a object as 334 defined by the schema in Section 7.4 in the HTTP Entity-body when a 335 HTTP/200 code is sent by the interface. 337 The element includes the following child 338 elements: 340 o A choice of one of the elements as defined in the 341 "rdeHeader:repositoryTypeGroup" (see [RFC9022]) that indicates the 342 unique identifier for the repository being escrowed. 344 o A element with the date and time in which the 345 queried repository was created in the system. 347 o A OPTIONAL element indicating the current Data 348 Escrow Deposit schedule for the queried repository. Possible 349 values are "None", "Weekly", and "Daily". 351 o An OPTIONAL element indicating the date of the 352 Timeline Watermark ( element) of the most recent FULL 353 deposit that was successfully validated for the queried repository 354 as notified by the Data Escrow Agent. 356 o A element with a element for each 357 report type for the queried repository. Each 358 element includes the following child elements: 360 * : a string value indicating the report type to which the 361 information provided pertains. 363 * : a boolean value indicating if the report type is 364 enabled for the repository. 366 * : a string value indicating the reporting status. A 367 value of "ok" indicates no reporting issues in the 368 corresponding report type, otherwise the value of 369 "unsatisfactory" is shown. 371 * An OPTIONAL element included only when the 372 element has a value of "unsatisfactory", and includes an empty 373 element for each date with a reporting problem found in 374 the corresponding report type. Each element includes a 375 REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED 376 "description" attribute to describe the issue. The possible 377 values to describe each reporting issue are: 379 + "Missing_Deposit_Full": If the latest notification received 380 from the Data Escrow Agent for the date indicates that a 381 scheduled "Full" deposit was not submitted by the repository 382 owner. 384 + "Missing_Deposit_Diff": If the latest notification received 385 from the Data Escrow Agent for the date indicates that a 386 scheduled "Differential" deposit was not submitted by the 387 repository owner. 389 + "Invalid_Deposit_Full": If the latest notification received 390 from the Data Escrow Agent for the date indicates that a 391 "Full" deposit was received by the Data Escrow Agent, but 392 failed the verification process. 394 + "Invalid_Deposit_Diff": If the latest notification received 395 from the Data Escrow Agent for the date indicates that a 396 "Differential" deposit was received by the Data Escrow 397 Agent, but failed the verification process. 399 + "No_Report_Received" If no report has been received for the 400 date. 402 o A element to indicate the date and time the reporting 403 status response was created. 405 1.4.5. Object 407 Interfaces that support monitoring and retrieving Data Escrow Reports 408 received, provide a object as defined by the 409 schema in Section 7.6 in the HTTP Entity-body when an HTTP/200 code 410 is sent by the interface. 412 The element includes a list of 413 objects, one for each 414 successfully received by ICANN. 416 Each object includes the following child 417 elements: 419 o A element to indicate the date and time in which ICANN 420 received the report. 422 o A element as defined in Section 1.4.2 as 423 received by ICANN. 425 1.4.6. Object 427 Interfaces that support monitoring and retrieving Data Escrow 428 Notifications received from Data Escrow Agents, provide a 429 object as defined by the schema in 430 Section 7.5 in the HTTP Entity-body when an HTTP/200 code is sent by 431 the interface. 433 The element includes a list of 434 objects, one for each 435 successfully received by ICANN. 437 Each object includes the 438 following child elements: 440 o A element to indicate the date and time in which ICANN 441 received the notification. 443 o A element as defined in 444 Section 1.4.3 as received by ICANN. 446 1.4.7. object 448 The object is used to provide details of an 449 instance of a maintenance window. The maintenance window is 450 identified by a Universally Unique IDentifier version 4 (see 451 [RFC4122]) captured in the attribute "scheduleId". An additional 452 attribute "enabled" defined as a boolean can be used to enable (value 453 of true) or disable (value of false) the maintenance window. The XML 454 Schema for the object can be found in 455 Section 7.7. 457 The object contains the following child elements: 459 o A element contains a descriptive name of the maintenance 460 window. 462 o A element contains a description of the maintenance 463 window. 465 o A element contains the version of the specification 466 used. This value MUST be 1. 468 o A element contains the date and time when the 469 maintenance window starts being active. 471 o A element contains the date and time when the 472 maintenance window ends being active. 474 An example of a object is available in Section 4. 476 1.4.8. object 478 The object is used to provide the list of 479 maintenance window objects. The XML Schema for the 480 object can be found in Section 7.7. 482 The object contains the following child 483 elements: 485 o Zero or more elements. See, Section 1.4.7 for 486 the definition of . 488 An example of a object is available in 489 Section 4. 491 1.4.9. object 493 The object is used to provide the list of 494 probe nodes used by the SLA Monitoring System. The XML Schema for 495 the object can be found in Section 7.8. 497 The object contains the following child 498 elements: 500 o One or more elements. Each element 501 contains the following child elements: 503 * A element contains the name of the city where the node 504 is located. 506 * One or more element contains the IP addresses used in 507 the node to originate test connections. An "ip" attribute 508 contains the string "v4" if the IP address is an IPv4 address 509 or "v6" if the IP address is an IPv6 address. 511 o A element contains the date and time of the last 512 update of the list. 514 o A element contains the version of the specification 515 used. This value MUST be 1. 517 An example of a object is available in 518 Section 5. 520 2. Interfaces for Specification 2 - Data Escrow Reporting 522 This section describes the interfaces provided by ICANN to Registry 523 Operators and Data Escrow Agents to fulfill the reporting 524 requirements detailed in Specification 2 of the gTLD Base Registry 525 Agreement [ICANN-GTLD-RA-20170731]. 527 2.1. Registry Operator Reporting 529 The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], 530 Specification 2, Part A, Section 7 requires Registry Operators to 531 provide ICANN with a written statement that includes a copy of the 532 report generated upon creation of a deposit and a statement that the 533 deposit has been inspected by the Registry Operator and is complete 534 and accurate. 536 In order to satisfy this requirement, the Registry Operator sends to 537 ICANN a object as defined in Section 1.4.2 for 538 each deposit successfully sent to the Data Escrow Agent, using the 539 PUT HTTP verb in the interface provided by ICANN at: 541 /report/registry-escrow-report// 543 Where: 545 * MUST be substituted by the TLD for which the report is 546 being provided. In the case of an IDN TLD, the A-label (see 547 [RFC5890]) MUST be used. 549 * MUST be substituted by the identifier assigned to this 550 report, which MUST be the same as the "id" attribute from the 551 . 553 Note: the interface supports overwriting the information of a 554 particular report to support asynchronous interfaces between 555 Registry Operators and Data Escrow Agents. 557 Example of a object for a data escrow deposit 558 corresponding to a TLD Registry repository: 560 561 564 20101017001 565 1 566 567 RFC8909 568 569 570 RFC9022 571 572 0 573 2010-10-17T00:15:00.0Z 574 FULL 575 2010-10-17T00:00:00Z 576 577 test 578 2 580 1 582 1 584 1 586 587 1 589 1 591 1 593 594 595 597 2.2. Data Escrow Agent Reporting 599 The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], 600 Specification 2, Part B, Section 7 requires Data Escrow Agents to 601 deliver ICANN with a notification object every time a successfully 602 processed deposit is received from the Registry Operator regardless 603 of the final status of the verification process. 605 To satisfy this requirement, the Data Escrow Agent sends to ICANN a 606 object as defined in Section 1.4.3, 607 using the POST HTTP verb in the interface provided by ICANN at: 609 /report/escrow-agent-notification/ 611 Where: 613 * MUST be substituted by the TLD for which the notification 614 is being provided. In the case of an IDN TLD, the A-label (see 615 [RFC5890]) MUST be used. 617 If by 23:59:59 UTC, a deposit has not been successfully processed 618 regardless of the final status of the verification process, a 619 object with DRFN status MUST be sent 620 to ICANN. 622 Example of a object of a Data Escrow 623 Agent notification corresponding to a Registry repository Data Escrow 624 Deposit: 626 627 631 Escrow Agent Inc. 632 1 633 2010-10-17 634 DVPN 635 636 2010-10-17T03:15:00.0Z 637 638 639 2010-10-17T05:15:00.0Z 640 641 642 2010-10-14 643 644 645 20101017001 646 1 647 648 RFC8909 649 650 651 RFC9022 652 653 0 654 2010-10-17T00:15:00.0Z 655 FULL 656 2010-10-17T00:00:00Z 657 658 test 659 1 661 3 663 1 665 3 667 1 669 10 671 0 673 674 675 677 2.3. Monitoring the reporting status 679 Registries MAY monitor the status of the reports described in 680 Specification 2 [ICANN-GTLD-RA-20170731] using the following 681 interfaces that support the HEAD HTTP verb: 683 2.3.1. Monitoring the status of Data Escrow Reports 685 Registries MAY monitor the status of Data Escrow Reports using the 686 following interface: 688 /info/report/registry-escrow-report// 690 Where: 692 * MUST be substituted by the TLD being queried. In the 693 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 695 * MUST be substituted by the day being queried. For 696 example, 2013-03-02. 698 Possible results are: 700 * The interface provides an HTTP/200 status code if a 701 syntactically valid data escrow report was received for the 702 queried date. 704 * The interface provides an HTTP/404 status code if a 705 syntactically valid data escrow report has not been received 706 for the queried date. 708 2.3.2. Monitoring the status of Data Escrow Notifications 710 Registries and Data Escrow Agents MAY monitor the status of Data 711 Escrow Notifications using the following interface: 713 /info/report/escrow-agent-notification// 715 Where: 717 * MUST be substituted by the TLD being queried. In the 718 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 720 * MUST be substituted by the day being queried. For 721 example, 2013-03-02. 723 Possible results are: 725 * The interface provides an HTTP/200 status code if a 726 syntactically valid data escrow notification was received for 727 the queried date. 729 * The interface provides an HTTP/404 status code if a 730 syntactically valid data escrow notification has not been 731 received for the queried date. 733 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting 735 Specification 3 of the gTLD Base Registry Agreement 736 [ICANN-GTLD-RA-20170731] requires Registry Operators to provide a set 737 of monthly reports per gTLD. Two types of reports are required to be 738 sent by Registries: Per-Registrar Transactions Report and Registry 739 Functions Activity Report. This section specifies the interfaces 740 provided by ICANN to automate the upload of these reports by Registry 741 Operators. 743 The cut-off date for the reception of the reports specified in 744 specification 3 is defined in the gTLD Base Registry Agreement 745 [ICANN-GTLD-RA-20170731]. Before the cut-off date, the Registry 746 Operator MAY replace a successfully validated report as many times as 747 needed. 749 3.1. Per-Registrar Transactions Report 751 The Per-Registrar Transactions Report is a CSV report encoded in 752 UTF-8 described in Section 1 of Specification 3 of the gTLD Base 753 Registry Agreement [ICANN-GTLD-RA-20170731]. 755 To satisfy this requirement, the Registry Operator sends a CSV report 756 monthly as described in the gTLD Base Registry Agreement 757 [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the interface 758 provided by ICANN at: 760 /report/registrar-transactions// 762 Where: 764 * MUST be substituted by the TLD for which the report is 765 being provided. In the case of an IDN TLD, the A-label (see 766 [RFC5890]) MUST be used. 768 * MUST be substituted by the month for which the report is 769 being provided in the form of YYYY-MM. Where 'YYYY' is the 770 year, and 'MM' is the two-digit month number. For example, 771 2013-03. 773 3.2. Registry Functions Activity Report 775 The Registry Functions Activity Report is a CSV report encoded in 776 UTF-8 described in Section 2 of Specification 3 of the gTLD Base 777 Registry Agreement [ICANN-GTLD-RA-20170731]. 779 To satisfy this requirement, the Registry Operator sends a CSV report 780 monthly as described in the gTLD Base Registry Agreement 781 [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the interface 782 provided by ICANN at: 784 /report/registry-functions-activity// 786 Where: 788 * MUST be substituted by the TLD for which the report is 789 being provided. In the case of an IDN TLD, the A-label (see 790 [RFC5890]) MUST be used. 792 * MUST be substituted by the month for which the report is 793 being provided in the form of YYYY-MM. Where 'YYYY' is the 794 year, and 'MM' is the two-digit month number. For example, 795 2013-03. 797 3.3. Monitoring the reporting status 799 Registries MAY monitor the status of the reports described in 800 Specification 3 of the gTLD Base Registry Agreement 801 [ICANN-GTLD-RA-20170731] using the following interfaces that support 802 the HEAD HTTP verb: 804 3.3.1. Monitoring the status of Registry Functions Activity Report 806 Registries MAY monitor the status of Registry Functions Activity 807 Report using the following interface: 809 /info/report/registry-functions-activity// 811 Where: 813 * MUST be substituted by the TLD being queried. In the 814 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 816 * MUST be substituted by the month being queried. For 817 example, 2013-03. 819 Possible results are: 821 * The interface provides an HTTP/200 status code if a 822 syntactically valid registry functions activity report was 823 received for the queried month. 825 * The interface provides an HTTP/404 status code if a 826 syntactically valid registry functions activity report has not 827 been received for the queried month. 829 3.3.2. Monitoring the status of the Per-Registrar Transactions Report 831 Registries MAY monitor the status of Per-Registrar Transactions 832 Report using the following interface: 834 /info/report/registrar-transactions// 836 Where: 838 * MUST be substituted by the TLD being queried. In the 839 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 841 * MUST be substituted by the month being queried. For 842 example, 2013-03. 844 Possible results are: 846 * The interface provides an HTTP/200 status code if a 847 syntactically valid per-registrar transactions report was 848 received for the queried month. 850 * The interface provides an HTTP/404 status code if a 851 syntactically valid per-registrar transactions report has not 852 been received for the queried month. 854 4. Maintenance Windows 856 Specification 10 of the gTLD Base Registry Agreement 857 [ICANN-GTLD-RA-20170731] allows Registry Operators to provide notice 858 to ICANN about plans of maintenance. This section specifies the 859 interfaces provided by ICANN to programmatically manage maintenance 860 windows by Registry Operators. 862 4.1. Creating and updating a maintenance window 864 To create or update a previously created maintenance window, the 865 Registry Operator sends a object (see 866 Section 1.4.7) using the PUT HTTP verb in the interface provided by 867 ICANN at: 869 /maintenance-window/// 871 Where: 873 * MUST be substituted by the TLD for which the report is 874 being provided. In the case of an IDN TLD, the A-label (see 875 [RFC5890]) MUST be used. 877 * MUST be substituted by a service for which a 878 maintenance window could be created (e.g., RDDS). 880 * MUST be substituted by a Universally Unique 881 IDentifier version 4 (see [RFC4122]). 883 4.2. Deleting a maintenance window 885 To delete a previously created maintenance window, the Registry 886 Operator uses the DELETE HTTP verb in the interface provided by ICANN 887 at: 889 /maintenance-window/// 891 4.3. Getting the persisted data for a maintenance window 893 To get the persisted data for a maintenance window, the Registry 894 Operator uses the GET HTTP verb in the interface provided by ICANN 895 at: 897 /maintenance-window/// 899 The interface provides an HTTP/200 status code and sets the HTTP 900 header Content-type: text/xml after a successful request, and 901 includes a object as defined in Section 1.4.7. 903 Example of a object of a Maintenance Window: 905 906 908 Maintenance window for RDDS semester II-2017 909 910 Pre-planned maintenance window for RDDS 911 912 2010-10-17T00:15:00.0Z 913 2010-10-17T02:15:00.0Z 914 1 915 917 4.4. Getting a list of maintenance windows 919 To get the list of all the maintenance windows that have not ended 920 yet (see Section 4), the Registry Operator uses the GET HTTP verb in 921 the interface provided by ICANN at: 923 maintenance-window// 925 The interface provides an HTTP/200 status code and sets the HTTP 926 header Content-type: text/xml after a successful request, and 927 includes a object as defined in Section 1.4.8. 929 Example of a : 931 932 934 936 Maintenance window for example 937 Pre-planned maintenance window 1 938 939 2010-10-17T00:15:00.0Z 940 2010-10-17T02:15:00.0Z 941 1 942 943 945 Maintenance window for example 946 Pre-planned maintenance window 2 947 948 2010-10-19T00:15:00.0Z 949 2010-10-19T02:15:00.0Z 950 1 951 952 954 5. Interfaces for the SLAM Probe Node List 956 The current list of probe nodes used by the SLA Monitoring System may 957 be retrieved by using the GET HTTP verb in the interface provided by 958 ICANN at: 960 /slam-probe-nodes/list 962 The interface provides an HTTP/200 status code and sets the HTTP 963 header Content-type: text/xml after a successful request, and 964 includes a object as defined in Section 1.4.9. 966 Example of the response upon successful retrieval of the SLAM Probe 967 Node List: 969 970 972 973 Mumbai 974 192.0.2.1 975 2001:db8:1::1 976 977 978 Seoul 979 198.51.100.1 980 981 2020-11-18T02:23:56-08:00 982 983 1 984 986 6. Technical details of the interfaces 988 This section describes the technical details of the interfaces 989 described in this document. 991 6.1. General technical details 993 This section describes the technical details that apply to all the 994 interfaces described in this document. 996 The following HTTP status codes are returned: 998 o The interface provides an HTTP/401 status code and sets the HTTP 999 header Content-type: text/plain, if the credentials provided do 1000 not authorize the user to perform the action requested for that 1001 . 1003 o The interface provides an HTTP/403 status code and sets the HTTP 1004 header Content-type: text/plain, if the user attempts to access a 1005 resource that permission is not granted for, or the connecting IP 1006 address is not authorized for the . 1008 o The interface provides an HTTP/404 status code if the object 1009 referenced in the URL is not found. 1011 o The interface provides an HTTP/405 status code if the interface 1012 does not support the request method. 1014 o The interface provides an HTTP/500 status code and sets the HTTP 1015 header Content-type: text/plain, if the system is experiencing a 1016 general failure. The sending party is responsible for sending the 1017 input again. 1019 o The interface provides an HTTP/501 status code and sets the HTTP 1020 header Content-type: text/plain, if the functionality has not yet 1021 been implemented. 1023 After sending the response, the interfaces close the TCP connection. 1025 The interfaces support HTTP streams only (HTTP multi-part forms are 1026 not supported). 1028 6.2. Specific technical details 1030 This section describes the technical details that apply to the 1031 following interfaces: 1033 o Registry Operator Reporting (see Section 2.1) 1035 o Data Escrow Agent Reporting (see Section 2.2) 1037 o Per-Registrar Transactions Report (see Section 3.1) 1039 o Registry Functions Activity Report (see Section 3.2) 1041 o Creating and updating a maintenance window (see Section 4.1) 1043 o Deleting a maintenance window (see Section 4.2) 1045 The following additional HTTP status codes are returned: 1047 o The interface provides an HTTP/200 status code and sets the HTTP 1048 header Content-type: text/xml, if the interface was able to 1049 receive the input successfully, the client MUST review the 1050 response object (see Section 6.2.1) to verify the result code 1051 after processing the input. 1053 o The interface provides an HTTP/400 status code and sets the HTTP 1054 header Content-type: text/xml, if the input is incorrect or the 1055 syntax of the input is invalid. A response object (see 1056 Section 6.2.1) is included with the input validation failure 1057 details. 1059 Content-type value in the HTTP header: 1061 o The client MUST set "text/xml" in the HTTP header Content-type 1062 when using the interfaces described in Section 2.1, Section 2.2, 1063 Section 4.1, and Section 4.2. 1065 o The client MUST set "text/csv" in the HTTP header Content-type 1066 when using the interfaces described in Section 3.1 and 1067 Section 3.2. 1069 6.2.1. Response Object 1071 After processing the input provided to the interfaces described in 1072 this section, a response object defined in Section 1.4.1 is sent in 1073 the HTTP Entity-body when an HTTP/200 or HTTP/400 status code is sent 1074 by the interface. 1076 An example of a response object upon successful input receipt is 1077 presented below: 1079 HTTP/1.1 200 OK 1080 Content-Type: text/xml 1081 Content-Length: 248 1083 1084 1086 1087 No ERRORs were found and the report has been 1088 accepted by ICANN. 1089 1090 1091 1093 An example of a response object in the event of input error is 1094 presented below: 1096 HTTP/1.1 400 Bad Request 1097 Content-Type: text/xml 1098 Content-Length: 279 1100 1101 1103 1104 The structure of the report is invalid. 1105 1106 'XX' could not be parsed as a number (line: 2 column:3) 1107 1108 1109 1111 The following sections provide the IIRDEA Result Codes per interface: 1113 6.2.1.1. Registry Operator Reporting 1115 The following table lists the result codes of the Registry Operator 1116 Reporting interface (see Section 2.1): 1118 +--------+----------------------------------------------------------+ 1119 | Result | Message | 1120 | Code | | 1121 +--------+----------------------------------------------------------+ 1122 | 1000 | No ERRORs were found, and the report has been accepted | 1123 | | by ICANN. | 1124 | 2001 | The request did not validate against the schema. | 1125 | 2004 | Report for a date in the future. The and | 1126 | | date should not be in the future. | 1127 | 2005 | Version is not supported. | 1128 | 2006 | The in the element and the in the URL | 1129 | | path do not match. | 1130 | 2007 | Interface is disabled for this TLD. | 1131 | 2008 | The and date should not be before | 1132 | | the creation date of the TLD in the system. | 1133 | 2202 | The in the
and the TLD in the URL path do | 1134 | | not match. | 1135 | 2205 | Report regarding a differential deposit received when a | 1136 | | full deposit was expected (). | 1137 | 2206 | csvDomain and rdeDomain count provided in the
. | 1138 | 2209 | Missing required element in the
. | 1139 | 2210 | The value of the "rcdn" attribute in the element | 1140 | | does not match the same or lower level names in the | 1141 | | in the URL path. | 1142 | 2211 | Multiple count elements with the same "uri", "rcdn", and | 1143 | | "registrarId" attribute values provided in the
. | 1144 | 2212 | An invalid NR-LDH label or A-label was found or the | 1145 | | domain name syntax is invalid in the "rcdn" attribute. | 1146 +--------+----------------------------------------------------------+ 1148 Data Escrow Reporting Result Codes 1150 6.2.1.2. Data Escrow Agent Reporting 1152 The following table lists the result codes of the Data Escrow Agent 1153 Reporting interface (see Section 2.2): 1155 +--------+----------------------------------------------------------+ 1156 | Result | Message | 1157 | Code | | 1158 +--------+----------------------------------------------------------+ 1159 | 1000 | No ERRORs were found, and the notification has been | 1160 | | accepted by ICANN. | 1161 | 2001 | The request did not validate against the schema. | 1162 | 2002 | A DVPN notification exists for that date (). | 1163 | 2004 | Notification for a date in the future. The and | 1164 | | and date should not be in the | 1165 | | future. | 1166 | 2005 | Version is not supported. | 1167 | 2007 | Interface is disabled for this TLD. | 1168 | 2008 | The and and date should | 1169 | | not be before the creation date of the TLD in the | 1170 | | system. | 1171 | 2201 | The and in the notification do not | 1172 | | match. | 1173 | 2202 | The in the
and the TLD in the URL path do | 1174 | | not match. | 1175 | 2203 | A Deposit Verification Pass Notice (DVPN) notification | 1176 | | was received, but the Domain Name count is missing in | 1177 | | the
. | 1178 | 2204 | The notification for the report "id" already exists. | 1179 | 2205 | Notification regarding a differential deposit received | 1180 | | when a full deposit was expected (). | 1181 | 2206 | csvDomain and rdeDomain count provided in the
. | 1182 | 2207 | A DVPN or DVFN was received, but the element is | 1183 | | missing in the notification. | 1184 | 2208 | A DRFN was received, but an element exists in | 1185 | | the notification. | 1186 | 2209 | Missing required element in the
. | 1187 | 2210 | The value of the "rcdn" attribute in the element | 1188 | | does not match the same or lower level names in the | 1189 | | in the URL path. | 1190 | 2211 | Multiple count elements with the same "uri", "rcdn", and | 1191 | | "registrarId" attribute values provided in the
. | 1192 | 2212 | An invalid NR-LDH label or A-label was found or the | 1193 | | domain name syntax is invalid in the "rcdn" attribute. | 1194 +--------+----------------------------------------------------------+ 1196 Data Escrow Reporting Result Codes 1198 6.2.1.3. Per-Registrar Transactions Report 1200 The following table lists the result codes of the Per-Registrar 1201 Transactions Report interface (see Section 3.1): 1203 +----------+--------------------------------------------------------+ 1204 | Result | Message | 1205 | Code | | 1206 +----------+--------------------------------------------------------+ 1207 | 1000 | No ERRORs were found, and the report has been accepted | 1208 | | by ICANN. | 1209 | 2001 | The structure of the report is invalid. | 1210 | 2002 | A report for that month already exists, the cut-off | 1211 | | date already passed. | 1212 | 2003 | Negative numeric value present in the report. | 1213 | 2004 | Report for a month in the future. | 1214 | 2007 | Interface is disabled for this TLD. | 1215 | 2008 | Reported month before the creation date of the TLD in | 1216 | | the system. | 1217 | 2101 | Incorrect totals present in the report. | 1218 | 2102 | A non-ICANN-accredited registrar is present in the | 1219 | | report. | 1220 | 2103 | Values found in the second field of the totals line. | 1221 | 2105 | The report is not encoded in UTF-8. Note: reports | 1222 | | encoded in US-ASCII are accepted. | 1223 +----------+--------------------------------------------------------+ 1225 Per-Registrar Transactions Report Result Codes 1227 6.2.1.4. Registry Functions Activity Report 1229 The following table lists the result codes of the Registry Functions 1230 Activity Report interface (see Section 3.2): 1232 +----------+--------------------------------------------------------+ 1233 | Result | Message | 1234 | Code | | 1235 +----------+--------------------------------------------------------+ 1236 | 1000 | No ERRORs were found, and the report has been accepted | 1237 | | by ICANN. | 1238 | 2001 | The structure of the report is invalid. | 1239 | 2002 | A report for that month already exists, the cut-off | 1240 | | date already passed. | 1241 | 2003 | Negative numeric value present in the report. | 1242 | 2004 | Report for a month in the future. | 1243 | 2007 | Interface is disabled for this TLD. | 1244 | 2008 | Reported month before the creation date of the TLD in | 1245 | | the system. | 1246 | 2105 | The report is not encoded in UTF-8. Note: reports | 1247 | | encoded in US-ASCII are accepted. | 1248 +----------+--------------------------------------------------------+ 1250 Registry Functions Activity Report Result Codes 1252 6.2.1.5. Maintenance Window Management 1254 The following table lists the result codes of the Maintenance Window 1255 Management interface (see Section 4): 1257 +--------+-----+--------+-----+-------------------------------------+ 1258 | Result | PUT | DELETE | GET | Message | 1259 | Code | | | | | 1260 +--------+-----+--------+-----+-------------------------------------+ 1261 | 1000 | * | * | | No ERRORs were found, and the | 1262 | | | | | report has been accepted by ICANN. | 1263 | 2001 | * | | | The request did not validate | 1264 | | | | | against the schema. | 1265 | 2005 | * | | | Version is not supported. | 1266 | 2006 | * | | | The scheduleId in the schedule | 1267 | | | | | object and the scheduleId in the | 1268 | | | | | URL PATH do not match. | 1269 | 2007 | * | * | * | Interface is disabled for this TLD. | 1270 | 2401 | * | * | * | The syntax of the UUID in the PATH | 1271 | | | | | is incorrect. | 1272 | 2402 | * | | | The maintenance window start date | 1273 | | | | | and time is not 24 hours ahead of | 1274 | | | | | the current date and time. | 1275 | 2403 | * | | | The period specified by start and | 1276 | | | | | end date and time is greater than | 1277 | | | | | the monthly SLR for the service. | 1278 | 2404 | * | | | The period specified in the | 1279 | | | | | maintenance window collides with a | 1280 | | | | | previously scheduled maintenance | 1281 | | | | | window for the service. | 1282 | 2405 | | * | | The maintenance window that you are | 1283 | | | | | trying to delete already started. | 1284 | 2406 | * | | | The endTime is in the past, before | 1285 | | | | | or equal to the startTime. | 1286 | 2407 | * | | | The maintenance window that you are | 1287 | | | | | trying to update already ended, | 1288 | | | | | updates are not allowed. | 1289 | 2408 | * | | | The maintenance window that you are | 1290 | | | | | trying to update already started, | 1291 | | | | | only enabled and endTime fields can | 1292 | | | | | be modified. | 1293 +--------+-----+--------+-----+-------------------------------------+ 1295 Maintenance Window Management Result Codes 1297 7. Formal Syntax 1299 The schema of the IIRDEA Result, Report, Notification, RRI Reporting, 1300 Notifications, and Reports objects described in Section 1.4 are 1301 presented here. 1303 The and tags are not part of the schema; 1304 they are used to note the beginning and ending of the schema for URI 1305 registration purposes. 1307 7.1. RRI IIRDEA Result Schema 1308 1309 1310 1315 1316 1317 ICANN interfaces for registries and data escrow agents 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1332 1333 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1346 7.2. RRI Report Object 1347 1348 1349 1356 1357 1358 1359 1360 Data Escrow Report schema 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1380 7.3. RRI Notification Object 1382 1383 1384 1391 1392 1393 1394 1395 Data Escrow Notification schema 1396 1397 1398 1400 1401 1402 1403 1404 1405 1406 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1435 7.4. RRI Reporting Summary Object 1437 1438 1439 1445 1446 1447 1448 1449 1450 1451 1453 1454 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1470 1471 1472 1473 1474 1475 1476 1477 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1503 1504 1505 1506 1508 1510 1511 1512 1513 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1529 7.5. RRI Notifications Object 1530 1531 1532 1538 1539 1541 1542 1543 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1557 7.6. RRI Reports Object 1558 1559 1560 1566 1567 1568 1569 1570 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1584 7.7. Maintenance Window 1585 1586 1587 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1604 1605 1606 1607 1608 1610 1611 1612 1613 1614 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 7.8. SLAM Probe Node List 1633 1634 1635 1640 1641 1642 1643 1644 1645 1647 1648 1649 1650 1651 1653 1654 1655 1656 1657 1658 1659 1660 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1680 8. Acknowledgements 1682 Special suggestions that have been incorporated into this document 1683 were provided by David Kipling, James Gould, Gregory Zaltsman, Brett 1684 Carr, and Harel Efraim. 1686 9. Change History 1688 [[RFC Editor: Please remove this section.]] 1690 9.1. Version 00 1692 Initial version. 1694 9.2. Version 01 1696 o and moved from 1697 escrow drafts to this draft 1699 o Added to 1701 o element of is now OPTIONAL 1703 o Added element to 1705 o and added to the draft 1707 o Several report elements are OPTIONAL to support async interfaces 1708 between Registry Operators and Data Escrow Agents 1710 o Added and to registry-escrow-report interface in order 1711 to make the interface idempotent and support async RyO-DEA 1712 interfaces 1714 o Added to escrow-agent-notification interface 1716 o The escrow-agent-notification uses POST and not PUT, this has been 1717 fixed 1719 o Several clarifications 1721 9.3. Version 02 1723 o Added and updated several result codes. 1725 o Added element. 1727 o Added Content-type definition. 1729 9.4. Version 03 1731 o Added several result codes. 1733 o unsignedShort is now used for result code in iirdea schema. 1735 o Enumeration was removed from the iirdea schema. 1737 9.5. Version 04 1739 o Added result codes: 2207 and 2208. 1741 o Removed result codes: 2203. 1743 o Added clarification regarding the support of HTTP streams. 1745 9.6. Version 05 1747 o Added result codes: 2007 and 2008. 1749 9.7. Version 06 1751 o Added clarification of error code HTTP/403 in Section 6. 1753 9.8. Version 07 1755 o Added Section 5: "Monitoring compliance with the New gTLD Base 1756 Agreement". 1758 9.9. Version 08 1760 o Reorganized specification structure to allow easier references 1761 from new specifications expanding functionality in the ICANN 1762 Registry Interfaces. 1764 o Added Section 1.4 to document object definitions, previously 1765 defined in other sections. 1767 o Added , , and object 1768 descriptions to Section 1.4, and schema definitions to Section 7. 1770 o Renamed Section 5 title as "Monitoring the reporting status". 1772 o Updated element as OPTIONAL in the 1773 schema. 1775 o Added OPTIONAL attribute "domainCount" to the 1776 element. 1778 o Added OPTIONAL element to the schema. 1780 o Added result codes: 2105, 2209, 2210 and 2211. 1782 o Added "gTLD Base Registry Agreement" references. 1784 o Added clarifications to Section 6. 1786 9.10. Version 09 1788 o Standardized XSD schema validation error message for notifications 1789 and reports. 1791 o Element made optional in the schema. 1793 o Separated example RRI interface responses for successful and 1794 unsuccessful input. 1796 9.11. Version 10 1798 1. Ping update. 1800 9.12. Version 11 1802 1. Ping update. 1804 9.13. Version 12 1806 1. Ping update. 1808 9.14. Version 13 1810 1. IANA Considerations section added. 1812 2. Implementation section added. 1814 3. Internationalization Considerations status section added. 1816 4. Security section added. 1818 5. Editorial updates. 1820 9.15. Version 14 1822 1. Ping update. 1824 9.16. Version 15 1826 1. Added description and technical details for the interfaces for 1827 management of maintenance windows and list of probe nodes. 1829 2. I-D was restructured to make it easier to read. 1831 3. Editorial updates. 1833 9.17. Version 16 1835 1. Added interface description for supporting maintenance window 1836 objects and retrieving the IP addresses of the probe nodes used 1837 in the SLA Monitoring System (SLAM). 1839 2. I-D was restructured to make it easier to read. 1841 3. Editorial updates. 1843 9.18. Version 17 1845 1. Ping update. 1847 10. Internationalization Considerations 1849 The interfaces described in this document use XML, which provides 1850 native support for encoding information using the Unicode character 1851 set and its more compact representations including UTF-8. Conformant 1852 XML processors recognize both UTF-8 and UTF-16. Though XML includes 1853 provisions to identify and use other character encodings through use 1854 of an "encoding" attribute in an declaration, use of UTF-8 is 1855 RECOMMENDED. 1857 11. IANA Considerations 1859 This document uses URNs to describe XML namespaces and XML schemas 1860 conforming to a registry mechanism described in [RFC3688]. Six URI 1861 assignments have been registered by the IANA. 1863 Registration request for the RRI IIRDEA Result namespace: 1865 URI: urn:ietf:params:xml:ns:iirdea-1.0 1867 Registrant Contact: ICANN 1869 Note to RFC Editor: Please remove the email address from the RFC 1870 after IANA records it. 1872 XML: None. Namespace URIs do not represent an XML specification. 1874 Registration request for the RRI IIRDEA Result XML schema: 1876 URI: urn:ietf:params:xml:ns:iirdea-1.0 1878 Registrant Contact: ICANN 1880 Note to RFC Editor: Please remove the email address from the RFC 1881 after IANA records it. 1883 See section Section 7.1 of this document. 1885 Registration request for the RRI Report namespace: 1887 URI: urn:ietf:params:xml:ns:rdeReport-1.0 1889 Registrant Contact: ICANN 1891 Note to RFC Editor: Please remove the email address from the RFC 1892 after IANA records it. 1894 XML: None. Namespace URIs do not represent an XML specification. 1896 Registration request for the RRI Report schema: 1898 URI: urn:ietf:params:xml:ns:rdeReport-1.0 1900 Registrant Contact: ICANN 1902 Note to RFC Editor: Please remove the email address from the RFC 1903 after IANA records it. 1905 See section Section 7.2 of this document. 1907 Registration request for the RRI Notification namespace: 1909 URI: urn:ietf:params:xml:ns:rdeNotification-1.0 1911 Registrant Contact: ICANN 1913 Note to RFC Editor: Please remove the email address from the RFC 1914 after IANA records it. 1916 XML: None. Namespace URIs do not represent an XML specification. 1918 Registration request for the RRI Notification XML schema: 1920 URI: urn:ietf:params:xml:ns:rdeNotification-1.0 1922 Registrant Contact: ICANN 1924 Note to RFC Editor: Please remove the email address from the RFC 1925 after IANA records it. 1927 See section Section 7.3 of this document. 1929 Registration request for the RRI Reporting Summary namespace: 1931 URI: urn:ietf:params:xml:ns:rriReporting-1.0 1933 Registrant Contact: ICANN 1935 Note to RFC Editor: Please remove the email address from the RFC 1936 after IANA records it. 1938 XML: None. Namespace URIs do not represent an XML specification. 1940 Registration request for the RRI Reporting Summary XML schema: 1942 URI: urn:ietf:params:xml:ns:rriReporting-1.0 1944 Registrant Contact: ICANN 1946 Note to RFC Editor: Please remove the email address from the RFC 1947 after IANA records it. 1949 See section Section 7.4 of this document. 1951 Registration request for the RRI Notifications namespace: 1953 URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 1955 Registrant Contact: ICANN 1957 Note to RFC Editor: Please remove the email address from the RFC 1958 after IANA records it. 1960 XML: None. Namespace URIs do not represent an XML specification. 1962 Registration request for the RRI Notifications XML schema: 1964 URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 1966 Registrant Contact: ICANN 1967 Note to RFC Editor: Please remove the email address from the RFC 1968 after IANA records it. 1970 See section Section 7.5 of this document. 1972 Registration request for the RRI Reports namespace: 1974 URI: urn:ietf:params:xml:ns:rdeReports-1.0 1976 Registrant Contact: ICANN 1978 Note to RFC Editor: Please remove the email address from the RFC 1979 after IANA records it. 1981 XML: None. Namespace URIs do not represent an XML specification. 1983 Registration request for the RRI Reports XML schema: 1985 URI: urn:ietf:params:xml:ns:rdeReports-1.0 1987 Registrant Contact: ICANN 1989 Note to RFC Editor: Please remove the email address from the RFC 1990 after IANA records it. 1992 See section Section 7.6 of this document. 1994 Registration request for the Maintenance Window namespace: 1996 URI: urn:ietf:params:xml:ns:schedule-1.0 1998 Registrant Contact: ICANN 2000 Note to RFC Editor: Please remove the email address from the RFC 2001 after IANA records it. 2003 XML: None. Namespace URIs do not represent an XML specification. 2005 Registration request for the Maintenance Window XML schema: 2007 URI: urn:ietf:params:xml:ns:schedule-1.0 2009 Registrant Contact: ICANN 2011 Note to RFC Editor: Please remove the email address from the RFC 2012 after IANA records it. 2014 See section Section 7.7 of this document. 2016 Registration request for the SLAM Probe Node List namespace: 2018 URI: urn:ietf:params:xml:ns:probeNode-1.0 2020 Registrant Contact: ICANN 2022 Note to RFC Editor: Please remove the email address from the RFC 2023 after IANA records it. 2025 XML: None. Namespace URIs do not represent an XML specification. 2027 Registration request for the SLAM Probe Node List XML schema: 2029 URI: urn:ietf:params:xml:ns:probeNode-1.0 2031 Registrant Contact: ICANN 2033 Note to RFC Editor: Please remove the email address from the RFC 2034 after IANA records it. 2036 See section Section 7.8 of this document. 2038 12. Implementation Status 2040 Note to RFC Editor: Please remove this section and the reference to 2041 RFC 7942 [RFC7942] before publication. 2043 This section records the status of known implementations of the 2044 protocol defined by this specification at the time of posting of this 2045 Internet-Draft, and is based on a proposal described in RFC 7942 2046 [RFC7942]. The description of implementations in this section is 2047 intended to assist the IETF in its decision processes in progressing 2048 drafts to RFCs. Please note that the listing of any individual 2049 implementation here does not imply endorsement by the IETF. 2050 Furthermore, no effort has been spent to verify the information 2051 presented here that was supplied by IETF contributors. This is not 2052 intended as, and must not be construed to be, a catalog of available 2053 implementations or their features. Readers are advised to note that 2054 other implementations may exist. 2056 According to RFC 7942 [RFC7942], "this will allow reviewers and 2057 working groups to assign due consideration to documents that have the 2058 benefit of running code, which may serve as evidence of valuable 2059 experimentation and feedback that have made the implemented protocols 2060 more mature. It is up to the individual working groups to use this 2061 information as they see fit". 2063 12.1. Implementation in the gTLD space 2065 Organization: ICANN 2067 Name: ICANN Registry Agreement 2069 Description: the ICANN Base Registry Agreement requires Registries, 2070 Data Escrow Agents, and ICANN to implement this specification. ICANN 2071 receives daily notifications from Data Escrow Agents and Registries 2072 using this specification. 2074 Level of maturity: production. 2076 Coverage: all aspects of this specification are implemented. 2078 Version compatibility: versions 00 - 09 are known to be implemented. 2080 Contact: gustavo.lozano@icann.org 2082 URL: https://www.icann.org/resources/pages/registries/registries- 2083 agreements-en 2085 13. Security Considerations 2087 The interfaces described in this document MUST be provided using 2088 HTTPS. The recommendations in [RFC7525] MUST be implemented. 2090 14. References 2092 14.1. Normative References 2094 [ICANN-GTLD-RA-20170731] 2095 ICANN, "Base Registry Agreement 2017-07-31", July 2017, 2096 . 2099 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2100 Requirement Levels", BCP 14, RFC 2119, 2101 DOI 10.17487/RFC2119, March 1997, 2102 . 2104 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 2105 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 2106 . 2108 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 2109 DOI 10.17487/RFC3688, January 2004, 2110 . 2112 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 2113 Unique IDentifier (UUID) URN Namespace", RFC 4122, 2114 DOI 10.17487/RFC4122, July 2005, 2115 . 2117 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2118 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 May 2017, . 2121 [RFC8909] Lozano, G., "Registry Data Escrow Specification", 2122 RFC 8909, DOI 10.17487/RFC8909, November 2020, 2123 . 2125 [RFC9022] Lozano, G., Gould, J., and C. Thippeswamy, "Domain Name 2126 Registration Data (DNRD) Objects Mapping", RFC 9022, 2127 DOI 10.17487/RFC9022, May 2021, 2128 . 2130 [W3C.REC-xml-20081126] 2131 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 2132 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 2133 Edition) REC-xml-20081126", November 2008, 2134 . 2136 [W3C.REC-xmlschema-1-20041028] 2137 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 2138 "XML Schema Part 1: Structures Second Edition REC- 2139 xmlschema-1-20041028", October 2004, 2140 . 2142 [W3C.REC-xmlschema-2-20041028] 2143 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 2144 Second Edition REC-xmlschema-2-20041028", October 2004, 2145 . 2147 14.2. Informative References 2149 [RFC5890] Klensin, J., "Internationalized Domain Names for 2150 Applications (IDNA): Definitions and Document Framework", 2151 RFC 5890, DOI 10.17487/RFC5890, August 2010, 2152 . 2154 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2155 "Recommendations for Secure Use of Transport Layer 2156 Security (TLS) and Datagram Transport Layer Security 2157 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2158 2015, . 2160 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 2161 Code: The Implementation Status Section", BCP 205, 2162 RFC 7942, DOI 10.17487/RFC7942, July 2016, 2163 . 2165 Authors' Addresses 2167 Gustavo Lozano 2168 ICANN 2169 12025 Waterfront Drive, Suite 300 2170 Los Angeles 90292 2171 US 2173 Phone: +1.3103015800 2174 Email: gustavo.lozano@icann.org 2176 Eduardo Alvarez 2177 ICANN 2178 12025 Waterfront Drive, Suite 300 2179 Los Angeles 90292 2180 US 2182 Phone: +1.3103015800 2183 Email: eduardo.alvarez@icann.org