idnits 2.17.1 draft-ietf-regext-simple-registration-reporting-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 June 2022) is 688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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: 10 December 2022 8 June 2022 7 Simple Registration Reporting 8 draft-ietf-regext-simple-registration-reporting-07 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 10 December 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. Date_Time . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.7. Period . . . . . . . . . . . . . . . . . . . . . . . 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_Unit . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.13. Description . . . . . . . . . . . . . . . . . . . . . 6 75 2.2. Domain Price Data Elements . . . . . . . . . . . . . . . 6 76 2.2.1. Price_Domain_Create . . . . . . . . . . . . . . . . . 6 77 2.2.2. Price_Domain_Renew . . . . . . . . . . . . . . . . . 7 78 2.2.3. Price_Domain_Transfer . . . . . . . . . . . . . . . . 7 79 2.2.4. Price_Domain_Restore . . . . . . . . . . . . . . . . 7 80 2.2.5. Price_Domain_Trade . . . . . . . . . . . . . . . . . 7 81 2.3. Timestamp Data Elements . . . . . . . . . . . . . . . . . 7 82 2.3.1. Available_Date . . . . . . . . . . . . . . . . . . . 7 83 2.3.2. Deleted_Date . . . . . . . . . . . . . . . . . . . . 7 84 2.3.3. Redemption_End_Date . . . . . . . . . . . . . . . . . 7 85 2.3.4. Pending_Delete_Date . . . . . . . . . . . . . . . . . 7 86 2.3.5. Updated_Date . . . . . . . . . . . . . . . . . . . . 8 87 2.3.6. Created_Date . . . . . . . . . . . . . . . . . . . . 8 88 2.3.7. Expiration_Date . . . . . . . . . . . . . . . . . . . 8 89 2.4. Registration Information Data Elements . . . . . . . . . 8 90 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 8 91 2.4.2. 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 . . . . . . . . . . . . . . . . . . . . 9 96 2.4.7. Linked . . . . . . . . . . . . . . . . . . . . . . . 9 97 2.4.8. Host_Name . . . . . . . . . . . . . . . . . . . . . . 9 98 2.4.9. Host_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 . . . . . . . . . . . . . . . . . . . . . . . 12 104 3.4. Reserved Domain . . . . . . . . . . . . . . . . . . . . . 13 105 3.5. Domain Inventory . . . . . . . . . . . . . . . . . . . . 13 106 3.6. Contact Inventory . . . . . . . . . . . . . . . . . . . . 14 107 3.7. Host Inventory . . . . . . . . . . . . . . . . . . . . . 15 108 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 109 4.1. Report Specification . . . . . . . . . . . . . . . . . . 16 110 4.1.1. Designated Expert Evaluation Criteria . . . . . . . . 16 111 4.1.2. Registration Procedure . . . . . . . . . . . . . . . 17 112 4.1.2.1. Required Information . . . . . . . . . . . . . . 17 113 4.1.2.2. Registration Processing . . . . . . . . . . . . . 18 114 4.1.2.3. Updating Report Definition Registry Entries . . . 18 115 4.2. Initial assignments . . . . . . . . . . . . . . . . . . . 19 116 4.2.1. Data Element Definition in IANA Registry . . . . . . 19 117 4.2.2. Report Definition in IANA Registry . . . . . . . . . 30 118 5. Security Considerations . . . . . . . . . . . . . . . . . . . 33 119 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 33 120 7. Internationalization Considerations . . . . . . . . . . . . . 33 121 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 122 8.1. Normative References . . . . . . . . . . . . . . . . . . 33 123 8.2. Informative References . . . . . . . . . . . . . . . . . 34 124 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 35 125 Appendix B. File Naming Convention . . . . . . . . . . . . . . . 35 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 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 practices that have evolved, 138 these are not currently documented as such, which results in a fair 139 amount of customization on the part of the consumers to import data. 141 This document standardizes the name and syntax of the data elements 142 to be used across all existing domain name registration reports and 143 creates an IANA registry of them to facilitate their evolution, 144 including adding additional data elements as needed. In addition, a 145 known set of existing standard reports using the aforementioned data 146 elements is specified in another IANA registry to facilitate the 147 evolution of the reports and adding additional report definitions as 148 needed. 150 Each report definition MUST use only the data elements defined in the 151 data element aforementioned data element registry, including all 152 future reports. Note that a produced report MAY include data 153 elements that are not registered, as specified below. Future reports 154 and future data elements may be specified in their own individual 155 documents, updating the IANA registries as needed. 157 The mechanism for the distribution of and access to the files is a 158 matter of local policy. 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. Data Element Specification 168 Data elements are grouped into categories for convenience. There is 169 no other significance to the groupings. 171 Each data element conceptually represents the column heading in a 172 printed report. It is a single unit of information that can be 173 passed from the producer to the consumer. The primary purposes of 174 the IANA registry of data elements are to ensure that each data 175 element is assigned a unique name and that the syntax of each data 176 element is specified. 178 The name of the data element MUST be unique and this characteristic 179 MUST be enforced by the registry. The name is used in the report 180 definition (in the next section) to alert the consumer as to what to 181 expect in the file and how to import the data element. Character 182 encoding recommendation for data elements is specified in Section 7. 184 The data elements adopt the same naming convention, where all the 185 leading character of each word use upper-case and the rest in lower- 186 case, and each word join with symobl underbars as a word separator. 188 The subsections below comprise an initial list of known data elements 189 commonly being used between producers and consumers as of the date of 190 publication of this document. The title of the subsection is the 191 data element name for the data element. Data element names in the 192 IANA registry MUST be unique and MUST be processed as case 193 insensitive. 195 2.1. General Information Data Elements 197 2.1.1. TLD 199 The string of the top level domain involved that MUST be in A-label 200 format as defined by RFC 5890 [RFC5890]. 202 2.1.2. Server_TRID 204 The transaction identifier issued by an EPP Server. The format MUST 205 conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. 207 2.1.3. Domain 209 This is the domain name in an EPP RFC 5731 [RFC5731] domain object 210 and it MUST be in A-Label format. 212 2.1.4. Transaction_Type 214 The type of transform action made to the domain object (e.g., create, 215 delete, update, transfer, renew) as specified in RFC 5730 [RFC5730] 216 Section 2.9.3. 218 2.1.5. Object_Type 220 The object type involved in the report. In the EPP environment, an 221 object could be domain RFC 5731 [RFC5731], contact RFC 5733 222 [RFC5733], or host RFC 5732 [RFC5732]. 224 2.1.6. Date_Time 226 The timestamp of the transaction recorded in the system. Dates and 227 Times MUST be expressed as defined in RFC 5731 [RFC5731] Section 2.4. 229 2.1.7. Period 231 The number of units added to the domain registration period in 232 RFC 5731 [RFC5731] in create, renew or transfer 233 transforms. If there is no , the default value set 234 out-of-band by the registry should be used. 236 2.1.8. Fee 238 The amount of money charged or returned (shown as a negative value) 239 to the registrar. The numeric format MUST conform to the currency 240 specified below in Section 2.1.9. The format must conform to 241 "balanceType" as defined in RFC 8748 [RFC8748]. 243 2.1.9. Currency 245 The currency used in the money charged as documented above in 246 Section 2.1.8. The currency code should follow the ISO 4217 247 [ISO4217] standard. 249 2.1.10. Status 251 The status or statuses of the domain object. It MUST be one of the 252 values specified in RFC 5731 [RFC5731] Section 2.3. If there are 253 multiple statuses, each must be separated by symbol commma, with the 254 whole string under double quotes as specified in RFC 4180 [RFC4180] 256 2.1.11. Registrar 258 The name of the registrar. This data element is text/string with no 259 naming convention enforced. The string must be under double quotes 260 if it contains comma symbol as specified in RFC 4180 [RFC4180] 262 2.1.12. Period_Unit 264 The type of time (year, month) in 'Period' described above in 265 Section 2.1.7. The value of 'year' and 'month' are referenced to 266 pUnitType value 'y' and 'm' respectively. pUnitType is specified in 267 RFC 5731 [RFC5731]. 269 2.1.13. Description 271 Additional information regarding the current entry in the report. It 272 is provided by the producer and its actual value is a matter of local 273 policy. This data element is text/string with no naming convention 274 enforced. 276 2.2. Domain Price Data Elements 278 2.2.1. Price_Domain_Create 280 The fee charged to create the domain. The format must conform to 281 "balanceType" as defined in RFC 8748 [RFC8748]. 283 2.2.2. Price_Domain_Renew 285 The fee charged to renew the domain. The format must conform to 286 "balanceType" as defined in RFC 8748 [RFC8748]. 288 2.2.3. Price_Domain_Transfer 290 The fee charged to transfer the domain. The format must conform to 291 "balanceType" as defined in RFC 8748 [RFC8748]. 293 2.2.4. Price_Domain_Restore 295 The fee charged to restore the domain. The format must conform to 296 "balanceType" as defined in RFC 8748 [RFC8748]. 298 2.2.5. Price_Domain_Trade 300 The fee charged to trade the domain. The format must conform to 301 "balanceType" as defined in RFC 8748 [RFC8748]. 303 2.3. Timestamp Data Elements 305 2.3.1. Available_Date 307 The timestamp of when the domain object becomes available. The date 308 and time format follows the "type=dateTime" specification as defined 309 in RFC 5731 [RFC5731]. 311 2.3.2. Deleted_Date 313 The timestamp of when the domain was deleted. The date and time 314 format follows the "type=dateTime" specification as defined in RFC 315 5731 [RFC5731]. 317 2.3.3. Redemption_End_Date 319 The timestamp of when the domain will complete its redemption grace 320 period. The date and time format follows the "type=dateTime" 321 specification as defined in RFC 5731 [RFC5731]. 323 2.3.4. Pending_Delete_Date 325 The timestamp of when the domain will be purged and become available 326 again. The date and time format follows the "type=dateTime" 327 specification as defined in RFC 5731 [RFC5731]. 329 2.3.5. Updated_Date 331 The timestamp of the last time the domain object was updated. The 332 date and time format follows the "type=dateTime" specification as 333 defined in RFC 5731 [RFC5731]. 335 2.3.6. Created_Date 337 The timestamp of when the domain object was allocated. The date and 338 time format follows the "type=dateTime" specification as defined in 339 RFC 5731 [RFC5731]. 341 2.3.7. Expiration_Date 343 The timestamp of when the domain object will expire. The date and 344 time format follows the "type=dateTime" specification as defined in 345 RFC 5731 [RFC5731]. 347 2.4. Registration Information Data Elements 349 2.4.1. Registrar_ID 351 The identifier assigned to the registrar. If the registrar is 352 accredited under ICANN, it MUST be the registrar's IANA ID 353 [IANA_Registrar_IDs]. Otherwise it is a value known between the 354 producer and the consumer, set via an out-of-band mechanism and 355 unique within all reports of the producer. 357 2.4.2. Registrant_ID 359 The identifier, issued by EPP server, assigned to the contact object 360 that is associated as registrant of the domain name that MUST conform 361 to "clIDType" specified in RFC 5730 [RFC5730]. 363 2.4.3. DNSSEC 365 The value MUST be either 'YES' or 'NO' to indicate whether the domain 366 is DNSSEC signed. 368 2.4.4. Server_Contact_ID 370 The identifier of the contact object assigned by the registry system 371 and MUST conform to "clIDType" specified in RFC 5730 [RFC5730]. 373 2.4.5. Contact_Type 375 The value MUST be one of value as defined by "contactAttrType" in RFC 376 5731 [RFC5731]. 378 2.4.6. Contact_Name 380 The name of the contact object. Usually it is the name of an 381 individual or an organization as described in RFC 5733 [RFC5733] 382 Section 2.3. 384 2.4.7. Linked 386 The value MUST be either "YES" or "NO" to indicate whether the 387 contact object is associated with a domain object. 389 2.4.8. Host_Name 391 The full domain name of the host object as defined in RFC 5732 392 [RFC5732] Section 2.1. The name MUST be in A-label format as defined 393 by RFC5890 [RFC5890]. 395 2.4.9. Host_IP 397 The IP address of the host object. The syntax of the IPv4 address 398 MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address 399 MUST conform to RFC 4291 [RFC4291]. If it contains mutliple IP 400 addresses, each must be separated by symbol comma with the whole 401 string under double quotes as specified in RFC 4180 [RFC4180] 403 2.4.10. Client_Contact_ID 405 The identifier of the contact object assigned by the registrar and 406 MUST conform to "clIDType" specified in RFC 5730 [RFC5730]. 408 3. Report Definition Specification 410 Each report specification conceptually represents a file of comma 411 separated values [RFC4180] (commonly called a CSV file) where the 412 values are selected from the data elements specified above. The 413 first row of the file is a comma separated list of data element names 414 as specified in the data element registry. The remaining rows of the 415 file are the unordered sets of data elements, one set per row, where 416 each row is one record in the report. 418 Each data element in a set conceptually represents the column heading 419 in a report. 421 A consumer MUST be able to receive data elements that are not 422 recognized and MAY skip them accordingly, both in the header row and 423 in the record rows. 425 A report is specified in the report registry with two pieces of 426 information. First is the name of the report. This can be whatever 427 is appropriate as defined by the producer of the report. The name of 428 the report MUST be unique and this characteristic MUST be enforced by 429 registry. 431 Second is the ordered list of data element names of what is included 432 in the report. The data element names MUST be listed in the data 433 element registry specified above. The data element names and the 434 data MUST appear in the report in the order listed in the report 435 registry. 437 The subsections below comprise an initial list of standard reports 438 commonly being used between producers and consumers as of the date of 439 publication of this document. The title of the subsection is the 440 report name. The report name in the IANA registry MUST be unique and 441 MUST be processed as case insensitive. 443 3.1. Domain Transaction 445 Name of report: domain_transaction 447 Description: This report keeps records of actions taken by registrar 448 or the registry system on the domain under registrar's management 449 that changed the domain's status, charge or refund fee to registrar. 451 +==================+========================+ 452 | Data Element | Reference | 453 +==================+========================+ 454 | TLD | RFC XXXX Section 2.1.1 | 455 +------------------+------------------------+ 456 | Server_TRID | Section 2.1.2 | 457 +------------------+------------------------+ 458 | Domain | Section 2.1.3 | 459 +------------------+------------------------+ 460 | Date_Time | Section 2.1.6 | 461 +------------------+------------------------+ 462 | Registrar_ID | Section 2.4.1 | 463 +------------------+------------------------+ 464 | Registrar | Section 2.1.11 | 465 +------------------+------------------------+ 466 | Transaction_Type | Section 2.1.4 | 467 +------------------+------------------------+ 468 | Period_Unit | Section 2.1.12 | 469 +------------------+------------------------+ 470 | Period | Section 2.1.7 | 471 +------------------+------------------------+ 472 | Fee | Section 2.1.8 | 473 +------------------+------------------------+ 474 | Currency | Section 2.1.9 | 475 +------------------+------------------------+ 476 | Description | Section 2.1.13 | 477 +------------------+------------------------+ 479 Table 1: Transaction Report Definition Table 481 3.2. Premium Name 483 Name of report: premium_name 485 Description: This report list the domain and its price that is 486 different, ususally higher, from the regular price 487 +=======================+========================+ 488 | Data Element | Reference | 489 +=======================+========================+ 490 | TLD | RFC XXXX Section 2.1.1 | 491 +-----------------------+------------------------+ 492 | Domain | Section 2.1.3 | 493 +-----------------------+------------------------+ 494 | Status | Section 2.1.10 | 495 +-----------------------+------------------------+ 496 | Description | Section 2.1.13 | 497 +-----------------------+------------------------+ 498 | Currency | Section 2.1.9 | 499 +-----------------------+------------------------+ 500 | Price_Domain_Create | Section 2.2.1 | 501 +-----------------------+------------------------+ 502 | Price_Domain_Renew | Section 2.2.2 | 503 +-----------------------+------------------------+ 504 | Price_Domain_Transfer | Section 2.2.3 | 505 +-----------------------+------------------------+ 506 | Price_Domain_Restore | Section 2.2.4 | 507 +-----------------------+------------------------+ 508 | Available_Date | Section 2.3.1 | 509 +-----------------------+------------------------+ 511 Table 2: Premium Name Report Definition Table 513 3.3. Domain RGP 515 Name of report: domain_rgp 517 Description: This report tracks the domains under registrar's 518 management that are deleted and in the Redemption Grace Period (RGP). 520 +=====================+========================+ 521 | Data Element | Reference | 522 +=====================+========================+ 523 | TLD | RFC XXXX Section 2.1.1 | 524 +---------------------+------------------------+ 525 | Domain | Section 2.1.3 | 526 +---------------------+------------------------+ 527 | Deleted_Date | Section 2.3.2 | 528 +---------------------+------------------------+ 529 | Redemption_End_Date | Section 2.3.3 | 530 +---------------------+------------------------+ 531 | Pending_Delete_Date | Section 2.3.4 | 532 +---------------------+------------------------+ 534 Table 3: Domain RGP Report Definition Table 536 3.4. Reserved Domain 538 Name of report: reserved_domain 540 Description: This report lists name that are reserved by the registry 541 system and the domain's current status. 543 +==============+========================+ 544 | Data Element | Reference | 545 +==============+========================+ 546 | TLD | RFC XXXX Section 2.1.1 | 547 +--------------+------------------------+ 548 | Domain | Section 2.1.3 | 549 +--------------+------------------------+ 550 | Status | Section 2.1.10 | 551 +--------------+------------------------+ 553 Table 4: Reserved Domain Report 554 Definition Table 556 3.5. Domain Inventory 558 Name of report: domain_inventory 560 Description: This report lists all domain currently under the 561 registrar's management and its related attributes. 563 +=================+========================+ 564 | Data Element | Reference | 565 +=================+========================+ 566 | TLD | RFC XXXX Section 2.1.1 | 567 +-----------------+------------------------+ 568 | Domain | Section 2.1.3 | 569 +-----------------+------------------------+ 570 | Updated_Date | Section 2.3.5 | 571 +-----------------+------------------------+ 572 | Registrar_ID | Section 2.4.1 | 573 +-----------------+------------------------+ 574 | Created_Date | Section 2.3.6 | 575 +-----------------+------------------------+ 576 | Expiration_Date | Section 2.3.7 | 577 +-----------------+------------------------+ 578 | Registrant_ID | Section 2.4.2 | 579 +-----------------+------------------------+ 580 | DNSSEC | Section 2.4.3 | 581 +-----------------+------------------------+ 582 | Status | Section 2.1.10 | 583 +-----------------+------------------------+ 585 Table 5: Domain Inventory Report 586 Definition Table 588 3.6. Contact Inventory 590 Name of report: contact_inventory 592 Description: This report lists all contact created by the registrar 593 and any assocations it has to any domains. 595 +===================+================+ 596 | Data Element | Reference | 597 +===================+================+ 598 | Server_Contact_ID | Section 2.4.4 | 599 +-------------------+----------------+ 600 | Client_Contact_ID | Section 2.4.10 | 601 +-------------------+----------------+ 602 | TLD | Section 2.1.1 | 603 +-------------------+----------------+ 604 | Domain | Section 2.1.3 | 605 +-------------------+----------------+ 606 | Contact_Type | Section 2.4.5 | 607 +-------------------+----------------+ 608 | Contact_Name | Section 2.4.6 | 609 +-------------------+----------------+ 610 | Updated_Date | Section 2.3.5 | 611 +-------------------+----------------+ 612 | Linked | Section 2.4.7 | 613 +-------------------+----------------+ 615 Table 6: Contact Inventory Report 616 Definition Table 618 3.7. Host Inventory 620 Name of report: host_inventory 622 Description: This reports list all the host objects and its 623 attributes under registrar's management. 625 +==============+=======================+ 626 | Data Element | Reference | 627 +==============+=======================+ 628 | TLD | RFCXXXX Section 2.1.1 | 629 +--------------+-----------------------+ 630 | Host_Name | Section 2.4.8 | 631 +--------------+-----------------------+ 632 | Host_IP | Section 2.4.9 | 633 +--------------+-----------------------+ 635 Table 7: Host Inventory Report 636 Definition Table 638 4. IANA Considerations 640 This section describes the format of the IANA Registration Report 641 Registry, which has two tables described below, and the procedures 642 used to populate and manage the registry entries. 644 4.1. Report Specification 646 This registry uses the "Specification Required" policy described in 647 RFC 8126 [RFC8126]. An English language version of the extension 648 specification is required in the registry, though non-English 649 versions of the specification may also be provided. 651 The "Specification Required" policy implies review by a "designated 652 expert". Section 5.2 of RFC 8126 [RFC8126] describes the role of 653 designated experts and the function they perform. 655 4.1.1. Designated Expert Evaluation Criteria 657 A high-level description of the role of the designated expert is 658 described in Section 5.2 of RFC 8126 [RFC8126]. Specific guidelines 659 for the appointment of designated experts and the evaluation of a 660 Registration Report is provided here. 662 The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5) 663 to serve as designated experts, as described in Section 5.2 of RFC 664 8126 [RFC8126]. The pool should have a single administrative chair 665 who is appointed by the IESG. The designated experts should use the 666 existing regext mailing list (regext@ietf.org) for public discussion 667 of registration requests. This implies that the mailing list should 668 remain open after the work of the REGEXT working group has concluded. 670 The results of the evaluation should be shared via email with the 671 registrant and the regext mailing list. Issues discovered during the 672 evaluation can be corrected by the registrant, and those corrections 673 can be submitted to the designated experts until the designated 674 experts explicitly decide to accept or reject the registration 675 request. The designated experts must make an explicit decision and 676 that decision must be shared via email with the registrant and the 677 regext mailing list. If the specification for a data element or 678 report is an IETF Standards Track document, no review is required by 679 the designated expert. 681 Designated experts should be permissive in their evaluation of 682 requests for data elements and reports that have been implemented and 683 deployed by at least one registry. This implies that it may indeed 684 be possible to register multiple data elements or reports that 685 provide the same functionality. Requests to register data elements 686 or reports that have not been deployed should be evaluated with a 687 goal of reducing duplication. A potential registrant who submits a 688 request to register a new data element or report that includes 689 similar functionality to existing data elements or reports should be 690 made aware of the existing data elements and reports. The registrant 691 should be asked to reconsider their request given the existence of 692 similar data elements or reports. Should they decline to do so, 693 perceived similarity should not be a sufficient reason for rejection 694 as long as all other requirements are met. 696 4.1.2. Registration Procedure 698 The registry contains information describing each registered data 699 element or report. Registry entries are created and managed by 700 sending forms to IANA that describe the data element or report for 701 the registry entry. 703 4.1.2.1. Required Information 705 The required information must be formatted consistently using the 706 following registration form. Form field names and values may appear 707 on the same line. 709 4.1.2.1.1. Data Element Definition 711 Name of data element 712 MUST be unique within the registry, enforced to be unique, 713 and MUST be processed as case insensitive 715 Reference document 716 MUST define the data element, SHOULD be a URL to a RFC, and 717 SHOULD include the section number (or other detailed internal 718 document reference), MAY be a URL to any document available 719 under equivalent terms 721 Registrant 722 Will be IESG for initial entries and all Standards Track 723 specifications; otherwise as specified by the registran 725 Status 726 MUST be one of active, inactive, or unknown 728 4.1.2.1.2. Report Definition 730 Name of Report 731 MUST be unique within the registry, enforced to be unique, 732 and MUST be processed as case insensitive 734 Document Status 735 MUST be one of active, inactive, or unknown 737 Reference document 738 MUST define the report, SHOULD be a URL to a RFC and SHOULD 739 include the section number (or other detailed internal 740 document reference), MAY be a URL to any document available 741 under equivalent terms 743 Registrant 744 Will be IESG for initial entries and all Standards Track 745 specifications; otherwise as specified by the registrant 747 TLD 748 MUST be "ANY" if the report is intended to be generally 749 applicable or MAY be any top level domain formatted as 750 defined by RFC 5890 [RFC5890] (or comma separated list of 751 domains) and each MUST be an A-LABEL if the report is 752 intended to have that scope 754 Status:active 756 4.1.2.2. Registration Processing 758 Registrants should send each registration form to IANA with a single 759 record for incorporation into the registry. Send the form via email 760 to iana@iana.org or complete the online form found on the IANA web 761 site. The subject line should indicate whether the enclosed form 762 represents an insertion of a new record (indicated by the word 763 "INSERT" in the subject line) or a replacement of an existing record 764 (indicated by the word "MODIFY" in the subject line). At no time can 765 a record be deleted from the registry. On receipt of the 766 registration request, IANA will initiate review by the designated 767 expert(s) if appropriate, who will evaluate the request using the 768 criteria in Section 4.1.1 in consultation with the regext mailing 769 list. 771 4.1.2.3. Updating Report Definition Registry Entries 773 When submitting changes to existing registry entries, include text in 774 the "Notes" field of the registration form describing the change. 775 Under normal circumstances, registry entries are only to be updated 776 by the registrant. If the registrant becomes unavailable or 777 otherwise unresponsive, the designated expert can submit a 778 registration form to IANA to update the registrant information. 779 Entries can change state from "Active" to "Inactive" and back again 780 as long as state-change requests conform to the processing 781 requirements identified in this document. In addition to entries 782 that become "Inactive" due to a lack of implementation, entries for 783 which a specification becomes consistently unavailable over time 784 should be marked "Inactive" by the designated expert until the 785 specification again becomes reliably available. 787 4.2. Initial assignments 789 4.2.1. Data Element Definition in IANA Registry 791 ---- BEGIN FORM ---- 793 Name of data element: 794 TLD 796 Reference: 797 This RFC Section 2.1.1 799 Registrant: 800 IESG, iesg@ietf.org 802 Status: 803 Active 805 ---- END FORM ---- 807 ---- BEGIN FORM ---- 809 Name of data element: 810 Server_TRID 812 Reference: 813 This RFC Section 2.1.2 815 Registrant: 816 IESG, iesg@ietf.org 818 Status: 819 Active 821 ---- END FORM ---- 823 ---- BEGIN FORM ---- 825 Name of data element: 826 Domain 828 Reference: 829 This RFC Section 2.1.3 831 Registrant: 832 IESG, iesg@ietf.org 834 Status: 835 Active 837 ---- END FORM ---- 839 ---- BEGIN FORM ---- 841 Name of data element: 842 Transaction_Type 844 Reference: 845 This RFC Section 2.1.4 847 Registrant: 848 IESG, iesg@ietf.org 850 Status: 851 Active 853 ---- END FORM ---- 855 ---- BEGIN FORM ---- 857 Name of data element: 858 Ojbect_Type 860 Reference: 861 This RFC Section 2.1.5 863 Registrant: 864 IESG, iesg@ietf.org 866 Status: 867 Active 869 ---- END FORM ---- 871 ---- BEGIN FORM ---- 873 Name of data element: 874 Date_Time 876 Reference: 877 This RFC Section 2.1.6 879 Registrant: 880 IESG, iesg@ietf.org 882 Status: 883 Active 885 ---- END FORM ---- 887 ---- BEGIN FORM ---- 889 Name of data element: 890 Period 892 Reference: 893 This RFC Section 2.1.7 895 Registrant: 896 IESG, iesg@ietf.org 898 Status: 899 Active 901 ---- END FORM ---- 903 ---- BEGIN FORM ---- 905 Name of data element: 906 Currency 908 Reference: 909 This RFC Section 2.1.9 911 Registrant: 912 IESG, iesg@ietf.org 914 Status: 915 Active 917 ---- END FORM ---- 919 ---- BEGIN FORM ---- 921 Name of data element: 922 Status 924 Reference: 925 This RFC Section 2.1.10 927 Registrant: 928 IESG, iesg@ietf.org 930 Status: 931 Active 933 ---- END FORM ---- 935 ---- BEGIN FORM ---- 937 Name of data element: 938 Registrar 940 Reference: 941 This RFC Section 2.1.11 943 Registrant: 944 IESG, iesg@ietf.org 946 Status: 947 Active 949 ---- END FORM ---- 951 ---- BEGIN FORM ---- 953 Name of data element: 954 Period_Unit 956 Reference: 957 This RFC Section 2.1.12 959 Registrant: 960 IESG, iesg@ietf.org 962 Status: 963 Active 965 ---- END FORM ---- 967 ---- BEGIN FORM ---- 969 Name of data element: 970 Description 972 Reference: 973 This RFC Section 2.1.13 975 Registrant: 976 IESG, iesg@ietf.org 978 Status: 979 Active 981 ---- END FORM ---- 983 ---- BEGIN FORM ---- 985 Name of data element: 986 Price_Domain_Create 988 Reference: 989 This RFC Section 2.2.1 991 Registrant: 992 IESG, iesg@ietf.org 994 Status: 995 Active 997 ---- END FORM ---- 999 ---- BEGIN FORM ---- 1001 Name of data element: 1002 Price_Domain_Renew 1004 Reference: 1005 This RFC Section 2.2.2 1007 Registrant: 1008 IESG, iesg@ietf.org 1010 Status: 1011 Active 1013 ---- END FORM ---- 1015 ---- BEGIN FORM ---- 1017 Name of data element: 1018 Price_Domain_Transfer 1020 Reference: 1021 This RFC Section 2.2.3 1023 Registrant: 1024 IESG, iesg@ietf.org 1026 Status: 1027 Active 1029 ---- END FORM ---- 1031 ---- BEGIN FORM ---- 1033 Name of data element: 1034 Price_Domain_Restore 1036 Reference: 1037 This RFC Section 2.2.4 1039 Registrant: 1040 IESG, iesg@ietf.org 1042 Status: 1043 Active 1045 ---- END FORM ---- 1047 ---- BEGIN FORM ---- 1049 Name of data element: 1050 Available_Date 1052 Reference: 1053 This RFC Section 2.3.1 1055 Registrant: 1056 IESG, iesg@ietf.org 1058 Status: 1059 Active 1061 ---- END FORM ---- 1063 ---- BEGIN FORM ---- 1065 Name of data element: 1066 Deleted_Date 1068 Reference: 1069 This RFC Section 2.3.2 1071 Registrant: 1072 IESG, iesg@ietf.org 1074 Status: 1075 Active 1077 ---- END FORM ---- 1079 ---- BEGIN FORM ---- 1081 Name of data element: 1082 Redemption_End_Date 1084 Reference: 1085 This RFC Section 2.3.3 1087 Registrant: 1088 IESG, iesg@ietf.org 1090 Status: 1091 Active 1093 ---- END FORM ---- 1095 ---- BEGIN FORM ---- 1097 Name of data element: 1098 Pending_Delete_Date 1100 Reference: 1101 This RFC Section 2.3.4 1103 Registrant: 1104 IESG, iesg@ietf.org 1106 Status: 1107 Active 1109 ---- END FORM ---- 1111 ---- BEGIN FORM ---- 1113 Name of data element: 1114 Updated_Date 1116 Reference: 1117 This RFC Section 2.3.5 1119 Registrant: 1120 IESG, iesg@ietf.org 1122 Status: 1123 Active 1125 ---- END FORM ---- 1127 ---- BEGIN FORM ---- 1129 Name of data element: 1130 Created_Date 1132 Reference: 1133 This RFC Section 2.3.6 1135 Registrant: 1136 IESG, iesg@ietf.org 1138 Status: 1139 Active 1141 ---- END FORM ---- 1143 ---- BEGIN FORM ---- 1145 Name of data element: 1146 Expiration_Date 1148 Reference: 1149 This RFC Section 2.3.7 1151 Registrant: 1152 IESG, iesg@ietf.org 1154 Status: 1155 Active 1157 ---- END FORM ---- 1159 ---- BEGIN FORM ---- 1161 Name of data element: 1162 Registrar_ID 1164 Reference: 1165 This RFC Section 2.4.1 1167 Registrant: 1168 IESG, iesg@ietf.org 1170 Status: 1171 Active 1173 ---- END FORM ---- 1175 ---- BEGIN FORM ---- 1177 Name of data element: 1178 Registrant_ID 1180 Reference: 1181 This RFC Section 2.4.2 1183 Registrant: 1184 IESG, iesg@ietf.org 1186 Status: 1187 Active 1189 ---- END FORM ---- 1191 ---- BEGIN FORM ---- 1193 Name of data element: 1194 DNSSEC 1196 Reference: 1197 This RFC Section 2.4.3 1199 Registrant: 1200 IESG, iesg@ietf.org 1202 Status: 1203 Active 1205 ---- END FORM ---- 1207 ---- BEGIN FORM ---- 1209 Name of data element: 1210 Server_Contact_ID 1212 Reference: 1213 This RFC Section 2.4.4 1215 Registrant: 1216 IESG, iesg@ietf.org 1218 Status: 1219 Active 1221 ---- END FORM ---- 1223 ---- BEGIN FORM ---- 1225 Name of data element: 1226 Contact_Type 1228 Reference: 1229 This RFC Section 2.4.5 1231 Registrant: 1232 IESG, iesg@ietf.org 1234 Status: 1235 Active 1237 ---- END FORM ---- 1239 ---- BEGIN FORM ---- 1241 Name of data element: 1242 Contact_Name 1244 Reference: 1245 This RFC Section 2.4.6 1247 Registrant: 1248 IESG, iesg@ietf.org 1250 Status: 1251 Active 1253 ---- END FORM ---- 1255 ---- BEGIN FORM ---- 1257 Name of data element: 1258 Linked 1260 Reference: 1261 This RFC Section 2.4.7 1263 Registrant: 1264 IESG, iesg@ietf.org 1266 Status: 1267 Active 1269 ---- END FORM ---- 1271 ---- BEGIN FORM ---- 1273 Name of data element: 1274 Host_Name 1276 Reference: 1277 This RFC Section 2.4.8 1279 Registrant: 1280 IESG, iesg@ietf.org 1282 Status: 1283 Active 1285 ---- END FORM ---- 1287 ---- BEGIN FORM ---- 1289 Name of data element: 1290 Host_IP 1292 Reference: 1293 This RFC Section 2.4.9 1295 Registrant: 1296 IESG, iesg@ietf.org 1298 Status: 1299 Active 1301 ---- END FORM ---- 1303 ---- BEGIN FORM ---- 1305 Name of data element: 1306 Client_Contact_ID 1308 Reference: 1309 This RFC Section 2.4.10 1311 Registrant: 1312 IESG, iesg@ietf.org 1314 Status: 1315 Active 1317 ---- END FORM ---- 1319 4.2.2. Report Definition in IANA Registry 1321 ---- BEGIN FORM ---- 1323 Name of report: 1324 domain_transaction 1326 Reference: 1327 This RFC Table 1 1329 Registrant: 1330 IESG, iesg@ietf.org 1332 TLD: 1333 any 1335 Status: 1336 Active 1338 ---- END FORM ---- 1340 ---- BEGIN FORM ---- 1342 Name of report: 1343 premium_name 1345 Reference: 1346 This RFC Section 3.2 1348 Registrant: 1349 IESG, iesg@ietf.org 1351 TLD: 1352 any 1354 Status: 1355 Active 1357 ---- END FORM ---- 1359 ---- BEGIN FORM ---- 1360 Name of report: 1361 domain_rgp 1363 Reference: 1364 This RFC Section 3.3 1366 Registrant: 1367 IESG, iesg@ietf.org 1369 TLD: 1370 any 1372 Status: 1373 Active 1375 ---- END FORM ---- 1377 ---- BEGIN FORM ---- 1379 Name of report: 1380 reserved_domain 1382 Reference: 1383 This RFC Section 3.4 1385 Registrant: 1386 IESG, iesg@ietf.org 1388 TLD: 1389 any 1391 Status: 1392 Active 1394 ---- END FORM ---- 1396 ---- BEGIN FORM ---- 1398 Name of report: 1399 domain_inventory 1401 Reference: 1402 This RFC Section 3.5 1404 Registrant: 1405 IESG, iesg@ietf.org 1407 TLD: 1408 any 1410 Status: 1411 Active 1413 ---- END FORM ---- 1415 ---- BEGIN FORM ---- 1417 Name of report: 1418 contact_inventory 1420 Reference: 1421 This RFC Section 3.6 1423 Registrant: 1424 IESG, iesg@ietf.org 1426 TLD: 1427 any 1429 Status: 1430 Active 1432 ---- END FORM ---- 1434 ---- BEGIN FORM ---- 1436 Name of report: 1437 host_inventory 1439 Reference: 1440 This RFC Section 3.7 1442 Registrant: 1443 IESG, iesg@ietf.org 1445 TLD: 1446 any 1448 Status: 1449 Active 1451 ---- END FORM ---- 1453 5. Security Considerations 1455 This specification does not consider the issues of distribution or 1456 access to the reports that are created and thus does not introduce 1457 any new security security concerns that are not already present in 1458 the local environment in which the report is created. 1460 A security principle to keep in mind as new reports are developed is 1461 that it is considered a bad practice to report or disclose security 1462 information. In the case of the registration system upon which this 1463 reporting mechanism is based, the authInfo code is a specific example 1464 of a data element that SHOULD NOT be included in a report. 1466 6. Privacy Considerations 1468 This specification defines a mechanism for creating reports based on 1469 data in a registration system. Some of that data is likely to be 1470 considered personally identifiable information (PII) and thus would 1471 be subject to privacy protection according to an applicable privacy 1472 regulation. It is outside the scope of this specification to address 1473 those specific concerns. Implementors are urged to consider these 1474 issues with their local legal authority and develop appropriate 1475 requirements for their work. 1477 As expressly noted in the Introduction, distribution of and access to 1478 the reports created by this specification is expressly outside the 1479 scope of this specification. However, to the extent a report 1480 contains PII, implementors are urged to consider these issues with 1481 their local legal authority and develop appropriate requirements for 1482 their work. 1484 7. Internationalization Considerations 1486 The character encoding for the file contents MUST use UTF-8. 1488 Throughout this document A-LABEL is indicated as a SHOULD and that 1489 MUST be interpreted as follows. All domain name labels MUST be in 1490 A-LABEL format if it is possible to represent it as an A-LABEL, 1491 otherwise U-LABEL MAY be used. 1493 8. References 1495 8.1. Normative References 1497 [ISO4217] International Organization for Standardization, "ISO 4217 1498 Currency Codes", 2018, . 1501 [RFC0791] Postel, J., "Internet Protocol", September 1981, 1502 . 1504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1505 Requirement Levels", BCP 14, RFC 2119, 1506 DOI 10.17487/RFC2119, March 1997, 1507 . 1509 [RFC4180] Shafranovich, Y., "IP Version 6 Addressing Architecture", 1510 February 2006, . 1512 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1513 Architecture", February 2006, 1514 . 1516 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1517 August 2009, . 1519 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1520 Domain Name Mapping", August 2009, 1521 . 1523 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1524 Host Mapping", August 2009, 1525 . 1527 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1528 Contact Mapping", August 2009, 1529 . 1531 [RFC5890] Klensin, J., "Extensible Provisioning Protocol (EPP) 1532 Contact Mapping", August 2009, 1533 . 1535 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1536 Writing an IANA Considerations Section in RFCs", June 1537 2017, . 1539 [RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the 1540 Extensible Provisioning Protocol", March 2021, 1541 . 1543 8.2. Informative References 1545 [IANA_Registrar_IDs] 1546 Internet Assigned Numbers Authority, "IANA Assignments - 1547 Registrar IDs", 2020, . 1550 Appendix A. Acknowledgements 1552 The authors would like to thank Roger Carney, Jody Kolker, Tobias 1553 Sattler, and bestpractice.domains for their reviews and suggestions. 1555 Appendix B. File Naming Convention 1557 TBD on file naming convention suggestion 1559 Authors' Addresses 1561 Joseph Yee (editor) 1562 Donuts 1563 Toronto 1564 Canada 1565 Email: jyee@afilias.info 1567 James Galvin 1568 Donuts 1569 Horsham, PA 1570 United States 1571 Email: jgalvin@donuts.email