idnits 2.17.00 (12 Aug 2021) /tmp/idnits30275/draft-ietf-regext-simple-registration-reporting-06.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 document date (7 March 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2629' is defined on line 1521, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 1525, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1530, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Yee, Ed. 3 Internet-Draft J. Galvin 4 Intended status: Informational Donuts 5 Expires: 8 September 2022 7 March 2022 7 Simple Registration Reporting 8 draft-ietf-regext-simple-registration-reporting-06 10 Abstract 12 Domain name registries (the producer) and registrars (the consumer) 13 report to each other by sharing bulk information through files. This 14 document creates two IANA registries to establish a standard 15 reporting mechanism between domain name registries and registrars. 16 The first IANA registry lists standard data elements and their syntax 17 for inclusion in the files. The second IANA registry lists standard 18 reports based on the standard data elements. Each report is a file 19 formatted as a CSV file. The advantage of this reporting mechanism 20 is that a report, each file, can be imported by recipients without 21 any prior knowledge of their contents, although reporting is enhanced 22 with a minimum of knowledge about the files. The mechanism for the 23 distribution of and access of the files is a matter of local policy. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 8 September 2022. 42 Copyright Notice 44 Copyright (c) 2022 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Data Element Specification . . . . . . . . . . . . . . . . . 4 61 2.1. General Information Data Elements . . . . . . . . . . . . 5 62 2.1.1. TLD . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.2. Server_TRID . . . . . . . . . . . . . . . . . . . . . 5 64 2.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.4. Transaction_Type . . . . . . . . . . . . . . . . . . 5 66 2.1.5. Object_Type . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.6. DateTime . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.7. Term . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1.8. Fee . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.1.9. Currency . . . . . . . . . . . . . . . . . . . . . . 6 71 2.1.10. Status . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.1.11. Registrar . . . . . . . . . . . . . . . . . . . . . . 6 73 2.1.12. Period . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.13. Description . . . . . . . . . . . . . . . . . . . . . 6 75 2.2. Domain Price Data Elements . . . . . . . . . . . . . . . 6 76 2.2.1. Domain_Create . . . . . . . . . . . . . . . . . . . . 6 77 2.2.2. Domain_Renew . . . . . . . . . . . . . . . . . . . . 6 78 2.2.3. Domain_Transfer . . . . . . . . . . . . . . . . . . . 7 79 2.2.4. Domain_Restore . . . . . . . . . . . . . . . . . . . 7 80 2.2.5. Trade . . . . . . . . . . . . . . . . . . . . . . . . 7 81 2.3. Timestamp Data Elements . . . . . . . . . . . . . . . . . 7 82 2.3.1. Start_Date . . . . . . . . . . . . . . . . . . . . . 7 83 2.3.2. Deleted_Date . . . . . . . . . . . . . . . . . . . . 7 84 2.3.3. RGP_Date . . . . . . . . . . . . . . . . . . . . . . 7 85 2.3.4. Purge_Date . . . . . . . . . . . . . . . . . . . . . 7 86 2.3.5. Updated_Date . . . . . . . . . . . . . . . . . . . . 7 87 2.3.6. Create_Date . . . . . . . . . . . . . . . . . . . . . 8 88 2.3.7. Expiry_Date . . . . . . . . . . . . . . . . . . . . . 8 89 2.4. Registration Information Data Elements . . . . . . . . . 8 90 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 8 91 2.4.2. Server_Registrant_ID . . . . . . . . . . . . . . . . 8 92 2.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8 93 2.4.4. Server_Contact_ID . . . . . . . . . . . . . . . . . . 8 94 2.4.5. Contact_Type . . . . . . . . . . . . . . . . . . . . 8 95 2.4.6. Contact_Name . . . . . . . . . . . . . . . . . . . . 8 96 2.4.7. In_use . . . . . . . . . . . . . . . . . . . . . . . 9 97 2.4.8. Nameserver_Host . . . . . . . . . . . . . . . . . . . 9 98 2.4.9. Nameserver_IP . . . . . . . . . . . . . . . . . . . . 9 99 2.4.10. Client_Contact_ID . . . . . . . . . . . . . . . . . . 9 100 3. Report Definition Specification . . . . . . . . . . . . . . . 9 101 3.1. Domain Transaction . . . . . . . . . . . . . . . . . . . 10 102 3.2. Premium Name . . . . . . . . . . . . . . . . . . . . . . 11 103 3.3. Domain RGP . . . . . . . . . . . . . . . . . . . . . . . 11 104 3.4. Reserved Domain . . . . . . . . . . . . . . . . . . . . . 12 105 3.5. Domain Inventory . . . . . . . . . . . . . . . . . . . . 12 106 3.6. Contact Inventory . . . . . . . . . . . . . . . . . . . . 13 107 3.7. Host Inventory . . . . . . . . . . . . . . . . . . . . . 14 108 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 109 4.1. Report Specification . . . . . . . . . . . . . . . . . . 15 110 4.1.1. Designated Expert Evaluation Criteria . . . . . . . . 15 111 4.1.2. Registration Procedure . . . . . . . . . . . . . . . 16 112 4.1.2.1. Required Information . . . . . . . . . . . . . . 16 113 4.1.2.2. Registration Processing . . . . . . . . . . . . . 17 114 4.1.2.3. Updating Report Definition Registry Entries . . . 17 115 4.2. Initial assignments . . . . . . . . . . . . . . . . . . . 18 116 4.2.1. Data Element Definition in IANA Registry . . . . . . 18 117 4.2.2. Report Definition in IANA Registry . . . . . . . . . 29 118 5. Security Considerations . . . . . . . . . . . . . . . . . . . 32 119 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 120 7. Internationalization Considerations . . . . . . . . . . . . . 32 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 122 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 123 8.2. Informative References . . . . . . . . . . . . . . . . . 33 124 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 34 125 Appendix B. File Naming Convention . . . . . . . . . . . . . . . 34 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 128 1. Introduction 130 Currently, domain name registry operators (the producer) create and 131 set their own domain name registration reports for use by their 132 registrars (the consumer). Among the distinctions that vary by 133 producer is the syntax of the data provided, e.g., date formats, and 134 the format of the collection of the data provided, e.g., the report 135 may be a CSV file that tends to allow for straightforward importation 136 or a PDF file that can be problematic to import. In addition, 137 although there are a number of best practice reports that have 138 evolved, these are not currently documented as such, which results in 139 a fair amount of customization on the part of the consumers to import 140 data. 142 This document standardizes the name and syntax of the data elements 143 to be used across all existing domain name registration reports and 144 creates an IANA registry of them to facilitate their evolution, 145 including adding additional data elements as needed. In addition, a 146 known set of existing standard reports using the aforementioned data 147 elements is specified in another IANA registry to facilitate the 148 evolution of the reports and adding additional report definitions as 149 needed. 151 Each report definition MUST use only the data elements defined in the 152 data element aforementioned data element registry, including all 153 future reports. Note that a produced report MAY include data 154 elements that are not registered, as specified below. Future reports 155 and future data elements may be specified in their own individual 156 documents, updating the IANA registries as needed. 158 The mechanism for the distribution of and access to the files is a 159 matter of local policy. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Data Element Specification 169 Data elements are grouped into categories for convenience. There is 170 no other significance to the groupings. 172 Each data element conceptually represents the column heading in a 173 printed report. It is a single unit of information that can be 174 passed from the producer to the consumer. The primary purposes of 175 the IANA registry of data elements are to ensure that each data 176 element is assigned a unique name and that the syntax of each data 177 element is specified. 179 The name of the data element MUST be unique and this characteristic 180 MUST be enforced by the registry. The name is used in the report 181 definition (in the next section) to alert the consumer as to what to 182 expect in the file and how to import the data element. Character 183 encoding recommendation for data elements is specified in Section 7. 185 The subsections below comprise an initial list of known data elements 186 commonly being used between producers and consumers as of the date of 187 publication of this document. The title of the subsection is the 188 data element name for the data element. Data element names in the 189 IANA registry MUST be unique and MUST be processed as case 190 insensitive. 192 2.1. General Information Data Elements 194 2.1.1. TLD 196 The string of the top level domain involved that MUST be in A-label 197 format as defined by RFC 5890 [RFC5890]. 199 2.1.2. Server_TRID 201 The transaction identifier issued by an EPP Server. The format MUST 202 conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. 204 2.1.3. Domain 206 This is the domain name in an EPP RFC 5731 [RFC5731] domain object 207 and it MUST be in A-Label format. 209 2.1.4. Transaction_Type 211 The type of transform action made to the domain object (e.g., create, 212 delete, update, transfer, renew) as specified in RFC 5730 [RFC5730] 213 Section 2.9.3. 215 2.1.5. Object_Type 217 The object type involved in the report. In the EPP environment, an 218 object could be domain RFC 5731 [RFC5731], contact RFC 5733 219 [RFC5733], or host RFC 5732 [RFC5732]. 221 2.1.6. DateTime 223 The timestamp of the transaction recorded in the system. Dates and 224 Times MUST be expressed as defined in RFC 5731 [RFC5731] Section 2.4. 226 2.1.7. Term 228 The number of units added to the domain registration period in 229 RFC 5731 [RFC5731] in create, renew or transfer 230 transforms. If there is no , the default value set 231 out-of-band by the registry should be used. 233 2.1.8. Fee 235 The amount of money charged or returned (shown as a negative value) 236 to the registrar. The numeric format MUST conform to the currency 237 specified below in Section 2.1.9. The format must conform to 238 "balanceType" as defined in RFC 8748 [RFC8748]. 240 2.1.9. Currency 242 The currency used in the money charged as documented above in 243 Section 2.1.8. The currency code should follow the ISO 4217 244 [ISO4217] standard. 246 2.1.10. Status 248 The status of the domain object. It MUST be one of the values 249 specified in RFC 5731 [RFC5731] Section 2.3. 251 2.1.11. Registrar 253 The name of the registrar. This data element is text/string with no 254 naming convention enforced. 256 2.1.12. Period 258 The type of time (year, month) in 'Term' described above in 259 Section 2.1.7. The value of 'year' and 'month' are referenced to 260 pUnitType value 'y' and 'm' respectively. pUnitType is specified in 261 RFC 5731 [RFC5731]. 263 2.1.13. Description 265 Additional information regarding the current entry in the report. It 266 is provided by the producer and its actual value is a matter of local 267 policy. This data element is text/string with no naming convention 268 enforced. 270 2.2. Domain Price Data Elements 272 2.2.1. Domain_Create 274 The fee charged to create the domain. The format must conform to 275 "balanceType" as defined in RFC 8748 [RFC8748]. 277 2.2.2. Domain_Renew 279 The fee charged to renew the domain. The format must conform to 280 "balanceType" as defined in RFC 8748 [RFC8748]. 282 2.2.3. Domain_Transfer 284 The fee charged to transfer the domain. The format must conform to 285 "balanceType" as defined in RFC 8748 [RFC8748]. 287 2.2.4. Domain_Restore 289 The fee charged to restore the domain. The format must conform to 290 "balanceType" as defined in RFC 8748 [RFC8748]. 292 2.2.5. Trade 294 The fee charged to trade the domain. The format must conform to 295 "balanceType" as defined in RFC 8748 [RFC8748]. 297 2.3. Timestamp Data Elements 299 2.3.1. Start_Date 301 The timestamp of when the domain object becomes available. The date 302 and time format follows the "type=dateTime" specification as defined 303 in RFC 5731 [RFC5731]. 305 2.3.2. Deleted_Date 307 The timestamp of when the domain was deleted. The date and time 308 format follows the "type=dateTime" specification as defined in RFC 309 5731 [RFC5731]. 311 2.3.3. RGP_Date 313 The timestamp of when the domain will complete its redemption grace 314 period. The date and time format follows the "type=dateTime" 315 specification as defined in RFC 5731 [RFC5731]. 317 2.3.4. Purge_Date 319 The timestamp of when the domain will be purged and become available 320 again. The date and time format follows the "type=dateTime" 321 specification as defined in RFC 5731 [RFC5731]. 323 2.3.5. Updated_Date 325 The timestamp of the last time the domain object was updated. The 326 date and time format follows the "type=dateTime" specification as 327 defined in RFC 5731 [RFC5731]. 329 2.3.6. Create_Date 331 The timestamp of when the domain object was allocated. The date and 332 time format follows the "type=dateTime" specification as defined in 333 RFC 5731 [RFC5731]. 335 2.3.7. Expiry_Date 337 The timestamp of when the domain object will expire. The date and 338 time format follows the "type=dateTime" specification as defined in 339 RFC 5731 [RFC5731]. 341 2.4. Registration Information Data Elements 343 2.4.1. Registrar_ID 345 The identifier assigned to the registrar. If the registrar is 346 accredited under ICANN, it MUST be the registrar's IANA ID 347 [IANA_Registrar_IDs]. Otherwise it is a value known between the 348 producer and the consumer, set via an out-of-band mechanism and 349 unique within all reports of the producer. 351 2.4.2. Server_Registrant_ID 353 The identifier, issued by EPP server, assigned to the contact object 354 that is associated as registrant of the domain name that MUST conform 355 to "clIDType" specified in RFC 5730 [RFC5730]. 357 2.4.3. DNSSEC 359 The value MUST be either 'YES' or 'NO' to indicate whether the domain 360 is DNSSEC signed. 362 2.4.4. Server_Contact_ID 364 The identifier of the contact object assigned by the registry system 365 and MUST conform to "clIDType" specified in RFC 5730 [RFC5730]. 367 2.4.5. Contact_Type 369 The value MUST be one of value as defined by "contactAttrType" in RFC 370 5731 [RFC5731]. 372 2.4.6. Contact_Name 374 The name of the contact object. Usually it is the name of an 375 individual or an organization as described in RFC 5733 [RFC5733] 376 Section 2.3. 378 2.4.7. In_use 380 The value MUST be either "YES" or "NO" to indicate whether the 381 contact object is associated with a domain object. 383 2.4.8. Nameserver_Host 385 The full domain name of the host object as defined in RFC 5732 386 [RFC5732] Section 2.1. The name MUST be in A-label format as defined 387 by RFC5890 [RFC5890]. 389 2.4.9. Nameserver_IP 391 The IP address of the host object. The syntax of the IPv4 address 392 MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address 393 MUST conform to RFC 4291 [RFC4291]. 395 2.4.10. Client_Contact_ID 397 The identifier of the contact object assigned by the registrar and 398 MUST conform to "clIDType" specified in RFC 5730 [RFC5730]. 400 3. Report Definition Specification 402 Each report specification conceptually represents a file of comma 403 separated values [RFC4180] (commonly called a CSV file) where the 404 values are selected from the data elements specified above. The 405 first row of the file is a comma separated list of data element names 406 as specified in the data element registry. The remaining rows of the 407 file are the unordered sets of data elements, one set per row, where 408 each row is one transaction in the report. 410 Each data element in a set conceptually represents the column heading 411 in a printed report. 413 A consumer MUST be able to receive data elements that are not 414 recognized and MAY skip them accordingly, both in the header row and 415 in the transaction rows. 417 A report is specified in the report registry with two pieces of 418 information. First is the name of the report. This can be whatever 419 is appropriate as defined by the producer of the report. The name of 420 the report MUST be unique and this characteristic MUST be enforced by 421 registry. 423 Second is the ordered list of data element names of what is included 424 in the report. The data element names MUST be listed in the data 425 element registry specified above. The data element names and the 426 data MUST appear in the report in the order listed in the report 427 registry. 429 The subsections below comprise an initial list of standard reports 430 commonly being used between producers and consumers as of the date of 431 publication of this document. The title of the subsection is the 432 report name. The report name in the IANA registry MUST be unique and 433 MUST be processed as case insensitive. 435 3.1. Domain Transaction 437 Name of report: domain_transaction 439 +==================+========================+ 440 | Data Element | Reference | 441 +==================+========================+ 442 | TLD | RFC XXXX Section 2.1.1 | 443 +------------------+------------------------+ 444 | Server_TRID | Section 2.1.2 | 445 +------------------+------------------------+ 446 | Domain | Section 2.1.3 | 447 +------------------+------------------------+ 448 | DateTime | Section 2.1.6 | 449 +------------------+------------------------+ 450 | Registrar_ID | Section 2.4.1 | 451 +------------------+------------------------+ 452 | Registrar | Section 2.1.11 | 453 +------------------+------------------------+ 454 | Transaction_Type | Section 2.1.4 | 455 +------------------+------------------------+ 456 | Period | Section 2.1.12 | 457 +------------------+------------------------+ 458 | Term | Section 2.1.7 | 459 +------------------+------------------------+ 460 | Fee | Section 2.1.8 | 461 +------------------+------------------------+ 462 | Currency | Section 2.1.9 | 463 +------------------+------------------------+ 464 | Description | Section 2.1.13 | 465 +------------------+------------------------+ 467 Table 1: Transaction Report Definition Table 469 3.2. Premium Name 471 Name of report: premium_name 473 +=================+========================+ 474 | Data Element | Reference | 475 +=================+========================+ 476 | TLD | RFC XXXX Section 2.1.1 | 477 +-----------------+------------------------+ 478 | Domain | Section 2.1.3 | 479 +-----------------+------------------------+ 480 | Status | Section 2.1.10 | 481 +-----------------+------------------------+ 482 | Description | Section 2.1.13 | 483 +-----------------+------------------------+ 484 | Currency | Section 2.1.9 | 485 +-----------------+------------------------+ 486 | Domain_Create | Section 2.2.1 | 487 +-----------------+------------------------+ 488 | Domain_Renew | Section 2.2.2 | 489 +-----------------+------------------------+ 490 | Domain_Transfer | Section 2.2.3 | 491 +-----------------+------------------------+ 492 | Domain_Restore | Section 2.2.4 | 493 +-----------------+------------------------+ 494 | Start_Date | Section 2.3.1 | 495 +-----------------+------------------------+ 497 Table 2: Premium Name Report Definition 498 Table 500 3.3. Domain RGP 502 Name of report: domain_rgp 503 +==============+========================+ 504 | Data Element | Reference | 505 +==============+========================+ 506 | TLD | RFC XXXX Section 2.1.1 | 507 +--------------+------------------------+ 508 | Domain | Section 2.1.3 | 509 +--------------+------------------------+ 510 | Deleted_Date | Section 2.3.2 | 511 +--------------+------------------------+ 512 | RGP_Date | Section 2.3.3 | 513 +--------------+------------------------+ 514 | Purge_Date | Section 2.3.4 | 515 +--------------+------------------------+ 517 Table 3: Domain RGP Report Definition 518 Table 520 3.4. Reserved Domain 522 Name of report: reserved_domain 524 +==============+========================+ 525 | Data Element | Reference | 526 +==============+========================+ 527 | TLD | RFC XXXX Section 2.1.1 | 528 +--------------+------------------------+ 529 | Domain | Section 2.1.3 | 530 +--------------+------------------------+ 531 | Status | Section 2.1.10 | 532 +--------------+------------------------+ 534 Table 4: Reserved Domain Report 535 Definition Table 537 3.5. Domain Inventory 539 Name of report: domain_inventory 540 +======================+========================+ 541 | Data Element | Reference | 542 +======================+========================+ 543 | TLD | RFC XXXX Section 2.1.1 | 544 +----------------------+------------------------+ 545 | Domain | Section 2.1.3 | 546 +----------------------+------------------------+ 547 | Updated_Date | Section 2.3.5 | 548 +----------------------+------------------------+ 549 | Registrar_ID | Section 2.4.1 | 550 +----------------------+------------------------+ 551 | Create_Date | Section 2.3.6 | 552 +----------------------+------------------------+ 553 | Expiry_Date | Section 2.3.7 | 554 +----------------------+------------------------+ 555 | Server_Registrant_ID | Section 2.4.2 | 556 +----------------------+------------------------+ 557 | DNSSEC | Section 2.4.3 | 558 +----------------------+------------------------+ 559 | Status | Section 2.1.10 | 560 +----------------------+------------------------+ 562 Table 5: Domain Inventory Report Definition Table 564 3.6. Contact Inventory 566 Name of report: contact_inventory 567 +===================+================+ 568 | Data Element | Reference | 569 +===================+================+ 570 | Server_Contact_ID | Section 2.4.4 | 571 +-------------------+----------------+ 572 | Client_Contact_ID | Section 2.4.10 | 573 +-------------------+----------------+ 574 | TLD | Section 2.1.1 | 575 +-------------------+----------------+ 576 | Domain | Section 2.1.3 | 577 +-------------------+----------------+ 578 | Contact_Type | Section 2.4.5 | 579 +-------------------+----------------+ 580 | Contact_Name | Section 2.4.6 | 581 +-------------------+----------------+ 582 | Updated_Date | Section 2.3.5 | 583 +-------------------+----------------+ 584 | INUSE | Section 2.4.7 | 585 +-------------------+----------------+ 586 | Registrar_ID | Section 2.4.1 | 587 +-------------------+----------------+ 589 Table 6: Contact Inventory Report 590 Definition Table 592 3.7. Host Inventory 594 Name of report: host_inventory 596 +=================+=======================+ 597 | Data Element | Reference | 598 +=================+=======================+ 599 | TLD | RFCXXXX Section 2.1.1 | 600 +-----------------+-----------------------+ 601 | Nameserver_Host | Section 2.4.8 | 602 +-----------------+-----------------------+ 603 | Nameserver_IP | Section 2.4.9 | 604 +-----------------+-----------------------+ 606 Table 7: Host Inventory Report 607 Definition Table 609 4. IANA Considerations 611 This section describes the format of the IANA Registration Report 612 Registry, which has two tables described below, and the procedures 613 used to populate and manage the registry entries. 615 4.1. Report Specification 617 This registry uses the "Specification Required" policy described in 618 RFC 8126 [RFC8126]. An English language version of the extension 619 specification is required in the registry, though non-English 620 versions of the specification may also be provided. 622 The "Specification Required" policy implies review by a "designated 623 expert". Section 5.2 of RFC 8126 [RFC8126] describes the role of 624 designated experts and the function they perform. 626 4.1.1. Designated Expert Evaluation Criteria 628 A high-level description of the role of the designated expert is 629 described in Section 5.2 of RFC 8126 [RFC8126]. Specific guidelines 630 for the appointment of designated experts and the evaluation of a 631 Registration Report is provided here. 633 The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5) 634 to serve as designated experts, as described in Section 5.2 of RFC 635 8126 [RFC8126]. The pool should have a single administrative chair 636 who is appointed by the IESG. The designated experts should use the 637 existing regext mailing list (regext@ietf.org) for public discussion 638 of registration requests. This implies that the mailing list should 639 remain open after the work of the REGEXT working group has concluded. 641 The results of the evaluation should be shared via email with the 642 registrant and the regext mailing list. Issues discovered during the 643 evaluation can be corrected by the registrant, and those corrections 644 can be submitted to the designated experts until the designated 645 experts explicitly decide to accept or reject the registration 646 request. The designated experts must make an explicit decision and 647 that decision must be shared via email with the registrant and the 648 regext mailing list. If the specification for a data element or 649 report is an IETF Standards Track document, no review is required by 650 the designated expert. 652 Designated experts should be permissive in their evaluation of 653 requests for data elements and reports that have been implemented and 654 deployed by at least one registry. This implies that it may indeed 655 be possible to register multiple data elements or reports that 656 provide the same functionality. Requests to register data elements 657 or reports that have not been deployed should be evaluated with a 658 goal of reducing duplication. A potential registrant who submits a 659 request to register a new data element or report that includes 660 similar functionality to existing data elements or reports should be 661 made aware of the existing data elements and reports. The registrant 662 should be asked to reconsider their request given the existence of 663 similar data elements or reports. Should they decline to do so, 664 perceived similarity should not be a sufficient reason for rejection 665 as long as all other requirements are met. 667 4.1.2. Registration Procedure 669 The registry contains information describing each registered data 670 element or report. Registry entries are created and managed by 671 sending forms to IANA that describe the data element or report for 672 the registry entry. 674 4.1.2.1. Required Information 676 The required information must be formatted consistently using the 677 following registration form. Form field names and values may appear 678 on the same line. 680 4.1.2.1.1. Data Element Definition 682 Name of data element 683 MUST be unique within the registry, enforced to be unique, 684 and MUST be processed as case insensitive 686 Reference document 687 MUST define the data element, SHOULD be a URL to a RFC, and 688 SHOULD include the section number (or other detailed internal 689 document reference), MAY be a URL to any document available 690 under equivalent terms 692 Registrant 693 Will be IESG for initial entries and all Standards Track 694 specifications; otherwise as specified by the registran 696 Status 697 MUST be one of active, inactive, or unknown 699 4.1.2.1.2. Report Definition 701 Name of Report 702 MUST be unique within the registry, enforced to be unique, 703 and MUST be processed as case insensitive 705 Document Status 706 MUST be one of active, inactive, or unknown 708 Reference document 709 MUST define the report, SHOULD be a URL to a RFC and SHOULD 710 include the section number (or other detailed internal 711 document reference), MAY be a URL to any document available 712 under equivalent terms 714 Registrant 715 Will be IESG for initial entries and all Standards Track 716 specifications; otherwise as specified by the registrant 718 TLD 719 MUST be "ANY" if the report is intended to be generally 720 applicable or MAY be any top level domain formatted as 721 defined by RFC 5890 [RFC5890] (or comma separated list of 722 domains) and each MUST be an A-LABEL if the report is 723 intended to have that scope 725 Status:active 727 4.1.2.2. Registration Processing 729 Registrants should send each registration form to IANA with a single 730 record for incorporation into the registry. Send the form via email 731 to iana@iana.org or complete the online form found on the IANA web 732 site. The subject line should indicate whether the enclosed form 733 represents an insertion of a new record (indicated by the word 734 "INSERT" in the subject line) or a replacement of an existing record 735 (indicated by the word "MODIFY" in the subject line). At no time can 736 a record be deleted from the registry. On receipt of the 737 registration request, IANA will initiate review by the designated 738 expert(s) if appropriate, who will evaluate the request using the 739 criteria in Section 4.1.1 in consultation with the regext mailing 740 list. 742 4.1.2.3. Updating Report Definition Registry Entries 744 When submitting changes to existing registry entries, include text in 745 the "Notes" field of the registration form describing the change. 746 Under normal circumstances, registry entries are only to be updated 747 by the registrant. If the registrant becomes unavailable or 748 otherwise unresponsive, the designated expert can submit a 749 registration form to IANA to update the registrant information. 750 Entries can change state from "Active" to "Inactive" and back again 751 as long as state-change requests conform to the processing 752 requirements identified in this document. In addition to entries 753 that become "Inactive" due to a lack of implementation, entries for 754 which a specification becomes consistently unavailable over time 755 should be marked "Inactive" by the designated expert until the 756 specification again becomes reliably available. 758 4.2. Initial assignments 760 4.2.1. Data Element Definition in IANA Registry 762 ---- BEGIN FORM ---- 764 Name of data element: 765 TLD 767 Reference: 768 This RFC Section 2.1.1 770 Registrant: 771 IESG, iesg@ietf.org 773 Status: 774 Active 776 ---- END FORM ---- 778 ---- BEGIN FORM ---- 780 Name of data element: 781 Server_TRID 783 Reference: 784 This RFC Section 2.1.2 786 Registrant: 787 IESG, iesg@ietf.org 789 Status: 790 Active 792 ---- END FORM ---- 794 ---- BEGIN FORM ---- 796 Name of data element: 797 Domain 799 Reference: 800 This RFC Section 2.1.3 802 Registrant: 803 IESG, iesg@ietf.org 805 Status: 806 Active 808 ---- END FORM ---- 810 ---- BEGIN FORM ---- 812 Name of data element: 813 Transaction_Type 815 Reference: 816 This RFC Section 2.1.4 818 Registrant: 819 IESG, iesg@ietf.org 821 Status: 822 Active 824 ---- END FORM ---- 826 ---- BEGIN FORM ---- 828 Name of data element: 829 Ojbect_Type 831 Reference: 832 This RFC Section 2.1.5 834 Registrant: 835 IESG, iesg@ietf.org 837 Status: 838 Active 840 ---- END FORM ---- 842 ---- BEGIN FORM ---- 844 Name of data element: 845 DateTime 847 Reference: 848 This RFC Section 2.1.6 850 Registrant: 851 IESG, iesg@ietf.org 853 Status: 854 Active 856 ---- END FORM ---- 858 ---- BEGIN FORM ---- 860 Name of data element: 861 Term 863 Reference: 864 This RFC Section 2.1.7 866 Registrant: 867 IESG, iesg@ietf.org 869 Status: 870 Active 872 ---- END FORM ---- 874 ---- BEGIN FORM ---- 876 Name of data element: 877 Currency 879 Reference: 880 This RFC Section 2.1.9 882 Registrant: 883 IESG, iesg@ietf.org 885 Status: 886 Active 888 ---- END FORM ---- 890 ---- BEGIN FORM ---- 892 Name of data element: 893 Status 895 Reference: 896 This RFC Section 2.1.10 898 Registrant: 899 IESG, iesg@ietf.org 901 Status: 902 Active 904 ---- END FORM ---- 906 ---- BEGIN FORM ---- 908 Name of data element: 909 Registrar 911 Reference: 912 This RFC Section 2.1.11 914 Registrant: 915 IESG, iesg@ietf.org 917 Status: 918 Active 920 ---- END FORM ---- 922 ---- BEGIN FORM ---- 924 Name of data element: 925 Period 927 Reference: 928 This RFC Section 2.1.12 930 Registrant: 931 IESG, iesg@ietf.org 933 Status: 934 Active 936 ---- END FORM ---- 938 ---- BEGIN FORM ---- 940 Name of data element: 941 Description 943 Reference: 944 This RFC Section 2.1.13 946 Registrant: 947 IESG, iesg@ietf.org 949 Status: 950 Active 952 ---- END FORM ---- 954 ---- BEGIN FORM ---- 956 Name of data element: 957 Domain_Create 959 Reference: 960 This RFC Section 2.2.1 962 Registrant: 963 IESG, iesg@ietf.org 965 Status: 966 Active 968 ---- END FORM ---- 970 ---- BEGIN FORM ---- 972 Name of data element: 973 Domain_Renew 975 Reference: 976 This RFC Section 2.2.2 978 Registrant: 979 IESG, iesg@ietf.org 981 Status: 982 Active 984 ---- END FORM ---- 986 ---- BEGIN FORM ---- 988 Name of data element: 989 Domain_Transfer 991 Reference: 992 This RFC Section 2.2.3 994 Registrant: 995 IESG, iesg@ietf.org 997 Status: 998 Active 1000 ---- END FORM ---- 1002 ---- BEGIN FORM ---- 1004 Name of data element: 1005 Domain_Restore 1007 Reference: 1008 This RFC Section 2.2.4 1010 Registrant: 1011 IESG, iesg@ietf.org 1013 Status: 1014 Active 1016 ---- END FORM ---- 1018 ---- BEGIN FORM ---- 1020 Name of data element: 1021 Start_Date 1023 Reference: 1024 This RFC Section 2.3.1 1026 Registrant: 1027 IESG, iesg@ietf.org 1029 Status: 1030 Active 1032 ---- END FORM ---- 1034 ---- BEGIN FORM ---- 1036 Name of data element: 1037 Deleted_Date 1039 Reference: 1040 This RFC Section 2.3.2 1042 Registrant: 1043 IESG, iesg@ietf.org 1045 Status: 1046 Active 1048 ---- END FORM ---- 1050 ---- BEGIN FORM ---- 1052 Name of data element: 1053 RGP_Date 1055 Reference: 1056 This RFC Section 2.3.3 1058 Registrant: 1059 IESG, iesg@ietf.org 1061 Status: 1062 Active 1064 ---- END FORM ---- 1066 ---- BEGIN FORM ---- 1068 Name of data element: 1069 Purge_Date 1071 Reference: 1072 This RFC Section 2.3.4 1074 Registrant: 1075 IESG, iesg@ietf.org 1077 Status: 1078 Active 1080 ---- END FORM ---- 1082 ---- BEGIN FORM ---- 1084 Name of data element: 1085 Updated_Date 1087 Reference: 1088 This RFC Section 2.3.5 1090 Registrant: 1091 IESG, iesg@ietf.org 1093 Status: 1094 Active 1096 ---- END FORM ---- 1098 ---- BEGIN FORM ---- 1100 Name of data element: 1101 Create_Date 1103 Reference: 1104 This RFC Section 2.3.6 1106 Registrant: 1107 IESG, iesg@ietf.org 1109 Status: 1110 Active 1112 ---- END FORM ---- 1114 ---- BEGIN FORM ---- 1116 Name of data element: 1117 Expiry_Date 1119 Reference: 1120 This RFC Section 2.3.7 1122 Registrant: 1123 IESG, iesg@ietf.org 1125 Status: 1126 Active 1128 ---- END FORM ---- 1130 ---- BEGIN FORM ---- 1132 Name of data element: 1133 Registrar_ID 1135 Reference: 1136 This RFC Section 2.4.1 1138 Registrant: 1139 IESG, iesg@ietf.org 1141 Status: 1142 Active 1144 ---- END FORM ---- 1146 ---- BEGIN FORM ---- 1148 Name of data element: 1149 Server_Registrant_ID 1151 Reference: 1152 This RFC Section 2.4.2 1154 Registrant: 1155 IESG, iesg@ietf.org 1157 Status: 1158 Active 1160 ---- END FORM ---- 1162 ---- BEGIN FORM ---- 1164 Name of data element: 1165 DNSSEC 1167 Reference: 1168 This RFC Section 2.4.3 1170 Registrant: 1171 IESG, iesg@ietf.org 1173 Status: 1174 Active 1176 ---- END FORM ---- 1178 ---- BEGIN FORM ---- 1180 Name of data element: 1181 Server_Contact_ID 1183 Reference: 1184 This RFC Section 2.4.4 1186 Registrant: 1187 IESG, iesg@ietf.org 1189 Status: 1190 Active 1192 ---- END FORM ---- 1194 ---- BEGIN FORM ---- 1196 Name of data element: 1197 Contact_Type 1199 Reference: 1200 This RFC Section 2.4.5 1202 Registrant: 1203 IESG, iesg@ietf.org 1205 Status: 1206 Active 1208 ---- END FORM ---- 1210 ---- BEGIN FORM ---- 1212 Name of data element: 1213 Contact_Name 1215 Reference: 1216 This RFC Section 2.4.6 1218 Registrant: 1219 IESG, iesg@ietf.org 1221 Status: 1222 Active 1224 ---- END FORM ---- 1226 ---- BEGIN FORM ---- 1228 Name of data element: 1229 INUSE 1231 Reference: 1232 This RFC Section 2.4.7 1234 Registrant: 1235 IESG, iesg@ietf.org 1237 Status: 1238 Active 1240 ---- END FORM ---- 1242 ---- BEGIN FORM ---- 1244 Name of data element: 1245 Nameserver_Host 1247 Reference: 1248 This RFC Section 2.4.8 1250 Registrant: 1251 IESG, iesg@ietf.org 1253 Status: 1254 Active 1256 ---- END FORM ---- 1258 ---- BEGIN FORM ---- 1260 Name of data element: 1261 Nameserver_IP 1263 Reference: 1264 This RFC Section 2.4.9 1266 Registrant: 1267 IESG, iesg@ietf.org 1269 Status: 1270 Active 1272 ---- END FORM ---- 1274 ---- BEGIN FORM ---- 1276 Name of data element: 1277 Client_Contact_ID 1279 Reference: 1280 This RFC Section 2.4.10 1282 Registrant: 1283 IESG, iesg@ietf.org 1285 Status: 1286 Active 1288 ---- END FORM ---- 1290 4.2.2. Report Definition in IANA Registry 1292 ---- BEGIN FORM ---- 1294 Name of report: 1295 domain_transaction 1297 Reference: 1298 This RFC Table 1 1300 Registrant: 1301 IESG, iesg@ietf.org 1303 TLD: 1304 any 1306 Status: 1307 Active 1309 ---- END FORM ---- 1311 ---- BEGIN FORM ---- 1313 Name of report: 1314 premium_name 1316 Reference: 1317 This RFC Section 3.2 1319 Registrant: 1320 IESG, iesg@ietf.org 1322 TLD: 1323 any 1325 Status: 1326 Active 1328 ---- END FORM ---- 1330 ---- BEGIN FORM ---- 1331 Name of report: 1332 domain_rgp 1334 Reference: 1335 This RFC Section 3.3 1337 Registrant: 1338 IESG, iesg@ietf.org 1340 TLD: 1341 any 1343 Status: 1344 Active 1346 ---- END FORM ---- 1348 ---- BEGIN FORM ---- 1350 Name of report: 1351 reserved_domain 1353 Reference: 1354 This RFC Section 3.4 1356 Registrant: 1357 IESG, iesg@ietf.org 1359 TLD: 1360 any 1362 Status: 1363 Active 1365 ---- END FORM ---- 1367 ---- BEGIN FORM ---- 1369 Name of report: 1370 domain_inventory 1372 Reference: 1373 This RFC Section 3.5 1375 Registrant: 1376 IESG, iesg@ietf.org 1378 TLD: 1379 any 1381 Status: 1382 Active 1384 ---- END FORM ---- 1386 ---- BEGIN FORM ---- 1388 Name of report: 1389 contact_inventory 1391 Reference: 1392 This RFC Section 3.6 1394 Registrant: 1395 IESG, iesg@ietf.org 1397 TLD: 1398 any 1400 Status: 1401 Active 1403 ---- END FORM ---- 1405 ---- BEGIN FORM ---- 1407 Name of report: 1408 host_inventory 1410 Reference: 1411 This RFC Section 3.7 1413 Registrant: 1414 IESG, iesg@ietf.org 1416 TLD: 1417 any 1419 Status: 1420 Active 1422 ---- END FORM ---- 1424 5. Security Considerations 1426 This specification does not consider the issues of distribution or 1427 access to the reports that are created and thus does not introduce 1428 any new security security concerns that are not already present in 1429 the local environment in which the report is created. 1431 A security principle to keep in mind as new reports are developed is 1432 that it is considered a bad practice to report or disclose security 1433 information. In the case of the registration system upon which this 1434 reporting mechanism is based, the authInfo code is a specific example 1435 of a data element that SHOULD NOT be included in a report. 1437 6. Privacy Considerations 1439 This specification defines a mechanism for creating reports based on 1440 data in a registration system. Some of that data is likely to be 1441 considered personally identifiable information (PII) and thus would 1442 be subject to privacy protection according to an applicable privacy 1443 regulation. It is outside the scope of this specification to address 1444 those specific concerns. Implementors are urged to consider these 1445 issues with their local legal authority and develop appropriate 1446 requirements for their work. 1448 As expressly noted in the Introduction, distribution of and access to 1449 the reports created by this specification is expressly outside the 1450 scope of this specification. However, to the extent a report 1451 contains PII, implementors are urged to consider these issues with 1452 their local legal authority and develop appropriate requirements for 1453 their work. 1455 7. Internationalization Considerations 1457 The character encoding for the file contents MUST use UTF-8. 1459 Throughout this document A-LABEL is indicated as a SHOULD and that 1460 MUST be interpreted as follows. All domain name labels MUST be in 1461 A-LABEL format if it is possible to represent it as an A-LABEL, 1462 otherwise U-LABEL MAY be used. 1464 8. References 1466 8.1. Normative References 1468 [ISO4217] International Organization for Standardization, "ISO 4217 1469 Currency Codes", 2018, . 1472 [RFC0791] Postel, J., "Internet Protocol", September 1981, 1473 . 1475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1476 Requirement Levels", BCP 14, RFC 2119, 1477 DOI 10.17487/RFC2119, March 1997, 1478 . 1480 [RFC4180] Shafranovich, Y., "IP Version 6 Addressing Architecture", 1481 February 2006, . 1483 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1484 Architecture", February 2006, 1485 . 1487 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1488 August 2009, . 1490 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1491 Domain Name Mapping", August 2009, 1492 . 1494 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1495 Host Mapping", August 2009, 1496 . 1498 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1499 Contact Mapping", August 2009, 1500 . 1502 [RFC5890] Klensin, J., "Extensible Provisioning Protocol (EPP) 1503 Contact Mapping", August 2009, 1504 . 1506 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1507 Writing an IANA Considerations Section in RFCs", June 1508 2017, . 1510 [RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the 1511 Extensible Provisioning Protocol", March 2021, 1512 . 1514 8.2. Informative References 1516 [IANA_Registrar_IDs] 1517 Internet Assigned Numbers Authority, "IANA Assignments - 1518 Registrar IDs", 2020, . 1521 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1522 DOI 10.17487/RFC2629, June 1999, 1523 . 1525 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1526 Text on Security Considerations", BCP 72, RFC 3552, 1527 DOI 10.17487/RFC3552, July 2003, 1528 . 1530 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1531 IANA Considerations Section in RFCs", RFC 5226, 1532 DOI 10.17487/RFC5226, May 2008, 1533 . 1535 Appendix A. Acknowledgements 1537 The authors would like to thank Roger Carney, Jody Kolker, Tobias 1538 Sattler, and bestpractice.domains for their reviews and suggestions. 1540 Appendix B. File Naming Convention 1542 TBD on file naming convention suggestion 1544 Authors' Addresses 1546 Joseph Yee (editor) 1547 Donuts 1548 Toronto 1549 Canada 1550 Email: jyee@afilias.info 1552 James Galvin 1553 Donuts 1554 Horsham, PA 1555 United States 1556 Email: jgalvin@donuts.email