idnits 2.17.1 draft-ietf-regext-simple-registration-reporting-01.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 (13 July 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Note' is mentioned on line 411, but not defined == Unused Reference: 'ISO4217' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 698, 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 (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J.Y,. Yee, Ed. 3 Internet-Draft J.G,. Galvin 4 Intended status: Informational Afilias 5 Expires: 14 January 2021 13 July 2020 7 Simple Registration Reporting 8 draft-ietf-regext-simple-registration-reporting-01 10 Abstract 12 Domain name registries and registrars report to each other by sharing 13 bulk information through files. This document creates two IANA 14 registries to create a standard reporting mechanism between domain 15 name registries and registrars. The first IANA registry lists 16 standard data elements and their syntax for inclusion in the files. 17 The second IANA registry lists standard reports based on the standard 18 data elements. Each report is a file formatted as a CSV file. The 19 advantage of this reporting mechanism is that reports, each file, can 20 be imported by recipients without any prior knowledge of their 21 contents, although reporting is enhanced with a minimum of knowledge 22 about the files. The mechanism for the transmission and reception of 23 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 14 January 2021. 42 Copyright Notice 44 Copyright (c) 2020 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 Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified 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 Fields . . . . . . . . . . . . . . . 4 62 2.1.1. TLD . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.2. Server_TRID . . . . . . . . . . . . . . . . . . . . . 4 64 2.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1.4. Transaction_Type . . . . . . . . . . . . . . . . . . 5 66 2.1.5. Ojbect_Type . . . . . . . . . . . . . . . . . . . . . 5 67 2.1.6. DateTime . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.7. Term . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1.8. Fee . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1.9. Currency . . . . . . . . . . . . . . . . . . . . . . 5 71 2.1.10. Status . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1.11. Registrar . . . . . . . . . . . . . . . . . . . . . . 6 73 2.1.12. Period . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1.13. Description . . . . . . . . . . . . . . . . . . . . . 6 75 2.2. Domain Price Fields . . . . . . . . . . . . . . . . . . . 6 76 2.2.1. Domain_Create . . . . . . . . . . . . . . . . . . . . 6 77 2.2.2. Domain_Renew . . . . . . . . . . . . . . . . . . . . 6 78 2.2.3. Domain_Transfer . . . . . . . . . . . . . . . . . . . 6 79 2.2.4. Domain_Restore . . . . . . . . . . . . . . . . . . . 6 80 2.3. Timestamp Fields . . . . . . . . . . . . . . . . . . . . 6 81 2.3.1. Start_Date . . . . . . . . . . . . . . . . . . . . . 6 82 2.3.2. Deleted_Date . . . . . . . . . . . . . . . . . . . . 7 83 2.3.3. RGP_Date . . . . . . . . . . . . . . . . . . . . . . 7 84 2.3.4. Purge_Date . . . . . . . . . . . . . . . . . . . . . 7 85 2.3.5. Updated_Date . . . . . . . . . . . . . . . . . . . . 7 86 2.3.6. Create_Date . . . . . . . . . . . . . . . . . . . . . 7 87 2.3.7. Expiry_Date . . . . . . . . . . . . . . . . . . . . . 7 88 2.4. Registration Information Fields . . . . . . . . . . . . . 7 89 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 7 90 2.4.2. Server_Registrant_ID . . . . . . . . . . . . . . . . 8 91 2.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8 92 2.4.4. Server_Contact_ID . . . . . . . . . . . . . . . . . . 8 93 2.4.5. Contact_Type . . . . . . . . . . . . . . . . . . . . 8 94 2.4.6. Contact_Name . . . . . . . . . . . . . . . . . . . . 8 95 2.4.7. INUSE . . . . . . . . . . . . . . . . . . . . . . . . 8 96 2.4.8. Nameserver_Host . . . . . . . . . . . . . . . . . . . 8 97 2.4.9. Nameserver_IP . . . . . . . . . . . . . . . . . . . . 8 98 2.4.10. Client_Contact_ID . . . . . . . . . . . . . . . . . . 8 99 3. Report Definition Specification . . . . . . . . . . . . . . . 9 100 3.1. Transaction Report . . . . . . . . . . . . . . . . . . . 9 101 3.2. Premium Name Report . . . . . . . . . . . . . . . . . . . 10 102 3.3. Domain RGP Report . . . . . . . . . . . . . . . . . . . . 11 103 3.4. Reserved Domain Report . . . . . . . . . . . . . . . . . 11 104 3.5. Domain Inventory Report . . . . . . . . . . . . . . . . . 12 105 3.6. Contact Inventory Report . . . . . . . . . . . . . . . . 12 106 3.7. Host Inventory Report . . . . . . . . . . . . . . . . . . 13 107 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 108 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 109 5.1. Field Definition . . . . . . . . . . . . . . . . . . . . 13 110 5.2. Report Definition . . . . . . . . . . . . . . . . . . . . 14 111 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 112 7. Internationalization Considerations . . . . . . . . . . . . . 14 113 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 114 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 115 8.2. Informative References . . . . . . . . . . . . . . . . . 15 116 Appendix A. File Naming Convention . . . . . . . . . . . . . . . 16 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 119 1. Introduction 121 Currently, domain name registry operators (the producer) create and 122 set their own domain name registration reports for use by their 123 registrars (the consumer). Among the distinctions that vary by 124 producers is the syntax of the data provided, e.g., date formats, and 125 the format of the collection of the data provided, e.g., the report 126 may be a CSV file that tends to allow for straightforward importation 127 or a PDF file that can be problematic to import. In addition, 128 although there are a number of best practice reports that have 129 evolved, these are not currently documented as such, which results in 130 a fair amount of customization on the part of the consumers to import 131 data. 133 This document standardizes the name and syntax of the data elements 134 to be used across all existing domain name registration reports and 135 creates an IANA registry of them to facilitate their evolution, 136 including adding additional data elements as needed. In addition, a 137 known set of existing standard reports using the aforementioned data 138 elements is specified in another IANA registry to facilitate the 139 evolution of the reports and adding additional report definitions as 140 needed. 142 Each report definition MUST use the data elements defined here, 143 including all future reports. Future reports and future data 144 elements may be specified in their own individual documents, updating 145 the IANA registries as needed. 147 1.1. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC 2119 [RFC2119]. 153 2. Data Element Specification 155 Data elements are grouped into categories for convenience. There is 156 no other significance to the groupings. 158 Each data element conceptually represents the column heading in a 159 printed report. It is a single unit of information that can be 160 passed from the producer to the consumer. The primary purposes of 161 the IANA registry of data elements are to ensure that each data 162 element is assigned a unique name and that the syntax of each data 163 element is specified. 165 The name of the data element MUST be unique and this characteristic 166 MUST be enforced by registry. The name is used in the report 167 definition (in the next section) to alert the consumer as to what to 168 expect in the file and how to import the data element. 170 The subsections below comprise an initial list of known data elements 171 commonly being used between producers and consumers as of the date of 172 publication of this document. The title of the subsection is the 173 field name for the data element. 175 2.1. General Information Fields 177 2.1.1. TLD 179 The string of the top level domain involved that SHOULD be in A-LABEL 180 format as defined by RFC 5890 [RFC5890]. 182 2.1.2. Server_TRID 184 The transaction identifier issued by EPP Server. The format MUST 185 conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. 187 2.1.3. Domain 189 This is the domain name in EPP RFC 5731 [RFC5731] domain object and 190 it SHOULD be in A-Label format. 192 2.1.4. Transaction_Type 194 The type of transform action made to the domain object (CREATE, 195 DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730] 196 Section 2.9.3 198 2.1.5. Ojbect_Type 200 The object type involved in the report. In the EPP environment, an 201 object could be domain RFC 5731 [RFC5731], contact RFC 5733 202 [RFC5733], or host RFC 5732 [RFC5732]. 204 2.1.6. DateTime 206 The timestamp of the transaction recorded in the system. The date 207 and time format follows the "type=dateTime" specification as defined 208 in RFC 5731 [RFC5731]. 210 2.1.7. Term 212 The number of unit added to the domain registration period in 213 "domain:period" RFC 5731 [RFC5731] in create command or renew 214 command. If there's no "domain:period", it should take the default 215 value set by the registry. 217 2.1.8. Fee 219 The amount of money charged or returned (shown as negative value) to 220 the registrar. The numeric format MUST conform to the currency 221 specified below in Section 2.1.9. The format must conform to 222 "balanceType" as defined in RFC 8748 [RFC8748] 224 2.1.9. Currency 226 The currency used in the money charged as documented above in 227 Section 2.1.18. It is recommended for currency code to follow ISO 228 4217 [ISO4217]standard. 230 2.1.10. Status 232 The status of domain object. It MUST be one of the values specified 233 in RFC 5731 [RFC5731] Section 2.3. 235 2.1.11. Registrar 237 The name of the registrar. This field is text/string with no naming 238 convention enforced. 240 2.1.12. Period 242 The type of time (year, month) in 'Term' described above in 243 Section 2.1.7 245 2.1.13. Description 247 Additional information regarding the current entry in the report. It 248 is provided by the producer and its actual value is a matter of local 249 policy. 251 2.2. Domain Price Fields 253 2.2.1. Domain_Create 255 The fee charged to create the domain. The format must conform to 256 "balanceType" as defined in [draft-ietf-regext-epp-fees] 258 2.2.2. Domain_Renew 260 The fee charged to renew the domain. The format must conform to 261 "balanceType" as defined in [draft-ietf-regext-epp-fees] 263 2.2.3. Domain_Transfer 265 The fee charged to transfer the domain. The format must conform to 266 "balanceType" as defined in [draft-ietf-regext-epp-fees] 268 2.2.4. Domain_Restore 270 The fee charged to restore the domain. The format must conform to 271 "balanceType" as defined in [draft-ietf-regext-epp-fees] 273 2.3. Timestamp Fields 275 2.3.1. Start_Date 277 The timestamp of when the domain object becomes available. The date 278 and time format follows the "type=dateTime" specification as defined 279 in RFC 5731 [RFC5731]. 281 2.3.2. Deleted_Date 283 The timestamp of when the domain was deleted by the end user. The 284 date and time format follows the "type=dateTime" specification as 285 defined in RFC 5731 [RFC5731]. 287 2.3.3. RGP_Date 289 The timestamp of when the domain will complete its redemption grace 290 period. In BestPractice.domains, this is referred to as 'expired'. 291 The date and time format follows the "type=dateTime" specification as 292 defined in RFC 5731 [RFC5731]. 294 2.3.4. Purge_Date 296 The timestamp of when the domain will be purged and become available 297 again. In BestPractice.domains, this is referred to as 'purged'. 298 The date and time format follows the "type=dateTime" specification as 299 defined in RFC 5731 [RFC5731]. 301 2.3.5. Updated_Date 303 The timestamp of the last time the domain object was updated. In 304 BestPractice.domains, this is referred to as 'Updated'. The date and 305 time format follows the "type=dateTime" specification as defined in 306 RFC 5731 [RFC5731]. 308 2.3.6. Create_Date 310 The timestamp of the domain object was allocated. The date and time 311 format follows the "type=dateTime" specification as defined in RFC 312 5731 [RFC5731]. 314 2.3.7. Expiry_Date 316 The timestamp of the domain object will expire. The date and time 317 format follows the "type=dateTime" specification as defined in RFC 318 5731 [RFC5731]. 320 2.4. Registration Information Fields 322 2.4.1. Registrar_ID 324 The identifier assigned to the registrar. If the registrar is 325 accredited under ICANN, it MUST be the registrar's IANA ID 326 [IANA_Registrar_IDs]. Otherwise it is a value known between the 327 producer and the consumer. 329 2.4.2. Server_Registrant_ID 331 The identifier assigned to the contact object that is associated as 332 registrant of the domain name that MUST conform to "clIDType" 333 specified in RFC 5730 [RFC5730]. 335 2.4.3. DNSSEC 337 The value MUST be either 'YES' or 'NO' to indicate whether the domain 338 is DNSSEC signed. 340 2.4.4. Server_Contact_ID 342 The identifier of the contact object assigned by registry system. 344 2.4.5. Contact_Type 346 The value MUST be one of value as defined by "contactAttrType" in RFC 347 5731 [RFC5731]. 349 2.4.6. Contact_Name 351 The name of the contact object. Usually it is the name of an 352 individual or an organization as described in RFC 5733 [RFC5733] 353 Section 2.3 355 2.4.7. INUSE 357 MUST be either "YES" or "NO" to indicate whether the contact object 358 is associated with a domain object. 360 2.4.8. Nameserver_Host 362 The full domain name of the host object. The name MUST be in A-Label 363 format. 365 2.4.9. Nameserver_IP 367 The IP address of the host object. The syntax of the IPv4 address 368 MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address 369 MUST conform to RFC 4291 [RFC4291]. 371 2.4.10. Client_Contact_ID 373 The identifier of the contact object assigned by registrar. 375 3. Report Definition Specification 377 Each report specification conceptually represents a file of comma 378 separated values [RFC4180] (commonly called a CSV file) where the 379 values are selected from the data elements specified above. The 380 first row of the file is a comma separated list of field names as 381 specified in the data element registry. The remaining rows of the 382 file are the unordered sets of data elements, one set per row, where 383 each row is one transaction in the report. 385 Each data element conceptually represents the column heading in a 386 printed report. The first row represents the column headings and 387 each succeeding row represents a transaction of the report. 389 A consumer MUST be able to receive data elements that are not 390 recognized and MAY skip them accordingly, both in the header row and 391 in the transaction rows. 393 A report is specified in the report registry with two pieces of 394 information. First is the name of the report. This can be whatever 395 is appropriate as defined by the producer of the report. The name of 396 the report MUST be unique and this characteristic MUST be enforced by 397 registry. 399 Second is the ordered list of field names of what is included in the 400 report. The field names MUST be listed in the data element registry 401 specified above. The field names and the data MUST appear in the 402 report in the order listed in the report registry. 404 The subsections below comprise an initial list of standard reports 405 commonly being used between producers and consumers as of the data of 406 publication of this document. The title of the subsection is the 407 report name. 409 3.1. Transaction Report 411 [Note] There is a new column in this report that is not added to 412 other reports. There are discussions on whether to define if each 413 field is mandatory. The column was added to this report only for 414 visualation and to further discussion. This paragraph will be 415 removed once working group discussed and reached consensus on 416 direction. 418 +==================+========================+===========+ 419 | Field | Reference | Mandatory | 420 +==================+========================+===========+ 421 | TLD | RFC XXXX Section 2.1.1 | N | 422 +------------------+------------------------+-----------+ 423 | Server_TRID | Section 2.1.2 | Y | 424 +------------------+------------------------+-----------+ 425 | Domain | Section 2.1.3 | Y | 426 +------------------+------------------------+-----------+ 427 | DateTime | Section 2.1.6 | Y | 428 +------------------+------------------------+-----------+ 429 | Registrar_ID | Section 2.4.1 | Y | 430 +------------------+------------------------+-----------+ 431 | Registrar | Section 2.1.11 | Y | 432 +------------------+------------------------+-----------+ 433 | Transaction_Type | Section 2.1.4 | Y | 434 +------------------+------------------------+-----------+ 435 | Period | Section 2.1.12 | Y | 436 +------------------+------------------------+-----------+ 437 | Term | Section 2.1.7 | N | 438 +------------------+------------------------+-----------+ 439 | Fee | Section 2.1.8 | Y | 440 +------------------+------------------------+-----------+ 441 | Currency | Section 2.1.9 | Y | 442 +------------------+------------------------+-----------+ 443 | Description | Section 2.1.13 | N | 444 +------------------+------------------------+-----------+ 446 Table 1: Transaction Report Definition Table 448 3.2. Premium Name Report 450 +=================+========================+ 451 | Field | Reference | 452 +=================+========================+ 453 | TLD | RFC XXXX Section 2.1.1 | 454 +-----------------+------------------------+ 455 | Domain | Section 2.1.3 | 456 +-----------------+------------------------+ 457 | Status | Section 2.1.10 | 458 +-----------------+------------------------+ 459 | Description | Section 2.1.13 | 460 +-----------------+------------------------+ 461 | Currency | Section 2.1.9 | 462 +-----------------+------------------------+ 463 | Domain_Create | Section 2.2.1 | 464 +-----------------+------------------------+ 465 | Domain_Renew | Section 2.2.2 | 466 +-----------------+------------------------+ 467 | Domain_Transfer | Section 2.2.3 | 468 +-----------------+------------------------+ 469 | Domain_Restore | Section 2.2.4 | 470 +-----------------+------------------------+ 471 | Start_Date | Section 2.3.1 | 472 +-----------------+------------------------+ 474 Table 2: Premium Name Report Definition 475 Table 477 3.3. Domain RGP Report 479 +==============+========================+ 480 | Field | Reference | 481 +==============+========================+ 482 | TLD | RFC XXXX Section 2.1.1 | 483 +--------------+------------------------+ 484 | Domain | Section 2.1.3 | 485 +--------------+------------------------+ 486 | Deleted_Date | Section 2.3.2 | 487 +--------------+------------------------+ 488 | RGP_Date | Section 2.3.3 | 489 +--------------+------------------------+ 490 | Purge_Date | Section 2.3.4 | 491 +--------------+------------------------+ 493 Table 3: Domain RGP Report Definition 494 Table 496 3.4. Reserved Domain Report 498 +========+========================+ 499 | Field | Reference | 500 +========+========================+ 501 | TLD | RFC XXXX Section 2.1.1 | 502 +--------+------------------------+ 503 | Domain | Section 2.1.3 | 504 +--------+------------------------+ 505 | Status | Section 2.1.10 | 506 +--------+------------------------+ 508 Table 4: Reserved Domain Report 509 Definition Table 511 3.5. Domain Inventory Report 513 +======================+========================+ 514 | Field | Reference | 515 +======================+========================+ 516 | TLD | RFC XXXX Section 2.1.1 | 517 +----------------------+------------------------+ 518 | Domain | Section 2.1.3 | 519 +----------------------+------------------------+ 520 | Updated_Date | Section 2.3.5 | 521 +----------------------+------------------------+ 522 | Registrar_ID | Section 2.4.1 | 523 +----------------------+------------------------+ 524 | Create_Date | Section 2.3.6 | 525 +----------------------+------------------------+ 526 | Expiry_Date | Section 2.3.7 | 527 +----------------------+------------------------+ 528 | Server_Registrant_ID | Section 2.4.2 | 529 +----------------------+------------------------+ 530 | DNSSEC | Section 2.4.3 | 531 +----------------------+------------------------+ 532 | Status | Section 2.1.10 | 533 +----------------------+------------------------+ 535 Table 5: Domain Inventory Report Definition Table 537 3.6. Contact Inventory Report 539 +===================+================+ 540 | Field | Reference | 541 +===================+================+ 542 | Server_Contact_ID | Section 2.4.4 | 543 +-------------------+----------------+ 544 | Client_Contact_ID | Section 2.4.10 | 545 +-------------------+----------------+ 546 | TLD | Section 2.1.1 | 547 +-------------------+----------------+ 548 | Domain | Section 2.1.3 | 549 +-------------------+----------------+ 550 | Contact_Type | Section 2.4.5 | 551 +-------------------+----------------+ 552 | Contact_Name | Section 2.4.6 | 553 +-------------------+----------------+ 554 | Updated_Date | Section 2.3.5 | 555 +-------------------+----------------+ 556 | INUSE | Section 2.4.7 | 557 +-------------------+----------------+ 558 | Registrar_ID | Section 2.4.1 | 559 +-------------------+----------------+ 561 Table 6: Contact Inventory Report 562 Definition Table 564 3.7. Host Inventory Report 566 +=================+=======================+ 567 | Field | Reference | 568 +=================+=======================+ 569 | TLD | RFCXXXX Section 2.1.1 | 570 +-----------------+-----------------------+ 571 | Nameserver_Host | Section 2.4.8 | 572 +-----------------+-----------------------+ 573 | Nameserver_IP | Section 2.4.9 | 574 +-----------------+-----------------------+ 576 Table 7: Host Inventory Report 577 Definition Table 579 4. Acknowledgements 581 The authors would like to thank Roger Carney, Jody Kolker for their 582 reviews and suggestions 584 5. IANA Considerations 586 This document asks IANA to create two new registries. Each registry 587 is a first-come first-served registry. 589 DETAILS TO BE SPECIFIED AS THE DOCUMENT EVOLVES. 591 5.1. Field Definition 593 The field name must be unique and case insensitive. 595 PROPOSED FIELD NAME TABLE ENTRY. DETAILS TO BE SPECIFIED AS THE 596 DOCUMENT EVOLVES. 598 Name of field 599 Enforced to be case-insensitive (if appropriate) unique 601 Reference document defining the field, including section number 602 Should be an RFC in many cases 604 Registrant 605 Will be IESG for initial entries 607 Status 608 MUST be active, inactive, unknown 610 5.2. Report Definition 612 The report name must be unique and case insensitive. that any future 613 submission must not have the same case insensitive match with prior 614 entry. 616 Name of report 618 Document Status 620 Reference (including section number) 622 Registrant: IESG 624 TLD: any 626 Status: active 628 6. Security Considerations 630 TBD 632 7. Internationalization Considerations 634 The character encoding for the file contents MUST use UTF-8. 636 8. References 638 8.1. Normative References 640 [RFC0791] Postel, J., "Internet Protocol", September 1981, 641 . 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC4180] Shafranovich, Y., "IP Version 6 Addressing Architecture", 649 February 2006, . 651 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 652 Architecture", February 2006, 653 . 655 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 656 August 2009, . 658 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 659 Domain Name Mapping", August 2009, 660 . 662 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 663 Host Mapping", August 2009, 664 . 666 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 667 Contact Mapping", August 2009, 668 . 670 [RFC5890] Klensin, J., "Extensible Provisioning Protocol (EPP) 671 Contact Mapping", August 2009, 672 . 674 [RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the 675 Extensible Provisioning Protocol", March 2020, 676 . 678 8.2. Informative References 680 [IANA_Registrar_IDs] 681 Internet Assigned Numbers Authority, "IANA Assignments - 682 Registrar IDs", 2020, . 685 [ISO4217] International Organization for Standardization, "ISO 4217 686 Currency Codes", 2018, . 689 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 690 DOI 10.17487/RFC2629, June 1999, 691 . 693 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 694 Text on Security Considerations", BCP 72, RFC 3552, 695 DOI 10.17487/RFC3552, July 2003, 696 . 698 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 699 IANA Considerations Section in RFCs", RFC 5226, 700 DOI 10.17487/RFC5226, May 2008, 701 . 703 Appendix A. File Naming Convention 705 TBD on file naming convention suggestion 707 Authors' Addresses 709 Joseph Yee (editor) 710 Afilias 711 Toronto 712 Canada 714 Email: jyee@afilias.info 716 James Galvin 717 Afilias 718 Horsham, PA 719 United States 721 Email: jgalvin@afilias.info