idnits 2.17.1 draft-lozano-icann-registry-interfaces-15.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 (Jul 6, 2021) is 1024 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '1-9' is mentioned on line 1229, but not defined -- Looks like a reference, but probably isn't: '012' on line 1229 -- Looks like a reference, but probably isn't: '12' on line 1229 == Missing Reference: '0-9' is mentioned on line 1229, but not defined -- Looks like a reference, but probably isn't: '01' on line 1229 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 5 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: January 7, 2022 Jul 6, 2021 7 ICANN Registry Interfaces 8 draft-lozano-icann-registry-interfaces-15 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 also described in this document. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 7, 2022. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2. Date and Time . . . . . . . . . . . . . . . . . . . . . . 3 56 1.3. Common elements used in this specification . . . . . . . 4 57 1.4. Object Description . . . . . . . . . . . . . . . . . . . 4 58 2. Interfaces for Specification 2 - Data Escrow Reporting . . . 10 59 2.1. Registry Operator Reporting . . . . . . . . . . . . . . . 10 60 2.2. Data Escrow Agent Reporting . . . . . . . . . . . . . . . 11 61 3. Interfaces of Specification 3 - Registry Operator Monthly 62 Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 3.1. Per-Registrar Transactions Report . . . . . . . . . . . . 13 64 3.2. Registry Functions Activity Report . . . . . . . . . . . 14 65 4. Technical details of the interfaces . . . . . . . . . . . . . 14 66 4.1. Response Object . . . . . . . . . . . . . . . . . . . . . 16 67 5. Monitoring the reporting status . . . . . . . . . . . . . . . 21 68 5.1. Monitoring the status of Data Escrow Reports . . . . . . 21 69 5.2. Monitoring the status of Data Escrow Notifications . . . 21 70 5.3. Monitoring the status of Registry Functions Activity 71 Report . . . . . . . . . . . . . . . . . . . . . . . . . 22 72 5.4. Monitoring the status of the Per-Registrar Transactions 73 Report . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 24 75 6.1. RRI IIRDEA Result Schema . . . . . . . . . . . . . . . . 24 76 6.2. RRI Report Object . . . . . . . . . . . . . . . . . . . . 25 77 6.3. RRI Notification Object . . . . . . . . . . . . . . . . . 26 78 6.4. RRI Reporting Summary Object . . . . . . . . . . . . . . 28 79 6.5. RRI Notifications Object . . . . . . . . . . . . . . . . 30 80 6.6. RRI Reports Object . . . . . . . . . . . . . . . . . . . 30 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 82 8. Change History . . . . . . . . . . . . . . . . . . . . . . . 31 83 8.1. Version 00 . . . . . . . . . . . . . . . . . . . . . . . 31 84 8.2. Version 01 . . . . . . . . . . . . . . . . . . . . . . . 31 85 8.3. Version 02 . . . . . . . . . . . . . . . . . . . . . . . 32 86 8.4. Version 03 . . . . . . . . . . . . . . . . . . . . . . . 32 87 8.5. Version 04 . . . . . . . . . . . . . . . . . . . . . . . 32 88 8.6. Version 05 . . . . . . . . . . . . . . . . . . . . . . . 33 89 8.7. Version 06 . . . . . . . . . . . . . . . . . . . . . . . 33 90 8.8. Version 07 . . . . . . . . . . . . . . . . . . . . . . . 33 91 8.9. Version 08 . . . . . . . . . . . . . . . . . . . . . . . 33 92 8.10. Version 09 . . . . . . . . . . . . . . . . . . . . . . . 33 93 8.11. Version 10 . . . . . . . . . . . . . . . . . . . . . . . 34 94 8.12. Version 11 . . . . . . . . . . . . . . . . . . . . . . . 34 95 8.13. Version 12 . . . . . . . . . . . . . . . . . . . . . . . 34 96 8.14. Version 13 . . . . . . . . . . . . . . . . . . . . . . . 34 97 8.15. Version 14 . . . . . . . . . . . . . . . . . . . . . . . 34 98 8.16. Version 15 . . . . . . . . . . . . . . . . . . . . . . . 34 99 9. Internationalization Considerations . . . . . . . . . . . . . 34 100 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 101 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 37 102 11.1. Implementation in the gTLD space . . . . . . . . . . . . 38 103 12. Security Considerations . . . . . . . . . . . . . . . . . . . 38 104 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 105 13.1. Normative References . . . . . . . . . . . . . . . . . . 39 106 13.2. Informative References . . . . . . . . . . . . . . . . . 40 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 109 1. Introduction 111 This document describes the technical details of the interfaces 112 provided by the Internet Corporation for Assigned Names and Numbers 113 (ICANN) to other contracted parties to fulfill reporting 114 requirements. The interface provided by ICANN to Registry Operators 115 and Data Escrow Agents to fulfill the requirements of Specifications 116 2 and 3 of the gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731] 117 are also described in this document. 119 Extensible Markup Language (XML) 1.0 as described in 120 [W3C.REC-xml-20081126] and XML Schema notation as described in 121 [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028] are 122 used in this specification. 124 The provisioning of credentials and authentication methods used in 125 the interfaces is outside of this document's scope. 127 1.1. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 XML is case sensitive. Unless stated otherwise, XML specifications 136 and examples provided in this document MUST be interpreted in the 137 character case presented to develop a conforming implementation. 139 1.2. Date and Time 141 Numerous fields indicate "date and time", such as the creation and 142 receipt dates for data escrow deposits. These fields SHALL contain 143 timestamps indicating the date and time in UTC as specified in 144 [RFC3339], with no offset from the zero meridian. 146 1.3. Common elements used in this specification 148 Common elements used in this specification are explained in this 149 section. 151 o : The base URL used in the reporting interfaces examples 152 must be replaced with the URL indicated by ICANN. 154 1.4. Object Description 156 This section describes the base objects supported by this 157 specification. 159 1.4.1. object 161 The ICANN interfaces for registries and data escrow agents (IIRDEA) 162 object is used to provide information on the result 163 of a verification process when interacting with the interfaces. 165 The object contains the following attribute and child 166 elements: 168 o A "code" attribute whose value is a four-digit decimal number that 169 identifies the result of a process. Available result code values 170 MUST be defined for the corresponding process. 172 o An OPTIONAL "domainCount" attribute to indicate the number of 173 domain names related to the reported result. 175 o A element containing a human-readable description of the 176 result code. 178 o An OPTIONAL element that includes additional details 179 on the result conditions. 181 An example of a object is presented below: 183 184 The structure of the report is invalid. 185 186 'XX' could not be parsed as a number (line: 2 column:3) 187 188 190 1.4.2. object 192 The contents of a data escrow deposit are described using a 193 object. The object contains 194 the following child elements: 196 o An element that contains the identifier assigned to this 197 report. The report identifier MUST be the same as the "id" 198 attribute from the . If the data escrow deposit does not 199 include a unique identifer, the Data Escrow Agent MUST generate a 200 unique identifier to reference the data escrow deposit and use it 201 in the element. 203 o A element contains the version of the specification 204 used. This value MUST be 1. 206 o A element contains the version of the Data Escrow 207 Specification (e.g. RFC8909) used to create the deposit. After 208 the specification is published as an RFC, the value MUST be the 209 RFC number assigned by IANA. 211 o An OPTIONAL element contains the version of the 212 Domain Name Registration Data (DNRD) Objects Mapping (e.g. 213 RFC9022) used to create the deposit. After the specification is 214 published as an RFC, the value MUST be the RFC number assigned by 215 IANA. The element MUST be included if the 216 deposit was created using any version of the DNRD objects mapping 217 specification (see, [RFC9022]). 219 o A element contains the value of the "resend" attribute of 220 the . 222 o A element contains the date and time that the deposit was 223 created by the Registry Operator. 225 o A element is used to identify the kind of deposit: FULL, 226 INCR (Incremental) or DIFF (Differential). 228 o A element contains the date and time corresponding to 229 the Timeline Watermark ( element) of the . 231 o A element contains the header of the 232 as defined in [RFC9022]. 234 An example of a object is available in 235 Section 2.1. 237 1.4.3. object 239 The object is used by Data Escrow 240 Agents to document the result of the data escrow deposit verification 241 process. The object contains the 242 following child elements: 244 o A element contains the name of the Data Escrow Agent. 246 o A element contains the version of the specification 247 used. This value MUST be 1. 249 o A element contains the reported date. In case of a DVPN 250 or DVFN notification, this value MUST be the date of the 251 element of the . In case of a DRFN deposit 252 notification, this value MUST be the date for which no deposit was 253 received from the Registrar or Registry Operator. 255 o A element is used to specify the status of . 256 The possible values of status are DVPN, DVFN, and DRFN. The value 257 for the element is determined by the three types of 258 notices: 260 * Deposit Receipt Failure Notice (DRFN): generated by the Data 261 Escrow Agent when no deposit is received pursuant to the data 262 escrow deposit schedule. 264 * Deposit Verification Failure Notice (DVFN): generated by the 265 Data Escrow Agent when a deposit is received, but the final 266 result of the verification process is a failure. 268 * Deposit Verification Pass Notice (DVPN): generated by the Data 269 Escrow Agent when a deposit is received and the final result of 270 the verification process is a success. 272 o An OPTIONAL element contains the errors detected during 273 the data escrow deposit verification process performed by the Data 274 Escrow Agent. The element includes one or more 275 elements as defined in Section 1.4.1. In case of 276 a DRFN or DVPN deposit notification, the element MUST 277 NOT be present. 279 o An OPTIONAL element contains the date and time that the 280 deposit was successfully received by the Data Escrow Agent. In 281 case of a DRFN deposit notification, this element MUST NOT be 282 present. 284 o An OPTIONAL element contains the date and time that the 285 deposit was processed for validation by the Data Escrow Agent. In 286 case of a DRFN deposit notification, this element MUST NOT be 287 present. 289 o An OPTIONAL element contains the date of the 290 Timeline Watermark ( element) of the most recent FULL 291 deposit that was successfully validated by the Data Escrow Agent. 292 This element MUST NOT be present if a successfully validated full 293 deposit has never been deposited. 295 o An OPTIONAL element is used by the Data Escrow 296 Agent to provide extended information about the deposit. In case 297 of a DRFN deposit notification, this element MUST NOT be present. 298 In case of a DVPN or DVFN deposit notification, this element MUST 299 be present. When this element is present, the 300 element MUST be generated by the Data Escrow Agent for the 301 Timeline Watermark ( element) of the deposit being 302 processed. If the deposit being processed is a differential or 303 incremental deposit, the Data Escrow Agent MUST process the last 304 full plus all differentials or last full plus last incremental 305 escrow deposits from the same repository (e.g., TLD) to generate 306 the element. 308 o Note: In case of a DVPN or DVFN deposit notification, the is 309 used as a unique identifier. 311 An example of a object is available in 312 Section 2.2. 314 1.4.4. Object 316 Interfaces that support monitoring the reporting status for a 317 specific repository, provide a object as 318 defined by the schema in Section 6 in the HTTP Entity-body when a 319 HTTP/200 code is sent by the interface. 321 The element includes the following child 322 elements: 324 o A choice of one of the elements as defined in the 325 "rdeHeader:repositoryTypeGroup" (see [RFC9022]) that indicates the 326 unique identifier for the repository being escrowed. 328 o A element with the date and time in which the 329 queried repository was created in the system. 331 o A OPTIONAL element indicating the current Data 332 Escrow Deposit schedule for the queried repository. Possible 333 values are "None", "Weekly", and "Daily". 335 o An OPTIONAL element indicating the date of the 336 Timeline Watermark ( element) of the most recent FULL 337 deposit that was successfully validated for the queried repository 338 as notified by the Data Escrow Agent. 340 o A element with a element for each 341 report type for the queried repository. Each 342 element includes the following child elements: 344 * : a string value indicating the report type to which the 345 information provided pertains. 347 * : a boolean value indicating if the report type is 348 enabled for the repository. 350 * : a string value indicating the reporting status. A 351 value of "ok" indicates there are no reporting issues in the 352 corresponding report type, otherwise the value of 353 "unsatisfactory" is shown. 355 * An OPTIONAL element included only when the 356 element has a value of "unsatisfactory", and includes an empty 357 element for each date with a reporting problem found in 358 the corresponding report type. Each element includes a 359 REQUIRED "date" attribute in "YYYY-MM-DD" format and a REQUIRED 360 "description" attribute to describe the issue. The possible 361 values to describe each reporting issue are: 363 + "Missing_Deposit_Full": If the latest notification received 364 from the Data Escrow Agent for the date indicates that a 365 scheduled "Full" deposit was not submitted by the repository 366 owner. 368 + "Missing_Deposit_Diff": If the latest notification received 369 from the Data Escrow Agent for the date indicates that a 370 scheduled "Differential" deposit was not submitted by the 371 repository owner. 373 + "Invalid_Deposit_Full": If the latest notification received 374 from the Data Escrow Agent for the date indicates that a 375 "Full" deposit was received by the Data Escrow Agent, but 376 failed the verification process. 378 + "Invalid_Deposit_Diff": If the latest notification received 379 from the Data Escrow Agent for the date indicates that a 380 "Differential" deposit was received by the Data Escrow 381 Agent, but failed the verification process. 383 + "No_Report_Received" If no report has been received for the 384 date. 386 o A element to indicate the date and time the reporting 387 status response was created. 389 1.4.5. Object 391 Interfaces that support monitoring and retrieving Data Escrow Reports 392 received, provide a object as defined by the 393 schema in Section 6 in the HTTP Entity-body when an HTTP/200 code is 394 sent by the interface. 396 The element includes a list of 397 objects, one for each 398 successfully received by ICANN. Each 399 object includes the following child elements: 401 o A element to indicate the date and time in which the 402 report was received by ICANN. 404 o A element as defined in Section 1.4.2 as 405 received by ICANN. 407 1.4.6. Object 409 Interfaces that support monitoring and retrieving Data Escrow 410 Notifications received from Data Escrow Agents, provide a 411 object as defined by the schema in 412 Section 6 in the HTTP Entity-body when an HTTP/200 code is sent by 413 the interface. 415 The element includes a list of 416 objects, one for each 417 successfully received by ICANN. Each 418 object includes the following 419 child elements: 421 o A element to indicate the date and time in which the 422 notification was received by ICANN. 424 o A element as defined in 425 Section 1.4.3 as received by ICANN. 427 2. Interfaces for Specification 2 - Data Escrow Reporting 429 This section describes the interfaces provided by ICANN to Registry 430 Operators and Data Escrow Agents to fulfill the reporting 431 requirements detailed in Specification 2 of the gTLD Base Registry 432 Agreement [ICANN-GTLD-RA-20170731]. 434 2.1. Registry Operator Reporting 436 The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], 437 Specification 2, Part A, Section 7 requires Registry Operators to 438 provide ICANN with a written statement that includes a copy of the 439 report generated upon creation of a deposit and a statement that the 440 deposit has been inspected by the Registry Operator and is complete 441 and accurate. 443 In order to satisfy this requirement, the Registry Operator sends to 444 ICANN a object as defined in Section 1.4.2 for 445 each deposit successfully sent to the Data Escrow Agent, using the 446 PUT HTTP verb in the interface provided by ICANN at: 448 /report/registry-escrow-report// 450 Where: 452 * MUST be substituted by the TLD for which the report is 453 being provided. In case of an IDN TLD, the A-label (see 454 [RFC5890]) MUST be used. 456 * MUST be substituted by the identifier assigned to this 457 report, which MUST be the same as the "id" attribute from the 458 . 460 Note: the interface supports overwriting the information of a 461 particular report to support asynchronous interfaces between 462 Registry Operators and Data Escrow Agents. 464 Example of a object for a data escrow deposit 465 corresponding to a TLD Registry repository: 467 468 471 20101017001 472 1 473 474 RFC8909 475 476 477 RFC9022 478 479 0 480 2010-10-17T00:15:00.0Z 481 FULL 482 2010-10-17T00:00:00Z 483 484 test 485 2 487 1 489 1 491 1 493 494 1 496 1 498 1 500 501 502 504 2.2. Data Escrow Agent Reporting 506 The gTLD Base Registry Agreement [ICANN-GTLD-RA-20170731], 507 Specification 2, Part B, Section 7 requires Data Escrow Agents, to 508 deliver ICANN with a notification object every time a successfully 509 processed deposit is received from the Registry Operator regardless 510 of the final status of the verification process. 512 To satisfy this requirement, the Data Escrow Agent sends to ICANN a 513 object as defined in Section 1.4.3, 514 using the POST HTTP verb in the interface provided by ICANN at: 516 /report/escrow-agent-notification/ 518 Where: 520 * MUST be substituted by the TLD for which the notification 521 is being provided. In case of an IDN TLD, the A-label (see 522 [RFC5890]) MUST be used. 524 If by 23:59:59 UTC, a deposit has not been successfully processed 525 regardless of the final status of the verification process, a 526 object with DRFN status MUST be send 527 to ICANN. 529 Example of a object of a Data Escrow 530 Agent notification corresponding to a Registry repository Data Escrow 531 Deposit: 533 534 538 Escrow Agent Inc. 539 1 540 2010-10-17 541 DVPN 542 543 2010-10-17T03:15:00.0Z 544 545 546 2010-10-17T05:15:00.0Z 547 548 549 2010-10-14 550 551 552 20101017001 553 1 554 555 RFC8909 556 557 558 RFC9022 559 560 0 561 2010-10-17T00:15:00.0Z 562 FULL 563 2010-10-17T00:00:00Z 564 565 test 566 1 568 3 570 1 572 3 574 1 576 10 578 0 580 581 582 584 3. Interfaces of Specification 3 - Registry Operator Monthly Reporting 586 Specification 3 of the gTLD Base Registry Agreement 587 [ICANN-GTLD-RA-20170731] requires Registry Operators to provide a set 588 of monthly reports per gTLD. Two types of reports are required to be 589 sent by Registries: Per-Registrar Transactions Report and Registry 590 Functions Activity Report. This section specifies the interfaces 591 provided by ICANN to automate the upload of these reports by Registry 592 Operators. 594 The cut-off date for the reception of the reports specified in 595 specification 3 is defined in the gTLD Base Registry Agreement 596 [ICANN-GTLD-RA-20170731]. Before the cut-off date the Registry 597 Operator could replace a successfully validated report as many times 598 as it needs. 600 3.1. Per-Registrar Transactions Report 602 The Per-Registrar Transactions Report is a CSV report encoded in 603 UTF-8 described in Section 1 of Specification 3. 605 To satisfy this requirement, the Registry Operator sends a CSV report 606 monthly as described in the gTLD Base Registry Agreement 608 [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the interface 609 provided by ICANN at: 611 /report/registrar-transactions// 613 Where: 615 * MUST be substituted by the TLD for which the reports is 616 being provided. In case of an IDN TLD, the A-label (see 617 [RFC5890]) MUST be used. 619 * MUST be substituted by the month for which the reports 620 is being provided in the form of YYYY-MM. Where 'YYYY' is the 621 year, and 'MM' is the two-digit month number. For example: 622 2013-03. 624 3.2. Registry Functions Activity Report 626 The Registry Functions Activity Report is a CSV report encoded in 627 UTF-8 described in Section 2 of Specification 3 of the gTLD Base 628 Registry Agreement [ICANN-GTLD-RA-20170731]. 630 In order to satisfy this requirement, the Registry Operator sends a 631 CSV report on a monthly basis as described in the gTLD Base Registry 632 Agreement [ICANN-GTLD-RA-20170731], using the PUT HTTP verb in the 633 interface provided by ICANN at: 635 /report/registry-functions-activity// 637 Where: 639 * MUST be substituted by the TLD for which the report is 640 being provided. In case of an IDN TLD, the A-label (see 641 [RFC5890]) MUST be used. 643 * MUST be substituted by the month for which the reports 644 is being provided in the form of YYYY-MM. Where 'YYYY' is the 645 year, and 'MM' is the two-digit month number. For example: 646 2013-03. 648 4. Technical details of the interfaces 650 Content-type value in the HTTP header: 652 o The client MUST set "text/xml" in the HTTP header Content-type 653 when using the Data Escrow Agent Reporting and Registry Operator 654 Reporting interfaces described in Section 2. 656 o The client MUST set "text/csv" in the HTTP header Content-type 657 when using the Per-Registrar Transactions Report Registry 658 Functions Activity Report interfaces described in Section 3. 660 The interfaces support HTTP streams only (HTTP multi-part forms are 661 not supported). 663 After successfully receiving input in any of the interfaces, ICANN 664 validates it and provides a object with a result element 665 in the same HTTP transaction. 667 The following HTTP status codes are standard across all interfaces: 669 o The interface provides an HTTP/200 status code and sets the HTTP 670 header Content-type: text/xml, if the interface was able to 671 receive the input successfully, the client MUST review the 672 response object to verify the result code after processing the 673 input. 675 o The interface provides an HTTP/400 status code and sets the HTTP 676 header Content-type: text/xml, if the input is incorrect or the 677 syntax of the input is invalid. A response object is included 678 with the input validation failure details. 680 o The interface provides an HTTP/401 status code and sets the HTTP 681 header Content-type: text/plain, if the credentials provided does 682 not authorize the Registry Operator to upload a report for that 683 . 685 o The interface provides an HTTP/403 status code and sets the HTTP 686 header Content-type: text/plain, if the credentials provided are 687 valid but are being used to access a resource that permission is 688 not granted for or the connecting IP address is not whitelisted 689 for the . 691 o The interface provides an HTTP/405 status code if the interface 692 does not support the request method. 694 o The interface provides an HTTP/500 status code and sets the HTTP 695 header Content-type: text/plain, if the system is experiencing a 696 general failure. The sending party is responsible for sending the 697 input again. 699 o The interface provides an HTTP/501 status code and sets the HTTP 700 header Content-type: text/plain, if the functionality has not yet 701 been implemented. 703 After sending the response, the interfaces closes the TCP connection. 705 4.1. Response Object 707 After processing the input provided in any of the interfaces, a 708 response object as defined by the schema in Section 6 is provided in 709 the HTTP Entity-body when an HTTP/200 or HTTP/400 status code is sent 710 by the interface. 712 An example of a response object upon successful input receipt is 713 presented below: 715 HTTP/1.1 200 OK 716 Content-Type: text/xml 717 Content-Length: 248 719 720 721 722 No ERRORs were found and the report has been 723 accepted by ICANN. 724 725 726 728 An example of a response object in the event of input error is 729 presented below: 731 HTTP/1.1 400 Bad Request 732 Content-Type: text/xml 733 Content-Length: 279 735 736 737 738 The structure of the report is invalid. 739 740 'XX' could not be parsed as a number (line: 2 column:3) 741 742 743 745 The following sections provide the IIRDEA Result Codes per interface: 747 4.1.1. Registry Operator Reporting 749 The following table lists the result codes of the interface: 751 +--------+----------------------------------------------------------+ 752 | Result | Message | 753 | Code | | 754 +--------+----------------------------------------------------------+ 755 | 1000 | No ERRORs were found, and the report has been accepted | 756 | | by ICANN. | 757 | 2001 | The request did not validate against the schema. | 758 | 2004 | Report for a date in the future. The and | 759 | | date should not be in the future. | 760 | 2005 | Version is not supported. | 761 | 2006 | The in the element and the in the URL | 762 | | path do not match. | 763 | 2007 | Interface is disabled for this TLD. | 764 | 2008 | The and date should not be before | 765 | | the creation date of the TLD in the system. | 766 | 2202 | The in the
and the TLD in the URL path do | 767 | | not match. | 768 | 2205 | Report regarding a differential deposit received when a | 769 | | full deposit was expected (). | 770 | 2206 | csvDomain and rdeDomain count provided in the
. | 771 | 2209 | Missing required element in the
. | 772 | 2210 | The value of the "rcdn" attribute in the element | 773 | | does not match the same or lower level names in the | 774 | | in the URL path. | 775 | 2211 | Multiple count elements with the same "uri", "rcdn", and | 776 | | "registrarId" attribute values provided in the
. | 777 | 2212 | An invalid NR-LDH label or A-label was found or the | 778 | | domain name syntax is invalid in the "rcdn" attribute. | 779 +--------+----------------------------------------------------------+ 781 Data Escrow Reporting Result Codes 783 4.1.2. Data Escrow Agent Reporting 785 The following table lists the result codes of the interface: 787 +--------+----------------------------------------------------------+ 788 | Result | Message | 789 | Code | | 790 +--------+----------------------------------------------------------+ 791 | 1000 | No ERRORs were found, and the notification has been | 792 | | accepted by ICANN. | 793 | 2001 | The request did not validate against the schema. | 794 | 2002 | A DVPN notification exists for that date (). | 795 | 2004 | Notification for a date in the future. The and | 796 | | and date should not be in the | 797 | | future. | 798 | 2005 | Version is not supported. | 799 | 2007 | Interface is disabled for this TLD. | 800 | 2008 | The and and date should | 801 | | not be before the creation date of the TLD in the | 802 | | system. | 803 | 2201 | The and in the notification do not | 804 | | match. | 805 | 2202 | The in the
and the TLD in the URL path do | 806 | | not match. | 807 | 2203 | A Deposit Verification Pass Notice (DVPN) notification | 808 | | was received, but the Domain Name count is missing in | 809 | | the
. | 810 | 2204 | The notification for the report "id" already exists. | 811 | 2205 | Notification regarding a differential deposit received | 812 | | when a full deposit was expected (). | 813 | 2206 | csvDomain and rdeDomain count provided in the
. | 814 | 2207 | A DVPN or DVFN was received, but the element is | 815 | | missing in the notification. | 816 | 2208 | A DRFN was received, but an element exists in | 817 | | the notification. | 818 | 2209 | Missing required element in the
. | 819 | 2210 | The value of the "rcdn" attribute in the element | 820 | | does not match the same or lower level names in the | 821 | | in the URL path. | 822 | 2211 | Multiple count elements with the same "uri", "rcdn", and | 823 | | "registrarId" attribute values provided in the
. | 824 | 2212 | An invalid NR-LDH label or A-label was found or the | 825 | | domain name syntax is invalid in the "rcdn" attribute. | 826 +--------+----------------------------------------------------------+ 828 Data Escrow Reporting Result Codes 830 4.1.3. Per-Registrar Transactions Report 832 The following table lists the result codes of the interface: 834 +----------+--------------------------------------------------------+ 835 | Result | Message | 836 | Code | | 837 +----------+--------------------------------------------------------+ 838 | 1000 | No ERRORs were found, and the report has been accepted | 839 | | by ICANN. | 840 | 2001 | The structure of the report is invalid. | 841 | 2002 | A report for that month already exists, the cut-off | 842 | | date already passed. | 843 | 2003 | Negative numeric value present in the report. | 844 | 2004 | Report for a month in the future. | 845 | 2007 | Interface is disabled for this TLD. | 846 | 2008 | Reported month before the creation date of the TLD in | 847 | | the system. | 848 | 2101 | Incorrect totals present in the report. | 849 | 2102 | A non-ICANN-accredited registrar is present in the | 850 | | report. | 851 | 2103 | Values found in the second field of the totals line. | 852 | 2105 | The report is not encoded in UTF-8. Note: reports | 853 | | encoded in US-ASCII are accepted. | 854 +----------+--------------------------------------------------------+ 856 Per-Registrar Transactions Report Result Codes 858 4.1.4. Registry Functions Activity Report 860 The following table lists the result codes of the interface: 862 +----------+--------------------------------------------------------+ 863 | Result | Message | 864 | Code | | 865 +----------+--------------------------------------------------------+ 866 | 1000 | No ERRORs were found, and the report has been accepted | 867 | | by ICANN. | 868 | 2001 | The structure of the report is invalid. | 869 | 2002 | A report for that month already exists, the cut-off | 870 | | date already passed. | 871 | 2003 | Negative numeric value present in the report. | 872 | 2004 | Report for a month in the future. | 873 | 2007 | Interface is disabled for this TLD. | 874 | 2008 | Reported month before the creation date of the TLD in | 875 | | the system. | 876 | 2105 | The report is not encoded in UTF-8. Note: reports | 877 | | encoded in US-ASCII are accepted. | 878 +----------+--------------------------------------------------------+ 880 Registry Functions Activity Report Result Codes 882 5. Monitoring the reporting status 884 Registries MAY monitor the status of the reports described in 885 Specification 2 and Specification 3 of the gTLD Base Registry 886 Agreement [ICANN-GTLD-RA-20170731] using the following interfaces 887 that supports the HEAD HTTP verb: 889 5.1. Monitoring the status of Data Escrow Reports 891 Registries MAY monitor the status of Data Escrow Reports using the 892 following interface: 894 /info/report/registry-escrow-report// 896 Where: 898 * MUST be substituted by the TLD being queried. In the 899 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 901 * MUST be substituted by the day being queried. For 902 example: 2013-03-02. 904 Possible results are: 906 * The interface provides an HTTP/200 status code, if a 907 syntactically valid data escrow report was received for the 908 queried date. 910 * The interface provides an HTTP/404 status code, if a 911 syntactically valid data escrow report has not been received 912 for the queried date. 914 5.2. Monitoring the status of Data Escrow Notifications 916 Registries and Data Escrow Agents MAY monitor the status of Data 917 Escrow Notifications using the following interface: 919 /info/report/escrow-agent-notification// 921 Where: 923 * MUST be substituted by the TLD being queried. In the 924 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 926 * MUST be substituted by the day being queried. For 927 example: 2013-03-02. 929 Possible results are: 931 * The interface provides an HTTP/200 status code, if a 932 syntactically valid data escrow notification was received for 933 the queried date. 935 * The interface provides an HTTP/404 status code, if a 936 syntactically valid data escrow notification has not been 937 received for the queried date. 939 5.3. Monitoring the status of Registry Functions Activity Report 941 Registries MAY monitor the status of Registry Functions Activity 942 Report using the following interface: 944 /info/report/registry-functions-activity// 946 Where: 948 * MUST be substituted by the TLD being queried. In the 949 case of an IDN TLD, the A-label (see [RFC5890]) MUST be used. 951 * MUST be substituted by the month being queried. For 952 example: 2013-03. 954 Possible results are: 956 * The interface provides an HTTP/200 status code, if a 957 syntactically valid registry functions activity report was 958 received for the queried month. 960 * The interface provides an HTTP/404 status code, if a 961 syntactically valid registry functions activity report has not 962 been received for the queried month. 964 5.4. Monitoring the status of the Per-Registrar Transactions Report 966 Registries MAY monitor the status of Per-Registrar Transactions 967 Report using the following interface: 969 /info/report/registrar-transactions// 971 Where: 973 * MUST be substituted by the TLD being queried. In case of 974 an IDN TLD, the A-label (see [RFC5890]) MUST be used. 976 * MUST be substituted by the month being queried. For 977 example: 2013-03. 979 Possible results are: 981 * The interface provides an HTTP/200 status code, if a 982 syntactically valid per-registrar transactions report was 983 received for the queried month. 985 * The interface provides an HTTP/404 status code, if a 986 syntactically valid per-registrar transactions report has not 987 been received for the queried month. 989 6. Formal Syntax 991 The schema of the IIRDEA Result, Report, Notification, RRI Reporting, 992 Notifications, and Reports objects described in Section 1.4 are 993 presented here. 995 The BEGIN and END tags are not part of the schema; they are used to 996 note the beginning and ending of the schema for URI registration 997 purposes. 999 6.1. RRI IIRDEA Result Schema 1000 BEGIN 1001 1002 1007 1008 1009 ICANN interfaces for registries and data escrow agents 1010 1011 1013 1014 1016 1017 1018 1019 1020 1022 1023 1024 1025 1027 1028 1030 1031 1033 1034 1035 1036 1037 1038 1040 1041 END 1043 6.2. RRI Report Object 1044 BEGIN 1045 1046 1053 1054 1056 1057 1058 Data Escrow Report schema 1059 1060 1062 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 END 1080 6.3. RRI Notification Object 1082 BEGIN 1083 1084 1091 1092 1094 1095 1096 Data Escrow Notification schema 1097 1098 1100 1103 1104 1105 1106 1107 1108 1109 1111 1112 1113 1114 1115 1116 1118 1119 1120 1121 1122 1123 1125 1126 1127 1128 1129 1131 1132 1133 1134 1135 1136 1137 1138 1139 END 1141 6.4. RRI Reporting Summary Object 1143 BEGIN 1144 1145 1151 1153 1155 1156 1157 1158 1159 1161 1162 1164 1165 1166 1168 1169 1170 1171 1172 1173 1174 1176 1177 1178 1180 1181 1183 1184 1185 1186 1187 1188 1190 1191 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1205 1206 1207 1208 1209 1210 1212 1213 1214 1216 1217 1219 1220 1222 1224 1226 1227 1228 1230 1231 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 END 1245 6.5. RRI Notifications Object 1247 BEGIN 1248 1249 1255 1257 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 END 1275 6.6. RRI Reports Object 1276 BEGIN 1277 1278 1284 1286 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 END 1303 7. Acknowledgements 1305 Special suggestions that have been incorporated into this document 1306 were provided by David Kipling, James Gould, Gregory Zaltsman, Brett 1307 Carr and Harel Efraim. 1309 8. Change History 1311 [[RFC Editor: Please remove this section.]] 1313 8.1. Version 00 1315 Initial version. 1317 8.2. Version 01 1319 o and moved from 1320 escrow drafts to this draft 1322 o Added to 1323 o element of is now OPTIONAL 1325 o Added element to 1327 o and added to the draft 1329 o Several report elements are OPTIONAL to support async interfaces 1330 between Registry Operators and Data Escrow Agents 1332 o Added and to registry-escrow-report interface in order 1333 to make the interface idempotent and support async RyO-DEA 1334 interfaces 1336 o Added to escrow-agent-notification interface 1338 o The escrow-agent-notification uses POST and not PUT, this has been 1339 fixed 1341 o Several clarifications 1343 8.3. Version 02 1345 o Added and updated several result codes. 1347 o Added element. 1349 o Added Content-type definition. 1351 8.4. Version 03 1353 o Added several result codes. 1355 o unsignedShort is now used for result code in iirdea schema. 1357 o Enumeration was removed from the iirdea schema. 1359 8.5. Version 04 1361 o Added result codes: 2207 and 2208. 1363 o Removed result codes: 2203. 1365 o Added clarification regarding the support of HTTP streams. 1367 8.6. Version 05 1369 o Added result codes: 2007 and 2008. 1371 8.7. Version 06 1373 o Added clarification of error code HTTP/403 in Section 4. 1375 8.8. Version 07 1377 o Added Section 5: "Monitoring compliance with the New gTLD Base 1378 Agreement". 1380 8.9. Version 08 1382 o Reorganized specification structure to allow easier references 1383 from new specifications expanding functionality in the ICANN 1384 Registry Interfaces. 1386 o Added Section 1.4 to document object definitions, previously 1387 defined in other sections. 1389 o Added , , and object 1390 descriptions to Section 1.4, and schema definitions to Section 6. 1392 o Renamed Section 5 title as "Monitoring the reporting status". 1394 o Updated element as OPTIONAL in the 1395 schema. 1397 o Added OPTIONAL attribute "domainCount" to the 1398 element. 1400 o Added OPTIONAL element to the schema. 1402 o Added result codes: 2105, 2209, 2210 and 2211. 1404 o Added "gTLD Base Registry Agreement" references. 1406 o Added clarifications to Section 4. 1408 8.10. Version 09 1410 o Standardized XSD schema validation error message for notifications 1411 and reports. 1413 o Element made optional in the schema. 1415 o Separated example RRI interface responses for successful and 1416 unsuccessful input. 1418 8.11. Version 10 1420 1. Ping update. 1422 8.12. Version 11 1424 1. Ping update. 1426 8.13. Version 12 1428 1. Ping update. 1430 8.14. Version 13 1432 1. IANA Considerations section added. 1434 2. Implementation section added. 1436 3. Internationalization Considerations status section added. 1438 4. Security section added. 1440 5. Editorial updates. 1442 8.15. Version 14 1444 1. Ping update. 1446 8.16. Version 15 1448 1. Fixes in the IANA Considerations. 1450 2. Citations for RFCs that were recently published. 1452 9. Internationalization Considerations 1454 The interfaces described in this document use XML, which provides 1455 native support for encoding information using the Unicode character 1456 set and its more compact representations including UTF-8. Conformant 1457 XML processors recognize both UTF-8 and UTF-16. Though XML includes 1458 provisions to identify and use other character encodings through use 1459 of an "encoding" attribute in an declaration, use of UTF-8 is 1460 RECOMMENDED. 1462 10. IANA Considerations 1464 This document uses URNs to describe XML namespaces and XML schemas 1465 conforming to a registry mechanism described in [RFC3688]. Six URI 1466 assignments have been registered by the IANA. 1468 Registration request for the RRI IIRDEA Result namespace: 1470 URI: urn:ietf:params:xml:ns:iirdea-1.0 1472 Registrant Contact: ICANN 1474 Note to RFC Editor: Please remove the email address from the RFC 1475 after IANA records it. 1477 XML: None. Namespace URIs do not represent an XML specification. 1479 Registration request for the RRI IIRDEA Result XML schema: 1481 URI: urn:ietf:params:xml:ns:iirdea-1.0 1483 Registrant Contact: ICANN 1485 Note to RFC Editor: Please remove the email address from the RFC 1486 after IANA records it. 1488 See section Section 6.1 of this document. 1490 Registration request for the RRI Report namespace: 1492 URI: urn:ietf:params:xml:ns:rdeReport-1.0 1494 Registrant Contact: ICANN 1496 Note to RFC Editor: Please remove the email address from the RFC 1497 after IANA records it. 1499 XML: None. Namespace URIs do not represent an XML specification. 1501 Registration request for the RRI Report schema: 1503 URI: urn:ietf:params:xml:ns:rdeReport-1.0 1505 Registrant Contact: ICANN 1507 Note to RFC Editor: Please remove the email address from the RFC 1508 after IANA records it. 1510 See section Section 6.2 of this document. 1512 Registration request for the RRI Notification namespace: 1514 URI: urn:ietf:params:xml:ns:rdeNotification-1.0 1516 Registrant Contact: ICANN 1518 Note to RFC Editor: Please remove the email address from the RFC 1519 after IANA records it. 1521 XML: None. Namespace URIs do not represent an XML specification. 1523 Registration request for the RRI Notification XML schema: 1525 URI: urn:ietf:params:xml:ns:rdeNotification-1.0 1527 Registrant Contact: ICANN 1529 Note to RFC Editor: Please remove the email address from the RFC 1530 after IANA records it. 1532 See section Section 6.3 of this document. 1534 Registration request for the RRI Reporting Summary namespace: 1536 URI: urn:ietf:params:xml:ns:rriReporting-1.0 1538 Registrant Contact: ICANN 1540 Note to RFC Editor: Please remove the email address from the RFC 1541 after IANA records it. 1543 XML: None. Namespace URIs do not represent an XML specification. 1545 Registration request for the RRI Reporting Summary XML schema: 1547 URI: urn:ietf:params:xml:ns:rriReporting-1.0 1549 Registrant Contact: ICANN 1551 Note to RFC Editor: Please remove the email address from the RFC 1552 after IANA records it. 1554 See section Section 6.4 of this document. 1556 Registration request for the RRI Notifications namespace: 1558 URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 1560 Registrant Contact: ICANN 1562 Note to RFC Editor: Please remove the email address from the RFC 1563 after IANA records it. 1565 XML: None. Namespace URIs do not represent an XML specification. 1567 Registration request for the RRI Notifications XML schema: 1569 URI: urn:ietf:params:xml:ns:rdeNotifications-1.0 1571 Registrant Contact: ICANN 1573 Note to RFC Editor: Please remove the email address from the RFC 1574 after IANA records it. 1576 See section Section 6.5 of this document. 1578 Registration request for the RRI Reports namespace: 1580 URI: urn:ietf:params:xml:ns:rdeReports-1.0 1582 Registrant Contact: ICANN 1584 Note to RFC Editor: Please remove the email address from the RFC 1585 after IANA records it. 1587 XML: None. Namespace URIs do not represent an XML specification. 1589 Registration request for the RRI Reports XML schema: 1591 URI: urn:ietf:params:xml:ns:rdeReports-1.0 1593 Registrant Contact: ICANN 1595 Note to RFC Editor: Please remove the email address from the RFC 1596 after IANA records it. 1598 See section Section 6.6 of this document. 1600 11. Implementation Status 1602 Note to RFC Editor: Please remove this section and the reference to 1603 RFC 7942 [RFC7942] before publication. 1605 This section records the status of known implementations of the 1606 protocol defined by this specification at the time of posting of this 1607 Internet-Draft, and is based on a proposal described in RFC 7942 1608 [RFC7942]. The description of implementations in this section is 1609 intended to assist the IETF in its decision processes in progressing 1610 drafts to RFCs. Please note that the listing of any individual 1611 implementation here does not imply endorsement by the IETF. 1612 Furthermore, no effort has been spent to verify the information 1613 presented here that was supplied by IETF contributors. This is not 1614 intended as, and must not be construed to be, a catalog of available 1615 implementations or their features. Readers are advised to note that 1616 other implementations may exist. 1618 According to RFC 7942 [RFC7942], "this will allow reviewers and 1619 working groups to assign due consideration to documents that have the 1620 benefit of running code, which may serve as evidence of valuable 1621 experimentation and feedback that have made the implemented protocols 1622 more mature. It is up to the individual working groups to use this 1623 information as they see fit". 1625 11.1. Implementation in the gTLD space 1627 Organization: ICANN 1629 Name: ICANN Registry Agreement 1631 Description: the ICANN Base Registry Agreement requires Registries, 1632 Data Escrow Agents, and ICANN to implement this specification. ICANN 1633 receives daily notifications from Data Escrow Agents and Registries 1634 using this specification. 1636 Level of maturity: production. 1638 Coverage: all aspects of this specification are implemented. 1640 Version compatibility: versions 00 - 09 are known to be implemented. 1642 Contact: gustavo.lozano@icann.org 1644 URL: https://www.icann.org/resources/pages/registries/registries- 1645 agreements-en 1647 12. Security Considerations 1649 The interfaces described in this document MUST be provided using 1650 HTTPS. The recommendations in [RFC7525] MUST be implemented. 1652 13. References 1654 13.1. Normative References 1656 [ICANN-GTLD-RA-20170731] 1657 ICANN, "Base Registry Agreement 2017-07-31", July 2017, 1658 . 1661 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1662 Requirement Levels", BCP 14, RFC 2119, 1663 DOI 10.17487/RFC2119, March 1997, 1664 . 1666 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1667 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1668 . 1670 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1671 DOI 10.17487/RFC3688, January 2004, 1672 . 1674 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1675 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1676 May 2017, . 1678 [RFC9022] Lozano, G., Gould, J., and C. Thippeswamy, "Domain Name 1679 Registration Data (DNRD) Objects Mapping", RFC 9022, 1680 DOI 10.17487/RFC9022, May 2021, 1681 . 1683 [W3C.REC-xml-20081126] 1684 Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 1685 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 1686 Edition) REC-xml-20081126", November 2008, 1687 . 1689 [W3C.REC-xmlschema-1-20041028] 1690 Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, 1691 "XML Schema Part 1: Structures Second Edition REC- 1692 xmlschema-1-20041028", October 2004, 1693 . 1695 [W3C.REC-xmlschema-2-20041028] 1696 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 1697 Second Edition REC-xmlschema-2-20041028", October 2004, 1698 . 1700 13.2. Informative References 1702 [RFC5890] Klensin, J., "Internationalized Domain Names for 1703 Applications (IDNA): Definitions and Document Framework", 1704 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1705 . 1707 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1708 "Recommendations for Secure Use of Transport Layer 1709 Security (TLS) and Datagram Transport Layer Security 1710 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1711 2015, . 1713 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1714 Code: The Implementation Status Section", BCP 205, 1715 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1716 . 1718 Authors' Addresses 1720 Gustavo Lozano 1721 ICANN 1722 12025 Waterfront Drive, Suite 300 1723 Los Angeles 90292 1724 US 1726 Phone: +1.3103015800 1727 Email: gustavo.lozano@icann.org 1729 Eduardo Alvarez 1730 ICANN 1731 12025 Waterfront Drive, Suite 300 1732 Los Angeles 90292 1733 US 1735 Phone: +1.3103015800 1736 Email: eduardo.alvarez@icann.org