idnits 2.17.1 draft-ietf-regext-simple-registration-reporting-00.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 (1 June 2020) is 1424 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ISO4217' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 690, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 695, 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 (~~), 5 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: 3 December 2020 1 June 2020 7 Simple Registration Reporting 8 draft-ietf-regext-simple-registration-reporting-00 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 3 December 2020. 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 . . . . . . . . . . . . . . . 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. Ojbect_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 Fields . . . . . . . . . . . . . . . . . . . 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.3. Timestamp Fields . . . . . . . . . . . . . . . . . . . . 7 81 2.3.1. Start_Date . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . 8 87 2.3.7. Expiry_Date . . . . . . . . . . . . . . . . . . . . . 8 88 2.4. Registration Information Fields . . . . . . . . . . . . . 8 89 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 96 2.4.8. Nameserver_Host . . . . . . . . . . . . . . . . . . . 9 97 2.4.9. Nameserver_IP . . . . . . . . . . . . . . . . . . . . 9 98 2.4.10. Client_Contact_ID . . . . . . . . . . . . . . . . . . 9 99 3. Report Definition Specification . . . . . . . . . . . . . . . 9 100 3.1. Transaction Report . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . 15 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 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 field names MUST NOT contain any whitespace and MAY use US-ASCII 171 underscores (_) as a separator. 173 The US-ASCII comma (,) and backslash (\) are special and MUST NOT 174 appear in any field name or data element value. In order to include 175 either character it must be quoted as follows. 177 * COMMA - to insert a comma precede it with a backslash thus (\,). 179 * BACKSLASH - to insert a backslash precede it with a backslash thus 180 (\\). 182 The syntax of the data element MAY be whatever is appropriate for the 183 information to be passed. In most cases it will be imported from 184 other standard specifications where the data element is already 185 defined for use in other protocols. In all cases the syntax 186 restriction mentioned above MUST be respected. 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 field name for the data element. 193 2.1. General Information Fields 195 2.1.1. TLD 197 The string of the top level domain involved that SHOULD be in A-LABEL 198 format. 200 2.1.2. Server_TRID 202 The transaction identifier issued by EPP Server. The format MUST 203 conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. 205 2.1.3. Domain 207 This is the domain name in EPP RFC 5731 [RFC5731] domain object and 208 it SHOULD be in A-Label format. 210 2.1.4. Transaction_Type 212 The type of transform action made to the domain object (CREATE, 213 DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730] 214 Section 2.9.3 216 2.1.5. Ojbect_Type 218 The object type involved in the report. In the EPP environment, an 219 object could be domain RFC 5731 [RFC5731], contact RFC 5733 220 [RFC5733], or host RFC 5732 [RFC5732]. 222 2.1.6. DateTime 224 The timestamp of the transaction recorded in the system. The date 225 and time format follows the "type=dateTime" specification as defined 226 in RFC 5731 [RFC5731]. 228 2.1.7. Term 230 The number of unit added to the domain registration period in 231 "domain:period" RFC 5731 [RFC5731] in create command or renew 232 command. If there's no "domain:period", it should take the default 233 value set by the registry. 235 2.1.8. Fee 237 The amount of money charged or returned (shown as negative value) to 238 the registrar. The numeric format MUST conform to the currency 239 specified below in Section 2.1.9. The format must conform to 240 "balanceType" as defined in RFC 8748 [RFC8748] 242 2.1.9. Currency 244 The currency used in the money charged as documented above in 245 Section 2.1.18. It is recommended for currency code to follow ISO 246 4217 [ISO4217]standard. 248 2.1.10. Status 250 The status of domain object. It MUST be one of the values specified 251 in RFC 5731 [RFC5731] Section 2.3. 253 2.1.11. Registrar 255 The name of the registrar. This field is text/string with no naming 256 convention enforced. 258 2.1.12. Period 260 The type of time (year, month) in 'Term' described above in 261 Section 2.1.7 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. 269 2.2. Domain Price Fields 271 2.2.1. Domain_Create 273 The fee charged to create the domain. The format must conform to 274 "balanceType" as defined in [draft-ietf-regext-epp-fees] 276 2.2.2. Domain_Renew 278 The fee charged to renew the domain. The format must conform to 279 "balanceType" as defined in [draft-ietf-regext-epp-fees] 281 2.2.3. Domain_Transfer 283 The fee charged to transfer the domain. The format must conform to 284 "balanceType" as defined in [draft-ietf-regext-epp-fees] 286 2.2.4. Domain_Restore 288 The fee charged to restore the domain. The format must conform to 289 "balanceType" as defined in [draft-ietf-regext-epp-fees] 291 2.3. Timestamp Fields 293 2.3.1. Start_Date 295 The timestamp of when the domain object becomes available. The date 296 and time format follows the "type=dateTime" specification as defined 297 in RFC 5731 [RFC5731]. 299 2.3.2. Deleted_Date 301 The timestamp of when the domain was deleted by the end user. The 302 date and time format follows the "type=dateTime" specification as 303 defined in RFC 5731 [RFC5731]. 305 2.3.3. RGP_Date 307 The timestamp of when the domain will complete its redemption grace 308 period. In BestPractice.domains, this is referred to as 'expired'. 309 The date and time format follows the "type=dateTime" specification as 310 defined in RFC 5731 [RFC5731]. 312 2.3.4. Purge_Date 314 The timestamp of when the domain will be purged and become available 315 again. In BestPractice.domains, this is referred to as 'purged'. 316 The date and time format follows the "type=dateTime" specification as 317 defined in RFC 5731 [RFC5731]. 319 2.3.5. Updated_Date 321 The timestamp of the last time the domain object was updated. In 322 BestPractice.domains, this is referred to as 'Updated'. The date and 323 time format follows the "type=dateTime" specification as defined in 324 RFC 5731 [RFC5731]. 326 2.3.6. Create_Date 328 The timestamp of the domain object was allocated. The date and time 329 format follows the "type=dateTime" specification as defined in RFC 330 5731 [RFC5731]. 332 2.3.7. Expiry_Date 334 The timestamp of the domain object will expire. The date and time 335 format follows the "type=dateTime" specification as defined in RFC 336 5731 [RFC5731]. 338 2.4. Registration Information Fields 340 2.4.1. Registrar_ID 342 The identifier assigned to the registrar. If the registrar is 343 accredited under ICANN, it MUST be the registrar's IANA ID. 344 Otherwise it is a value known between the producer and the consumer. 346 2.4.2. Server_Registrant_ID 348 The identifier assigned to the contact object that is associated as 349 registrant of the domain name that MUST conform to "clIDType" 350 specified in RFC 5730 [RFC5730]. 352 2.4.3. DNSSEC 354 The value MUST be either 'YES' or 'NO' to indicate whether the domain 355 is DNSSEC signed. 357 2.4.4. Server_Contact_ID 359 The identifier of the contact object assigned by registry system. 361 2.4.5. Contact_Type 363 The value MUST be one of value as defined by "contactAttrType" in RFC 364 5731 [RFC5731]. 366 2.4.6. Contact_Name 368 The name of the contact object. Usually it is the name of an 369 individual or an organization as described in RFC 5733 [RFC5733] 370 Section 2.3 372 2.4.7. INUSE 374 MUST be either "YES" or "NO" to indicate whether the contact object 375 is associated with a domain object. 377 2.4.8. Nameserver_Host 379 The full domain name of the host object. The name MUST be in A-Label 380 format. 382 2.4.9. Nameserver_IP 384 The IP address of the host object. The syntax of the IPv4 address 385 MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address 386 MUST conform to RFC 4291 [RFC4291]. 388 2.4.10. Client_Contact_ID 390 The identifier of the contact object assigned by registrar. 392 3. Report Definition Specification 394 Each report specification conceptually represents a file of comma 395 separated values (commonly called a CSV file) where the values are 396 selected from the data elements specified above. The first row of 397 the file is a comma separated list of field names as specified in the 398 data element registry. The remaining rows of the file are the 399 unordered sets of data elements, one set per row, where each row is 400 one transaction in the report. 402 Each data element conceptually represents the column heading in a 403 printed report. The first row represents the column headings and 404 each succeeding row represents a transaction of the report. 406 A consumer MUST be able to receive data elements that are not 407 recognized and MAY skip them accordingly, both in the header row and 408 in the transaction rows. 410 A report is specified in the report registry with two pieces of 411 information. First is the name of the report. This can be whatever 412 is appropriate as defined by the producer of the report. The name of 413 the report MUST be unique and this characteristic MUST be enforced by 414 registry. 416 Second is the ordered list of field names of what is included in the 417 report. The field names MUST be listed in the data element registry 418 specified above. The field names and the data MUST appear in the 419 report in the order listed in the report registry. 421 The subsections below comprise an initial list of standard reports 422 commonly being used between producers and consumers as of the data of 423 publication of this document. The title of the subsection is the 424 report name. 426 3.1. Transaction Report 428 +------------------+------------------------+ 429 | Field | Reference | 430 +==================+========================+ 431 | TLD | RFC XXXX Section 2.1.1 | 432 +------------------+------------------------+ 433 | Server_TRID | Section 2.1.2 | 434 +------------------+------------------------+ 435 | Domain | Section 2.1.3 | 436 +------------------+------------------------+ 437 | DateTime | Section 2.1.6 | 438 +------------------+------------------------+ 439 | Registrar_ID | Section 2.4.1 | 440 +------------------+------------------------+ 441 | Registrar | Section 2.1.11 | 442 +------------------+------------------------+ 443 | Transaction_Type | Section 2.1.4 | 444 +------------------+------------------------+ 445 | Period | Section 2.1.12 | 446 +------------------+------------------------+ 447 | Term | Section 2.1.7 | 448 +------------------+------------------------+ 449 | Fee | Section 2.1.8 | 450 +------------------+------------------------+ 451 | Currency | Section 2.1.9 | 452 +------------------+------------------------+ 453 | Description | Section 2.1.13 | 454 +------------------+------------------------+ 456 Table 1: Transaction Report Definition Table 458 3.2. Premium Name Report 460 +-----------------+------------------------+ 461 | Field | Reference | 462 +=================+========================+ 463 | TLD | RFC XXXX Section 2.1.1 | 464 +-----------------+------------------------+ 465 | Domain | Section 2.1.3 | 466 +-----------------+------------------------+ 467 | Status | Section 2.1.10 | 468 +-----------------+------------------------+ 469 | Description | Section 2.1.13 | 470 +-----------------+------------------------+ 471 | Currency | Section 2.1.9 | 472 +-----------------+------------------------+ 473 | Domain_Create | Section 2.2.1 | 474 +-----------------+------------------------+ 475 | Domain_Renew | Section 2.2.2 | 476 +-----------------+------------------------+ 477 | Domain_Transfer | Section 2.2.3 | 478 +-----------------+------------------------+ 479 | Domain_Restore | Section 2.2.4 | 480 +-----------------+------------------------+ 481 | Start_Date | Section 2.3.1 | 482 +-----------------+------------------------+ 484 Table 2: Premium Name Report Definition 485 Table 487 3.3. Domain RGP Report 489 +--------------+------------------------+ 490 | Field | Reference | 491 +==============+========================+ 492 | TLD | RFC XXXX Section 2.1.1 | 493 +--------------+------------------------+ 494 | Domain | Section 2.1.3 | 495 +--------------+------------------------+ 496 | Deleted_Date | Section 2.3.2 | 497 +--------------+------------------------+ 498 | RGP_Date | Section 2.3.3 | 499 +--------------+------------------------+ 500 | Purge_Date | Section 2.3.4 | 501 +--------------+------------------------+ 503 Table 3: Domain RGP Report Definition 504 Table 506 3.4. Reserved Domain Report 508 +--------+------------------------+ 509 | Field | Reference | 510 +========+========================+ 511 | TLD | RFC XXXX Section 2.1.1 | 512 +--------+------------------------+ 513 | Domain | Section 2.1.3 | 514 +--------+------------------------+ 515 | Status | Section 2.1.10 | 516 +--------+------------------------+ 517 Table 4: Reserved Domain Report 518 Definition Table 520 3.5. Domain Inventory Report 522 +----------------------+------------------------+ 523 | Field | Reference | 524 +======================+========================+ 525 | TLD | RFC XXXX Section 2.1.1 | 526 +----------------------+------------------------+ 527 | Domain | Section 2.1.3 | 528 +----------------------+------------------------+ 529 | Updated_Date | Section 2.3.5 | 530 +----------------------+------------------------+ 531 | Registrar_ID | Section 2.4.1 | 532 +----------------------+------------------------+ 533 | Create_Date | Section 2.3.6 | 534 +----------------------+------------------------+ 535 | Expiry_Date | Section 2.3.7 | 536 +----------------------+------------------------+ 537 | Server_Registrant_ID | Section 2.4.2 | 538 +----------------------+------------------------+ 539 | DNSSEC | Section 2.4.3 | 540 +----------------------+------------------------+ 541 | Status | Section 2.1.10 | 542 +----------------------+------------------------+ 544 Table 5: Domain Inventory Report Definition Table 546 3.6. Contact Inventory Report 548 +-------------------+----------------+ 549 | Field | Reference | 550 +===================+================+ 551 | Server_Contact_ID | Section 2.4.4 | 552 +-------------------+----------------+ 553 | Client_Contact_ID | Section 2.4.10 | 554 +-------------------+----------------+ 555 | TLD | Section 2.1.1 | 556 +-------------------+----------------+ 557 | Domain | Section 2.1.3 | 558 +-------------------+----------------+ 559 | Contact_Type | Section 2.4.5 | 560 +-------------------+----------------+ 561 | Contact_Name | Section 2.4.6 | 562 +-------------------+----------------+ 563 | Updated_Date | Section 2.3.5 | 564 +-------------------+----------------+ 565 | INUSE | Section 2.4.7 | 566 +-------------------+----------------+ 567 | Registrar_ID | Section 2.4.1 | 568 +-------------------+----------------+ 570 Table 6: Contact Inventory Report 571 Definition Table 573 3.7. Host Inventory Report 575 +-----------------+-----------------------+ 576 | Field | Reference | 577 +=================+=======================+ 578 | TLD | RFCXXXX Section 2.1.1 | 579 +-----------------+-----------------------+ 580 | Nameserver_Host | Section 2.4.8 | 581 +-----------------+-----------------------+ 582 | Nameserver_IP | Section 2.4.9 | 583 +-----------------+-----------------------+ 585 Table 7: Host Inventory Report 586 Definition Table 588 4. Acknowledgements 590 The authors would like to thank Roger Carney, Jody Kolker for their 591 reviews and suggestions 593 5. IANA Considerations 595 This document asks IANA to create two new registries. Each registry 596 is a first-come first-served registry. 598 DETAILS TO BE SPECIFIED AS THE DOCUMENT EVOLVES. 600 5.1. Field Definition 602 The field name must be unique and case insensitive. 604 PROPOSED FIELD NAME TABLE ENTRY. DETAILS TO BE SPECIFIED AS THE 605 DOCUMENT EVOLVES. 607 Name of field 608 Enforced to be case-insensitive (if appropriate) unique 610 Reference document defining the field, including section number 611 Should be an RFC in many cases 613 Registrant 614 Will be IESG for initial entries 616 Status 617 MUST be active, inactive, unknown 619 5.2. Report Definition 621 The report name must be unique and case insensitive. that any future 622 submission must not have the same case insensitive match with prior 623 entry. 625 Name of report 627 Document Status 629 Reference (including section number) 631 Registrant: IESG 633 TLD: any 635 Status: active 637 6. Security Considerations 639 TBD 641 7. Internationalization Considerations 643 The character encoding for the file contents MUST use UTF-8. 645 8. References 647 8.1. Normative References 649 [RFC0791] Postel, J., "Internet Protocol", September 1981, 650 . 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, 654 DOI 10.17487/RFC2119, March 1997, 655 . 657 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 658 Architecture", February 2006, 659 . 661 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 662 August 2009, . 664 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 665 Domain Name Mapping", August 2009, 666 . 668 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 669 Host Mapping", August 2009, 670 . 672 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 673 Contact Mapping", August 2009, 674 . 676 [RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the 677 Extensible Provisioning Protocol", March 2020, 678 . 680 8.2. Informative References 682 [ISO4217] International Organization for Standardization, "ISO 4217 683 Currency Codes", 2018, . 686 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 687 DOI 10.17487/RFC2629, June 1999, 688 . 690 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 691 Text on Security Considerations", BCP 72, RFC 3552, 692 DOI 10.17487/RFC3552, July 2003, 693 . 695 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 696 IANA Considerations Section in RFCs", RFC 5226, 697 DOI 10.17487/RFC5226, May 2008, 698 . 700 Appendix A. File Naming Convention 702 TBD on file naming convention suggestion 704 Authors' Addresses 705 Joseph Yee (editor) 706 Afilias 707 Toronto 708 Canada 710 Email: jyee@afilias.info 712 James Galvin 713 Afilias 714 Horsham, PA 715 United States 717 Email: jgalvin@afilias.info