Internet Engineering Task Force G.L. Lozano Internet-Draft E.A. Alvarez Intended status: Informational ICANN Expires: 1 December 2024 30 May 2024 ICANN Registry Interfaces draft-lozano-icann-registry-interfaces-22 Abstract This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to its contracted parties to fulfill reporting requirements. The interfaces provided by ICANN to Data Escrow Agents and Registry Operators to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 1 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Lozano & Alvarez Expires 1 December 2024 [Page 1] Internet-Draft ICANN Registry Interfaces May 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Date and Time . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Common elements used in this specification . . . . . . . 4 1.4. Object Description . . . . . . . . . . . . . . . . . . . 4 2. Interfaces for Specification 2 - Data Escrow Reporting . . . 12 2.1. Registry Operator Reporting . . . . . . . . . . . . . . . 12 2.2. Data Escrow Agent Reporting . . . . . . . . . . . . . . . 13 2.3. Monitoring the reporting status . . . . . . . . . . . . . 15 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Per-Registrar Transactions Report . . . . . . . . . . . . 17 3.2. Registry Functions Activity Report . . . . . . . . . . . 17 3.3. Monitoring the reporting status . . . . . . . . . . . . . 18 4. Maintenance Windows . . . . . . . . . . . . . . . . . . . . . 19 4.1. Creating and updating a maintenance window . . . . . . . 19 4.2. Deleting a maintenance window . . . . . . . . . . . . . . 19 4.3. Getting the persisted data for a maintenance window . . . 20 4.4. Getting a list of maintenance windows . . . . . . . . . . 20 4.5. Suppression of alerts . . . . . . . . . . . . . . . . . . 21 5. Interfaces for the SLAM Probe Node List . . . . . . . . . . . 21 6. Technical details of the interfaces . . . . . . . . . . . . . 22 6.1. General technical details . . . . . . . . . . . . . . . . 22 6.2. Specific technical details . . . . . . . . . . . . . . . 23 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 31 7.1. RRI IIRDEA Result Schema . . . . . . . . . . . . . . . . 32 7.2. RRI Report Object . . . . . . . . . . . . . . . . . . . . 32 7.3. RRI Notification Object . . . . . . . . . . . . . . . . . 33 7.4. RRI Reporting Summary Object . . . . . . . . . . . . . . 34 7.5. RRI Notifications Object . . . . . . . . . . . . . . . . 36 7.6. RRI Reports Object . . . . . . . . . . . . . . . . . . . 37 7.7. Maintenance Window . . . . . . . . . . . . . . . . . . . 38 7.8. SLAM Probe Node List . . . . . . . . . . . . . . . . . . 40 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 9. Change History . . . . . . . . . . . . . . . . . . . . . . . 41 9.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 41 9.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 41 9.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 41 9.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 42 9.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 42 9.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 42 9.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 42 Lozano & Alvarez Expires 1 December 2024 [Page 2] Internet-Draft ICANN Registry Interfaces May 2024 9.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 42 9.9. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 42 9.10. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 43 9.11. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 43 9.12. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 43 9.13. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 43 9.14. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 43 9.15. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 43 9.16. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 44 9.17. Version 16 . . . . . . . . . . . . . . . . . . . . . . . 44 9.18. Version 17 . . . . . . . . . . . . . . . . . . . . . . . 44 9.19. Version 18 . . . . . . . . . . . . . . . . . . . . . . . 44 9.20. Version 19 . . . . . . . . . . . . . . . . . . . . . . . 44 9.21. Version 20 . . . . . . . . . . . . . . . . . . . . . . . 44 9.22. Version 21 . . . . . . . . . . . . . . . . . . . . . . . 44 9.23. Version 22 . . . . . . . . . . . . . . . . . . . . . . . 44 10. Internationalization Considerations . . . . . . . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 49 12.1. Implementation in the gTLD space . . . . . . . . . . . . 49 13. Security Considerations . . . . . . . . . . . . . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 14.1. Normative References . . . . . . . . . . . . . . . . . . 50 14.2. Informative References . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 1. Introduction This document describes the technical details of the interfaces provided by the Internet Corporation for Assigned Names and Numbers (ICANN) to other contracted parties to fulfill reporting requirements. The interface provided by ICANN to Registry Operators and Data Escrow Agents to fulfill the requirements of Specifications 2 and 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] are described in this document. Additionally, interfaces for retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM) and interfaces for supporting maintenance window objects are described in this document. Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20081126] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are used in this specification. The provisioning of credentials and authentication methods used in the interfaces are outside of this document's scope. Lozano & Alvarez Expires 1 December 2024 [Page 3] Internet-Draft ICANN Registry Interfaces May 2024 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation. 1.2. Date and Time Numerous fields indicate "date and time", such as the creation and receipt dates for data escrow deposits. These fields SHALL contain timestamps indicating the date and time in UTC as specified in [RFC3339], with no offset from the zero meridian. 1.3. Common elements used in this specification Common elements used in this specification are explained in this section. * : The base URL used in the reporting interfaces examples must be replaced with the URL indicated by ICANN. 1.4. Object Description This section describes the base objects supported by this specification. 1.4.1. object The ICANN interfaces for registries and data escrow agents (IIRDEA) object is used to provide information on the result of a verification process when interacting with the interfaces. The XML Schema for the object can be found in Section 7.1. The object contains the following attributes and child elements: * A "code" attribute whose value is a four-digit decimal number that identifies the result of a process. Available result code values MUST be defined for the corresponding process. Lozano & Alvarez Expires 1 December 2024 [Page 4] Internet-Draft ICANN Registry Interfaces May 2024 * An OPTIONAL "domainCount" attribute indicates the number of domain names related to the reported result. * A element contains a human-readable description of the result code. * An OPTIONAL element that includes additional details on the result conditions. An example of a object is presented below: The structure of the report is invalid. 'XX' could not be parsed as a number (line: 2 column:3) 1.4.2. object The contents of a data escrow deposit are described using a object. The XML Schema for the object can be found in Section 7.2. The object contains the following child elements: * An element that contains the identifier assigned to this report. The report identifier MUST be the same as the "id" attribute from the . If the data escrow deposit does not include a unique identifier, the Data Escrow Agent MUST generate a unique identifier to reference the data escrow deposit and use it in the element. * A element contains the version of the specification used. This value MUST be 1. * A element contains the version of the Data Escrow Specification (e.g., RFC8909) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA. * An OPTIONAL element contains the version of the Domain Name Registration Data (DNRD) Objects Mapping (e.g., RFC9022) used to create the deposit. After the specification is published as an RFC, the value MUST be the RFC number assigned by IANA. The element MUST be included if the deposit was created using any version of the DNRD objects mapping specification (see [RFC9022]). Lozano & Alvarez Expires 1 December 2024 [Page 5] Internet-Draft ICANN Registry Interfaces May 2024 * A element contains the value of the "resend" attribute of the . * A element contains the date and time that the Registry Operator created the deposit. * A element is used to identify the kind of deposit: FULL, INCR (Incremental), or DIFF (Differential). * A element contains the date and time corresponding to the Timeline Watermark ( element) of the . * A element contains the header of the as defined in [RFC9022]. An example of a object is available in Section 2.1. 1.4.3. object The object is used by Data Escrow Agents to document the result of the data escrow deposit verification process. The XML Schema for the object can be found in Section 7.3. The object contains the following child elements: * A element contains the name of the Data Escrow Agent. * A element contains the version of the specification used. This value MUST be 1. * A element contains the reported date. In the case of a DVPN or DVFN notification, this value MUST be the date of the element of the . In the case of a DRFN deposit notification, this value MUST be the date for which no deposit was received from the Registrar or Registry Operator. * A element is used to specify the status of . The possible values of status are DVPN, DVFN, and DRFN. The three types of notices determine the value for the element: - Deposit Receipt Failure Notice (DRFN): generated by the Data Escrow Agent when no deposit is received according to the data escrow deposit schedule. Lozano & Alvarez Expires 1 December 2024 [Page 6] Internet-Draft ICANN Registry Interfaces May 2024 - Deposit Verification Failure Notice (DVFN): generated by the Data Escrow Agent when a deposit is received, but the final result of the verification process is a failure. - Deposit Verification Pass Notice (DVPN): generated by the Data Escrow Agent when a deposit is received, and the final result of the verification process is a success. * An OPTIONAL element contains the errors detected during the data escrow deposit verification process performed by the Data Escrow Agent. The element includes one or more elements as defined in Section 1.4.1. In the case of a DRFN or DVPN deposit notification, the element MUST NOT be present. * An OPTIONAL element contains the date and time that the Data Escrow Agent successfully received the deposit. In the case of a DRFN deposit notification, this element MUST NOT be present. * An OPTIONAL element contains the date and time that the Data Escrow Agent processed the deposit for validation. In the case of a DRFN deposit notification, this element MUST NOT be present. * An OPTIONAL element contains the date of the Timeline Watermark ( element) of the most recent FULL deposit that the Data Escrow Agent successfully validated. This element MUST NOT be present if a successfully validated full deposit has never been deposited. * An OPTIONAL element is used by the Data Escrow Agent to provide extended information about the deposit. In the case of a DRFN deposit notification, this element MUST NOT be present. In the case of a DVPN or DVFN deposit notification, this element MUST be present. When this element is present, the element MUST be generated by the Data Escrow Agent for the Timeline Watermark ( element) of the deposit being processed. If the deposit being processed is a differential or incremental deposit, the Data Escrow Agent MUST create a dataset by following Section 5.2 of [RFC8909] to generate the element. * Note: In the case of a DVPN or DVFN deposit notification, the is used as a unique identifier. An example of a object is available in Section 2.2. Lozano & Alvarez Expires 1 December 2024 [Page 7] Internet-Draft ICANN Registry Interfaces May 2024 1.4.4. Object Interfaces that support monitoring the reporting status for a specific repository provide a object as defined by the schema in Section 7.4 in the HTTP Entity-body when a HTTP/200 code is sent by the interface. The element includes the following child elements: * A choice of one of the elements as defined in the "rdeHeader:repositoryTypeGroup" (see [RFC9022]) that indicates the unique identifier for the repository being escrowed. * A element with the date and time in which the queried repository was created in the system. * A OPTIONAL element indicating the current Data Escrow Deposit schedule for the queried repository. Possible values are "None", "Weekly", and "Daily". * An OPTIONAL element indicating the date of the Timeline Watermark ( element) of the most recent FULL deposit that was successfully validated for the queried repository as notified by the Data Escrow Agent. * A element with a element for each report type for the queried repository. Each element includes the following child elements: - : a string value indicating the report type to which the information provided pertains. - : a boolean value indicating if the report type is enabled for the repository. - : a string value indicating the reporting status. A value of "ok" indicates no reporting issues in the corresponding report type, otherwise the value of "unsatisfactory" is shown. - An OPTIONAL element included only when the element has a value of "unsatisfactory", and includes an empty element for each date with a reporting problem found in the corresponding report type. Each element includes a REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED "description" attribute to describe the issue. The possible values to describe each reporting issue are: Lozano & Alvarez Expires 1 December 2024 [Page 8] Internet-Draft ICANN Registry Interfaces May 2024 o "Missing_Deposit_Full": If the latest notification received from the Data Escrow Agent for the date indicates that a scheduled "Full" deposit was not submitted by the repository owner. o "Missing_Deposit_Diff": If the latest notification received from the Data Escrow Agent for the date indicates that a scheduled "Differential" deposit was not submitted by the repository owner. o "Invalid_Deposit_Full": If the latest notification received from the Data Escrow Agent for the date indicates that a "Full" deposit was received by the Data Escrow Agent, but failed the verification process. o "Invalid_Deposit_Diff": If the latest notification received from the Data Escrow Agent for the date indicates that a "Differential" deposit was received by the Data Escrow Agent, but failed the verification process. o "No_Report_Received" If no report has been received for the date. * A element to indicate the date and time the reporting status response was created. 1.4.5. Object Interfaces that support monitoring and retrieving Data Escrow Reports received, provide a object as defined by the schema in Section 7.6 in the HTTP Entity-body when an HTTP/200 code is sent by the interface. The element includes a list of objects, one for each successfully received by ICANN. Each object includes the following child elements: * A element to indicate the date and time in which ICANN received the report. * A element as defined in Section 1.4.2 as received by ICANN. Lozano & Alvarez Expires 1 December 2024 [Page 9] Internet-Draft ICANN Registry Interfaces May 2024 1.4.6. Object Interfaces that support monitoring and retrieving Data Escrow Notifications received from Data Escrow Agents, provide a object as defined by the schema in Section 7.5 in the HTTP Entity-body when an HTTP/200 code is sent by the interface. The element includes a list of objects, one for each successfully received by ICANN. Each object includes the following child elements: * A element to indicate the date and time in which ICANN received the notification. * A element as defined in Section 1.4.3 as received by ICANN. 1.4.7. object The object is used to provide details of an instance of a maintenance window. The maintenance window is identified by a Universally Unique IDentifier version 4 (see [RFC4122]) captured in the attribute "scheduleId". An additional attribute "enabled" defined as a boolean can be used to enable (value of true) or disable (value of false) the maintenance window. The XML Schema for the object can be found in Section 7.7. The object contains the following child elements: * A element contains a descriptive name of the maintenance window. * A element contains a description of the maintenance window. * A element contains the version of the specification used. This value MUST be 1. * A element contains the date and time when the maintenance window starts being active. * A element contains the date and time when the maintenance window ends being active. Lozano & Alvarez Expires 1 December 2024 [Page 10] Internet-Draft ICANN Registry Interfaces May 2024 An example of a object is available in Section 4. 1.4.8. object The object is used to provide the list of maintenance window objects. The XML Schema for the object can be found in Section 7.7. The object contains the following child elements: * Zero or more elements. See, Section 1.4.7 for the definition of . An example of a object is available in Section 4. 1.4.9. object The object is used to provide the list of probe nodes used by the SLA Monitoring System. The XML Schema for the object can be found in Section 7.8. The object contains the following child elements: * One or more elements. Each element contains the following child elements: - A element contains the name of the city where the node is located. - One or more element contains the IP addresses used in the node to originate test connections. An "ip" attribute contains the string "v4" if the IP address is an IPv4 address or "v6" if the IP address is an IPv6 address. * A element contains the date and time of the last update of the list. * A element contains the version of the specification used. This value MUST be 1. An example of a object is available in Section 5. Lozano & Alvarez Expires 1 December 2024 [Page 11] Internet-Draft ICANN Registry Interfaces May 2024 2. Interfaces for Specification 2 - Data Escrow Reporting This section describes the interfaces provided by ICANN to Registry Operators and Data Escrow Agents to fulfill the reporting requirements detailed in Specification 2 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731]. 2.1. Registry Operator Reporting The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], Specification 2, Part A, Section 7 requires Registry Operators to provide ICANN with a written statement that includes a copy of the report generated upon creation of a deposit and a statement that the deposit has been inspected by the Registry Operator and is complete and accurate. In order to satisfy this requirement, the Registry Operator sends to ICANN a object as defined in Section 1.4.2 for each deposit successfully sent to the Data Escrow Agent, using the PUT HTTP verb in the interface provided by ICANN at: /report/registry-escrow-report// Where: - MUST be substituted by the TLD for which the report is being provided. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the identifier assigned to this report, which MUST be the same as the "id" attribute from the . Note: the interface supports overwriting the information of a particular report to support asynchronous interfaces between Registry Operators and Data Escrow Agents. Example of a object for a data escrow deposit corresponding to a TLD Registry repository: Lozano & Alvarez Expires 1 December 2024 [Page 12] Internet-Draft ICANN Registry Interfaces May 2024 20101017001 1 RFC8909 RFC9022 0 2010-10-17T00:15:00.0Z FULL 2010-10-17T00:00:00Z test 2 1 1 1 1 1 1 2.2. Data Escrow Agent Reporting The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], Specification 2, Part B, Section 7 requires Data Escrow Agents to deliver ICANN with a notification object every time a successfully processed deposit is received from the Registry Operator regardless of the final status of the verification process. To satisfy this requirement, the Data Escrow Agent sends to ICANN a object as defined in Section 1.4.3, using the POST HTTP verb in the interface provided by ICANN at: Lozano & Alvarez Expires 1 December 2024 [Page 13] Internet-Draft ICANN Registry Interfaces May 2024 /report/escrow-agent-notification/ Where: - MUST be substituted by the TLD for which the notification is being provided. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. If by 23:59:59 UTC, a deposit has not been successfully processed regardless of the final status of the verification process, a object with DRFN status MUST be sent to ICANN. Example of a object of a Data Escrow Agent notification corresponding to a Registry repository Data Escrow Deposit: Escrow Agent Inc. 1 2010-10-17 DVPN 2010-10-17T03:15:00.0Z 2010-10-17T05:15:00.0Z 2010-10-14 20101017001 1 RFC8909 RFC9022 0 2010-10-17T00:15:00.0Z FULL 2010-10-17T00:00:00Z Lozano & Alvarez Expires 1 December 2024 [Page 14] Internet-Draft ICANN Registry Interfaces May 2024 test 1 3 1 3 1 10 0 2.3. Monitoring the reporting status Registries MAY monitor the status of the reports described in Specification 2 [ICANN-GTLD-RA-20170731] using the following interfaces that support the HEAD HTTP verb: 2.3.1. Monitoring the status of Data Escrow Reports Registries MAY monitor the status of Data Escrow Reports using the following interface: /info/report/registry-escrow-report// Where: - MUST be substituted by the TLD being queried. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the day being queried. For example, 2013-03-02. Possible results are: - The interface provides an HTTP/200 status code if a syntactically valid data escrow report was received for the queried date. Lozano & Alvarez Expires 1 December 2024 [Page 15] Internet-Draft ICANN Registry Interfaces May 2024 - The interface provides an HTTP/404 status code if a syntactically valid data escrow report has not been received for the queried date. 2.3.2. Monitoring the status of Data Escrow Notifications Registries and Data Escrow Agents MAY monitor the status of Data Escrow Notifications using the following interface: /info/report/escrow-agent-notification// Where: - MUST be substituted by the TLD being queried. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the day being queried. For example, 2013-03-02. Possible results are: - The interface provides an HTTP/200 status code if a syntactically valid data escrow notification was received for the queried date. - The interface provides an HTTP/404 status code if a syntactically valid data escrow notification has not been received for the queried date. 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting Specification 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] requires Registry Operators to provide a set of monthly reports per gTLD. Two types of reports are required to be sent by Registries: Per-Registrar Transactions Report and Registry Functions Activity Report. This section specifies the interfaces provided by ICANN to automate the upload of these reports by Registry Operators. The cut-off date for the reception of the reports specified in specification 3 is defined in the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731]. Before the cut-off date, the Registry Operator MAY replace a successfully validated report as many times as needed. Lozano & Alvarez Expires 1 December 2024 [Page 16] Internet-Draft ICANN Registry Interfaces May 2024 3.1. Per-Registrar Transactions Report The Per-Registrar Transactions Report is a CSV report encoded in UTF-8 described in Section 1 of Specification 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731]. To satisfy this requirement, the Registry Operator sends a CSV report monthly as described in the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the interface provided by ICANN at: /report/registrar-transactions// Where: - MUST be substituted by the TLD for which the report is being provided. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the month for which the report is being provided in the form of YYYY-MM. Where 'YYYY' is the year, and 'MM' is the two-digit month number. For example, 2013-03. 3.2. Registry Functions Activity Report The Registry Functions Activity Report is a CSV report encoded in UTF-8 described in Section 2 of Specification 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731]. To satisfy this requirement, the Registry Operator sends a CSV report monthly as described in the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the interface provided by ICANN at: /report/registry-functions-activity// Where: - MUST be substituted by the TLD for which the report is being provided. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the month for which the report is being provided in the form of YYYY-MM. Where 'YYYY' is the year, and 'MM' is the two-digit month number. For example, 2013-03. Lozano & Alvarez Expires 1 December 2024 [Page 17] Internet-Draft ICANN Registry Interfaces May 2024 3.3. Monitoring the reporting status Registries MAY monitor the status of the reports described in Specification 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] using the following interfaces that support the HEAD HTTP verb: 3.3.1. Monitoring the status of Registry Functions Activity Report Registries MAY monitor the status of Registry Functions Activity Report using the following interface: /info/report/registry-functions-activity// Where: - MUST be substituted by the TLD being queried. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the month being queried. For example, 2013-03. Possible results are: - The interface provides an HTTP/200 status code if a syntactically valid registry functions activity report was received for the queried month. - The interface provides an HTTP/404 status code if a syntactically valid registry functions activity report has not been received for the queried month. 3.3.2. Monitoring the status of the Per-Registrar Transactions Report Registries MAY monitor the status of Per-Registrar Transactions Report using the following interface: /info/report/registrar-transactions// Where: - MUST be substituted by the TLD being queried. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by the month being queried. For example, 2013-03. Possible results are: Lozano & Alvarez Expires 1 December 2024 [Page 18] Internet-Draft ICANN Registry Interfaces May 2024 - The interface provides an HTTP/200 status code if a syntactically valid per-registrar transactions report was received for the queried month. - The interface provides an HTTP/404 status code if a syntactically valid per-registrar transactions report has not been received for the queried month. 4. Maintenance Windows Specification 10 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] allows Registry Operators to provide notice to ICANN about plans of maintenance. This section specifies the interfaces provided by ICANN to programmatically manage maintenance windows by Registry Operators. 4.1. Creating and updating a maintenance window To create or update a previously created maintenance window, the Registry Operator sends a object (see Section 1.4.7) using the PUT HTTP verb in the interface provided by ICANN at: /maintenance-window/// Where: - MUST be substituted by the TLD for which the report is being provided. In the case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. - MUST be substituted by a service for which a maintenance window could be created (e.g., RDDS). - MUST be substituted by a Universally Unique IDentifier version 4 (see [RFC4122]). 4.2. Deleting a maintenance window To delete a previously created maintenance window, the Registry Operator uses the DELETE HTTP verb in the interface provided by ICANN at: /maintenance-window/// Lozano & Alvarez Expires 1 December 2024 [Page 19] Internet-Draft ICANN Registry Interfaces May 2024 4.3. Getting the persisted data for a maintenance window To get the persisted data for a maintenance window, the Registry Operator uses the GET HTTP verb in the interface provided by ICANN at: /maintenance-window/// The interface provides an HTTP/200 status code and sets the HTTP header Content-type: text/xml after a successful request, and includes a object as defined in Section 1.4.7. Example of a object of a Maintenance Window: Maintenance window for RDDS semester II-2017 Pre-planned maintenance window for RDDS 2010-10-17T00:15:00.0Z 2010-10-17T02:15:00.0Z 1 4.4. Getting a list of maintenance windows To get the list of all the maintenance windows that have not ended yet (see Section 4), the Registry Operator uses the GET HTTP verb in the interface provided by ICANN at: maintenance-window// The interface provides an HTTP/200 status code and sets the HTTP header Content-type: text/xml after a successful request, and includes a object as defined in Section 1.4.8. Example of a : Lozano & Alvarez Expires 1 December 2024 [Page 20] Internet-Draft ICANN Registry Interfaces May 2024 Maintenance window for example Pre-planned maintenance window 1 2010-10-17T00:15:00.0Z 2010-10-17T02:15:00.0Z 1 Maintenance window for example Pre-planned maintenance window 2 2010-10-19T00:15:00.0Z 2010-10-19T02:15:00.0Z 1 4.5. Suppression of alerts ICANN will suspend Emergency Escalation services only for the 10% Emergency Threshold alert for RDDS and EPP when an enabled (i.e., the "enabled" attribute is true) schedule object exists and the threshold is reached on a point in time covered by the and . 5. Interfaces for the SLAM Probe Node List The current list of probe nodes used by the SLA Monitoring System may be retrieved by using the GET HTTP verb in the interface provided by ICANN at: /slam-probe-nodes/list The interface provides an HTTP/200 status code and sets the HTTP header Content-type: text/xml after a successful request, and includes a object as defined in Section 1.4.9. Example of the response upon successful retrieval of the SLAM Probe Node List: Lozano & Alvarez Expires 1 December 2024 [Page 21] Internet-Draft ICANN Registry Interfaces May 2024 Mumbai 192.0.2.1 2001:db8:1::1 Seoul 198.51.100.1 2020-11-18T02:23:56-08:00 1 6. Technical details of the interfaces This section describes the technical details of the interfaces described in this document. 6.1. General technical details This section describes the technical details that apply to all the interfaces described in this document. The following HTTP status codes are returned: * The interface provides an HTTP/401 status code and sets the HTTP header Content-type: text/plain, if the credentials provided do not authorize the user to perform the action requested for that . * The interface provides an HTTP/403 status code and sets the HTTP header Content-type: text/plain, if the user attempts to access a resource that permission is not granted for, or the connecting IP address is not authorized for the . * The interface provides an HTTP/404 status code if the object referenced in the URL is not found. * The interface provides an HTTP/405 status code if the interface does not support the request method. Lozano & Alvarez Expires 1 December 2024 [Page 22] Internet-Draft ICANN Registry Interfaces May 2024 * The interface provides an HTTP/500 status code and sets the HTTP header Content-type: text/plain, if the system is experiencing a general failure. The sending party is responsible for sending the input again. * The interface provides an HTTP/501 status code and sets the HTTP header Content-type: text/plain, if the functionality has not yet been implemented. After sending the response, the interfaces close the TCP connection. The interfaces support HTTP streams only (HTTP multi-part forms are not supported). 6.2. Specific technical details This section describes the technical details that apply to the following interfaces: * Registry Operator Reporting (see Section 2.1) * Data Escrow Agent Reporting (see Section 2.2) * Per-Registrar Transactions Report (see Section 3.1) * Registry Functions Activity Report (see Section 3.2) * Creating and updating a maintenance window (see Section 4.1) * Deleting a maintenance window (see Section 4.2) The following additional HTTP status codes are returned: * The interface provides an HTTP/200 status code and sets the HTTP header Content-type: text/xml, if the interface was able to receive the input successfully, the client MUST review the response object (see Section 6.2.1) to verify the result code after processing the input. * The interface provides an HTTP/400 status code and sets the HTTP header Content-type: text/xml, if the input is incorrect or the syntax of the input is invalid. A response object (see Section 6.2.1) is included with the input validation failure details. Content-type value in the HTTP header: Lozano & Alvarez Expires 1 December 2024 [Page 23] Internet-Draft ICANN Registry Interfaces May 2024 * The client MUST set "text/xml" in the HTTP header Content-type when using the interfaces described in Section 2.1, Section 2.2, Section 4.1, and Section 4.2. * The client MUST set "text/csv" in the HTTP header Content-type when using the interfaces described in Section 3.1 and Section 3.2. 6.2.1. Response Object After processing the input provided to the interfaces described in this section, a response object defined in Section 1.4.1 is sent in the HTTP Entity-body when an HTTP/200 or HTTP/400 status code is sent by the interface. An example of a response object upon successful input receipt is presented below: HTTP/1.1 200 OK Content-Type: text/xml Content-Length: 248 No ERRORs were found and the report has been accepted by ICANN. An example of a response object in the event of input error is presented below: Lozano & Alvarez Expires 1 December 2024 [Page 24] Internet-Draft ICANN Registry Interfaces May 2024 HTTP/1.1 400 Bad Request Content-Type: text/xml Content-Length: 279 The structure of the report is invalid. 'XX' could not be parsed as a number (line: 2 column:3) The following sections provide the IIRDEA Result Codes per interface: 6.2.1.1. Registry Operator Reporting The following table lists the result codes of the Registry Operator Reporting interface (see Section 2.1): Lozano & Alvarez Expires 1 December 2024 [Page 25] Internet-Draft ICANN Registry Interfaces May 2024 +========+====================================================+ | Result | Message | | Code | | +========+====================================================+ | 1000 | No ERRORs were found, and the report has been | | | accepted by ICANN. | +--------+----------------------------------------------------+ | 2001 | The request did not validate against the schema. | +--------+----------------------------------------------------+ | 2004 | Report for a date in the future. The and | | | date should not be in the future. | +--------+----------------------------------------------------+ | 2005 | Version is not supported. | +--------+----------------------------------------------------+ | 2006 | The in the element and the in | | | the URL path do not match. | +--------+----------------------------------------------------+ | 2007 | Interface is disabled for this TLD. | +--------+----------------------------------------------------+ | 2008 | The and date should not be | | | before the creation date of the TLD in the system. | +--------+----------------------------------------------------+ | 2202 | The in the
and the TLD in the URL | | | path do not match. | +--------+----------------------------------------------------+ | 2205 | Report regarding a differential deposit received | | | when a full deposit was expected (). | +--------+----------------------------------------------------+ | 2206 | csvDomain and rdeDomain count provided in the | | |
. | +--------+----------------------------------------------------+ | 2209 | Missing required element in the
. | +--------+----------------------------------------------------+ | 2210 | The value of the "rcdn" attribute in the | | | element does not match the same or lower level | | | names in the in the URL path. | +--------+----------------------------------------------------+ | 2211 | Multiple count elements with the same "uri", | | | "rcdn", and "registrarId" attribute values | | | provided in the
. | +--------+----------------------------------------------------+ | 2212 | An invalid NR-LDH label or A-label was found or | | | the domain name syntax is invalid in the "rcdn" | | | attribute. | +--------+----------------------------------------------------+ Table 1: Data Escrow Reporting Result Codes Lozano & Alvarez Expires 1 December 2024 [Page 26] Internet-Draft ICANN Registry Interfaces May 2024 6.2.1.2. Data Escrow Agent Reporting The following table lists the result codes of the Data Escrow Agent Reporting interface (see Section 2.2): +========+=================================================+ | Result | Message | | Code | | +========+=================================================+ | 1000 | No ERRORs were found, and the notification has | | | been accepted by ICANN. | +--------+-------------------------------------------------+ | 2001 | The request did not validate against the | | | schema. | +--------+-------------------------------------------------+ | 2002 | A DVPN notification exists for that date | | | (). | +--------+-------------------------------------------------+ | 2004 | Notification for a date in the future. The | | | and and date | | | should not be in the future. | +--------+-------------------------------------------------+ | 2005 | Version is not supported. | +--------+-------------------------------------------------+ | 2007 | Interface is disabled for this TLD. | +--------+-------------------------------------------------+ | 2008 | The and and date | | | should not be before the creation date of the | | | TLD in the system. | +--------+-------------------------------------------------+ | 2201 | The and in the | | | notification do not match. | +--------+-------------------------------------------------+ | 2202 | The in the
and the TLD in the | | | URL path do not match. | +--------+-------------------------------------------------+ | 2203 | A Deposit Verification Pass Notice (DVPN) | | | notification was received, but the Domain Name | | | count is missing in the
. | +--------+-------------------------------------------------+ | 2204 | The notification for the report "id" already | | | exists. | +--------+-------------------------------------------------+ | 2205 | Notification regarding a differential deposit | | | received when a full deposit was expected | | | (). | +--------+-------------------------------------------------+ | 2206 | csvDomain and rdeDomain count provided in the | Lozano & Alvarez Expires 1 December 2024 [Page 27] Internet-Draft ICANN Registry Interfaces May 2024 | |
. | +--------+-------------------------------------------------+ | 2207 | A DVPN or DVFN was received, but the | | | element is missing in the notification. | +--------+-------------------------------------------------+ | 2208 | A DRFN was received, but an element | | | exists in the notification. | +--------+-------------------------------------------------+ | 2209 | Missing required element in the
. | +--------+-------------------------------------------------+ | 2210 | The value of the "rcdn" attribute in the | | | element does not match the same or | | | lower level names in the in the URL path. | +--------+-------------------------------------------------+ | 2211 | Multiple count elements with the same "uri", | | | "rcdn", and "registrarId" attribute values | | | provided in the
. | +--------+-------------------------------------------------+ | 2212 | An invalid NR-LDH label or A-label was found or | | | the domain name syntax is invalid in the "rcdn" | | | attribute. | +--------+-------------------------------------------------+ Table 2: Data Escrow Reporting Result Codes 6.2.1.3. Per-Registrar Transactions Report The following table lists the result codes of the Per-Registrar Transactions Report interface (see Section 3.1): Lozano & Alvarez Expires 1 December 2024 [Page 28] Internet-Draft ICANN Registry Interfaces May 2024 +=============+============================================+ | Result Code | Message | +=============+============================================+ | 1000 | No ERRORs were found, and the report has | | | been accepted by ICANN. | +-------------+--------------------------------------------+ | 2001 | The structure of the report is invalid. | +-------------+--------------------------------------------+ | 2002 | A report for that month already exists, | | | the cut-off date already passed. | +-------------+--------------------------------------------+ | 2003 | Negative numeric value present in the | | | report. | +-------------+--------------------------------------------+ | 2004 | Report for a month in the future. | +-------------+--------------------------------------------+ | 2007 | Interface is disabled for this TLD. | +-------------+--------------------------------------------+ | 2008 | Reported month before the creation date of | | | the TLD in the system. | +-------------+--------------------------------------------+ | 2101 | Incorrect totals present in the report. | +-------------+--------------------------------------------+ | 2102 | A non-ICANN-accredited registrar is | | | present in the report. | +-------------+--------------------------------------------+ | 2103 | Values found in the second field of the | | | totals line. | +-------------+--------------------------------------------+ | 2105 | The report is not encoded in UTF-8. Note: | | | reports encoded in US-ASCII are accepted. | +-------------+--------------------------------------------+ Table 3: Per-Registrar Transactions Report Result Codes 6.2.1.4. Registry Functions Activity Report The following table lists the result codes of the Registry Functions Activity Report interface (see Section 3.2): Lozano & Alvarez Expires 1 December 2024 [Page 29] Internet-Draft ICANN Registry Interfaces May 2024 +=============+============================================+ | Result Code | Message | +=============+============================================+ | 1000 | No ERRORs were found, and the report has | | | been accepted by ICANN. | +-------------+--------------------------------------------+ | 2001 | The structure of the report is invalid. | +-------------+--------------------------------------------+ | 2002 | A report for that month already exists, | | | the cut-off date already passed. | +-------------+--------------------------------------------+ | 2003 | Negative numeric value present in the | | | report. | +-------------+--------------------------------------------+ | 2004 | Report for a month in the future. | +-------------+--------------------------------------------+ | 2007 | Interface is disabled for this TLD. | +-------------+--------------------------------------------+ | 2008 | Reported month before the creation date of | | | the TLD in the system. | +-------------+--------------------------------------------+ | 2105 | The report is not encoded in UTF-8. Note: | | | reports encoded in US-ASCII are accepted. | +-------------+--------------------------------------------+ Table 4: Registry Functions Activity Report Result Codes 6.2.1.5. Maintenance Window Management The following table lists the result codes of the Maintenance Window Management interface (see Section 4): +========+=====+========+=====+====================================+ | Result | PUT | DELETE | GET | Message | | Code | | | | | +========+=====+========+=====+====================================+ | 1000 | * | * | | No ERRORs were found, and the | | | | | | report has been accepted by ICANN. | +--------+-----+--------+-----+------------------------------------+ | 2001 | * | | | The request did not validate | | | | | | against the schema. | +--------+-----+--------+-----+------------------------------------+ | 2005 | * | | | Version is not supported. | +--------+-----+--------+-----+------------------------------------+ | 2006 | * | | | The scheduleId in the schedule | | | | | | object and the scheduleId in the | | | | | | URL PATH do not match. | +--------+-----+--------+-----+------------------------------------+ Lozano & Alvarez Expires 1 December 2024 [Page 30] Internet-Draft ICANN Registry Interfaces May 2024 | 2007 | * | * | * | Interface is disabled for this | | | | | | TLD. | +--------+-----+--------+-----+------------------------------------+ | 2401 | * | * | * | The syntax of the UUID in the PATH | | | | | | is incorrect. | +--------+-----+--------+-----+------------------------------------+ | 2402 | * | | | The maintenance window start date | | | | | | and time is not 24 hours ahead of | | | | | | the current date and time. | +--------+-----+--------+-----+------------------------------------+ | 2403 | * | | | The period specified by start and | | | | | | end date and time is greater than | | | | | | the monthly SLR for the service. | +--------+-----+--------+-----+------------------------------------+ | 2404 | * | | | The period specified in the | | | | | | maintenance window collides with a | | | | | | previously scheduled maintenance | | | | | | window for the service. | +--------+-----+--------+-----+------------------------------------+ | 2405 | | * | | The maintenance window that you | | | | | | are trying to delete already | | | | | | started. | +--------+-----+--------+-----+------------------------------------+ | 2406 | * | | | The endTime is in the past, before | | | | | | or equal to the startTime. | +--------+-----+--------+-----+------------------------------------+ | 2407 | * | | | The maintenance window that you | | | | | | are trying to update already | | | | | | ended, updates are not allowed. | +--------+-----+--------+-----+------------------------------------+ | 2408 | * | | | The maintenance window that you | | | | | | are trying to update already | | | | | | started, only enabled and endTime | | | | | | fields can be modified. | +--------+-----+--------+-----+------------------------------------+ Table 5: Maintenance Window Management Result Codes 7. Formal Syntax The schema of the IIRDEA Result, Report, Notification, RRI Reporting, Notifications, and Reports objects described in Section 1.4 are presented here. The and tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes. Lozano & Alvarez Expires 1 December 2024 [Page 31] Internet-Draft ICANN Registry Interfaces May 2024 7.1. RRI IIRDEA Result Schema ICANN interfaces for registries and data escrow agents 7.2. RRI Report Object Lozano & Alvarez Expires 1 December 2024 [Page 32] Internet-Draft ICANN Registry Interfaces May 2024 Data Escrow Report schema 7.3. RRI Notification Object Lozano & Alvarez Expires 1 December 2024 [Page 33] Internet-Draft ICANN Registry Interfaces May 2024 Data Escrow Notification schema 7.4. RRI Reporting Summary Object Lozano & Alvarez Expires 1 December 2024 [Page 35] Internet-Draft ICANN Registry Interfaces May 2024 7.5. RRI Notifications Object Lozano & Alvarez Expires 1 December 2024 [Page 36] Internet-Draft ICANN Registry Interfaces May 2024 7.6. RRI Reports Object Lozano & Alvarez Expires 1 December 2024 [Page 37] Internet-Draft ICANN Registry Interfaces May 2024 7.7. Maintenance Window Lozano & Alvarez Expires 1 December 2024 [Page 38] Internet-Draft ICANN Registry Interfaces May 2024 Lozano & Alvarez Expires 1 December 2024 [Page 39] Internet-Draft ICANN Registry Interfaces May 2024 7.8. SLAM Probe Node List Lozano & Alvarez Expires 1 December 2024 [Page 40] Internet-Draft ICANN Registry Interfaces May 2024 8. Acknowledgements Special suggestions that have been incorporated into this document were provided by David Kipling, James Gould, Gregory Zaltsman, Brett Carr, and Harel Efraim. 9. Change History [[RFC Editor: Please remove this section.]] 9.1. Version 00 Initial version. 9.2. Version 01 * and moved from escrow drafts to this draft * Added to * element of is now OPTIONAL * Added element to * and added to the draft * Several report elements are OPTIONAL to support async interfaces between Registry Operators and Data Escrow Agents * Added and to registry-escrow-report interface in order to make the interface idempotent and support async RyO-DEA interfaces * Added to escrow-agent-notification interface * The escrow-agent-notification uses POST and not PUT, this has been fixed * Several clarifications 9.3. Version 02 * Added and updated several result codes. * Added element. * Added Content-type definition. Lozano & Alvarez Expires 1 December 2024 [Page 41] Internet-Draft ICANN Registry Interfaces May 2024 9.4. Version 03 * Added several result codes. * unsignedShort is now used for result code in iirdea schema. * Enumeration was removed from the iirdea schema. 9.5. Version 04 * Added result codes: 2207 and 2208. * Removed result codes: 2203. * Added clarification regarding the support of HTTP streams. 9.6. Version 05 * Added result codes: 2007 and 2008. 9.7. Version 06 * Added clarification of error code HTTP/403 in Section 6. 9.8. Version 07 * Added Section 5: "Monitoring compliance with the New gTLD Base Agreement". 9.9. Version 08 * Reorganized specification structure to allow easier references from new specifications expanding functionality in the ICANN Registry Interfaces. * Added Section 1.4 to document object definitions, previously defined in other sections. * Added , , and object descriptions to Section 1.4, and schema definitions to Section 7. * Renamed Section 5 title as "Monitoring the reporting status". * Updated element as OPTIONAL in the schema. * Added OPTIONAL attribute "domainCount" to the element. Lozano & Alvarez Expires 1 December 2024 [Page 42] Internet-Draft ICANN Registry Interfaces May 2024 * Added OPTIONAL element to the schema. * Added result codes: 2105, 2209, 2210 and 2211. * Added "gTLD Base Registry Agreement" references. * Added clarifications to Section 6. 9.10. Version 09 * Standardized XSD schema validation error message for notifications and reports. * Element made optional in the schema. * Separated example RRI interface responses for successful and unsuccessful input. 9.11. Version 10 1. Ping update. 9.12. Version 11 1. Ping update. 9.13. Version 12 1. Ping update. 9.14. Version 13 1. IANA Considerations section added. 2. Implementation section added. 3. Internationalization Considerations status section added. 4. Security section added. 5. Editorial updates. 9.15. Version 14 1. Ping update. Lozano & Alvarez Expires 1 December 2024 [Page 43] Internet-Draft ICANN Registry Interfaces May 2024 9.16. Version 15 1. Added description and technical details for the interfaces for management of maintenance windows and list of probe nodes. 2. I-D was restructured to make it easier to read. 3. Editorial updates. 9.17. Version 16 1. Added interface description for supporting maintenance window objects and retrieving the IP addresses of the probe nodes used in the SLA Monitoring System (SLAM). 2. I-D was restructured to make it easier to read. 3. Editorial updates. 9.18. Version 17 1. Ping update. 9.19. Version 18 1. Ping update. 9.20. Version 19 1. Ping update. 9.21. Version 20 1. Ping update. 9.22. Version 21 1. Ping update. 9.23. Version 22 1. A note was added about suppressing alerts that reach the 10% emergency threshold when a maintenance window is active. Lozano & Alvarez Expires 1 December 2024 [Page 44] Internet-Draft ICANN Registry Interfaces May 2024 10. Internationalization Considerations The interfaces described in this document use XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an declaration, use of UTF-8 is RECOMMENDED. 11. IANA Considerations This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Six URI assignments have been registered by the IANA. Registration request for the RRI IIRDEA Result namespace: URI: urn:ietf:params:xml:ns:iirdea-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RRI IIRDEA Result XML schema: URI: urn:ietf:params:xml:ns:iirdea-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.1 of this document. Registration request for the RRI Report namespace: URI: urn:ietf:params:xml:ns:rdeReport-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Lozano & Alvarez Expires 1 December 2024 [Page 45] Internet-Draft ICANN Registry Interfaces May 2024 Registration request for the RRI Report schema: URI: urn:ietf:params:xml:ns:rdeReport-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.2 of this document. Registration request for the RRI Notification namespace: URI: urn:ietf:params:xml:ns:rdeNotification-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RRI Notification XML schema: URI: urn:ietf:params:xml:ns:rdeNotification-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.3 of this document. Registration request for the RRI Reporting Summary namespace: URI: urn:ietf:params:xml:ns:rriReporting-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RRI Reporting Summary XML schema: URI: urn:ietf:params:xml:ns:rriReporting-1.0 Lozano & Alvarez Expires 1 December 2024 [Page 46] Internet-Draft ICANN Registry Interfaces May 2024 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.4 of this document. Registration request for the RRI Notifications namespace: URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RRI Notifications XML schema: URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.5 of this document. Registration request for the RRI Reports namespace: URI: urn:ietf:params:xml:ns:rdeReports-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the RRI Reports XML schema: URI: urn:ietf:params:xml:ns:rdeReports-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. Lozano & Alvarez Expires 1 December 2024 [Page 47] Internet-Draft ICANN Registry Interfaces May 2024 See section Section 7.6 of this document. Registration request for the Maintenance Window namespace: URI: urn:ietf:params:xml:ns:schedule-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the Maintenance Window XML schema: URI: urn:ietf:params:xml:ns:schedule-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.7 of this document. Registration request for the SLAM Probe Node List namespace: URI: urn:ietf:params:xml:ns:probeNode-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. XML: None. Namespace URIs do not represent an XML specification. Registration request for the SLAM Probe Node List XML schema: URI: urn:ietf:params:xml:ns:probeNode-1.0 Registrant Contact: ICANN Note to RFC Editor: Please remove the email address from the RFC after IANA records it. See section Section 7.8 of this document. Lozano & Alvarez Expires 1 December 2024 [Page 48] Internet-Draft ICANN Registry Interfaces May 2024 12. Implementation Status Note to RFC Editor: Please remove this section and the reference to RFC 7942 [RFC7942] before publication. This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to RFC 7942 [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit". 12.1. Implementation in the gTLD space Organization: ICANN Name: ICANN Registry Agreement Description: the ICANN Base Registry Agreement requires Registries, Data Escrow Agents, and ICANN to implement this specification. ICANN receives daily notifications from Data Escrow Agents and Registries using this specification. Level of maturity: production. Coverage: all aspects of this specification are implemented. Version compatibility: versions 00 - 09 are known to be implemented. Contact: gustavo.lozano@icann.org URL: https://www.icann.org/resources/pages/registries/registries- agreements-en Lozano & Alvarez Expires 1 December 2024 [Page 49] Internet-Draft ICANN Registry Interfaces May 2024 13. Security Considerations The interfaces described in this document MUST be provided using HTTPS. The recommendations in [RFC7525] MUST be implemented. 14. References 14.1. Normative References [ICANN-GTLD-RA-20170731] ICANN, "Base Registry Agreement 2017-07-31", 31 July 2017, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8909] Lozano, G., "Registry Data Escrow Specification", RFC 8909, DOI 10.17487/RFC8909, November 2020, . [RFC9022] Lozano, G., Gould, J., and C. Thippeswamy, "Domain Name Registration Data (DNRD) Objects Mapping", RFC 9022, DOI 10.17487/RFC9022, May 2021, . Lozano & Alvarez Expires 1 December 2024 [Page 50] Internet-Draft ICANN Registry Interfaces May 2024 [W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition) REC-xml-20081126", November 2008, . [W3C.REC-xmlschema-1-20041028] Thompson, H. S., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition REC-xmlschema-1-20041028", October 2004, . [W3C.REC-xmlschema-2-20041028] Biron, P. V. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition REC-xmlschema-2-20041028", October 2004, . 14.2. Informative References [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015, . [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . Authors' Addresses Gustavo Lozano ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, 90292 United States of America Phone: +1.3103015800 Email: gustavo.lozano@icann.org Lozano & Alvarez Expires 1 December 2024 [Page 51] Internet-Draft ICANN Registry Interfaces May 2024 Eduardo Alvarez ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, 90292 United States of America Phone: +1.3103015800 Email: eduardo.alvarez@icann.org Lozano & Alvarez Expires 1 December 2024 [Page 52]