idnits 2.17.1 draft-yee-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 (8 March 2020) is 1509 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ISO4217' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 681, 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: 9 September 2020 8 March 2020 7 Simple Registration Reporting 8 draft-yee-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 9 September 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 . . . . . . . . . . . . . . . 4 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. Time . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2.1.7. Term . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.1.8. Fee . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 6 79 2.2.4. Domain Restore . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . . . 7 87 2.3.7. Expiry_date . . . . . . . . . . . . . . . . . . . . . 7 88 2.4. Registration Information Fields . . . . . . . . . . . . . 8 89 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 8 90 2.4.2. Registrant_ID . . . . . . . . . . . . . . . . . . . . 8 91 2.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8 92 2.4.4. 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 . . . . . . . . . . . . . . . . . . . . 9 98 3. Report Definition Specification . . . . . . . . . . . . . . . 9 99 3.1. Transaction Report . . . . . . . . . . . . . . . . . . . 9 100 3.2. Premium Name Report . . . . . . . . . . . . . . . . . . . 10 101 3.3. Domain RGP Report . . . . . . . . . . . . . . . . . . . . 11 102 3.4. Reserved Domain Report . . . . . . . . . . . . . . . . . 11 103 3.5. Domain Inventory Report . . . . . . . . . . . . . . . . . 11 104 3.6. Contact Inventory Report . . . . . . . . . . . . . . . . 12 105 3.7. Host Inventory Report . . . . . . . . . . . . . . . . . . 12 106 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 107 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 108 5.1. Field Definition . . . . . . . . . . . . . . . . . . . . 13 109 5.2. Report Definition . . . . . . . . . . . . . . . . . . . . 13 110 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 111 7. Internationalization Considerations . . . . . . . . . . . . . 14 112 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 113 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 114 8.2. Informative References . . . . . . . . . . . . . . . . . 15 115 Appendix A. File Naming Convention . . . . . . . . . . . . . . . 15 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 118 1. Introduction 120 Currently, domain name registry operators (the producer) create and 121 set their own domain name registration reports for use by their 122 registrars (the consumer). Among the distinctions that vary by 123 producers is the syntax of the data provided, e.g., date formats, and 124 the format of the collection of the data provided, e.g., the report 125 may be a CSV file that tends to allow for straightforward importation 126 or a PDF file that can be problematic to import. In addition, 127 although there are a number of best practice reports that have 128 evolved, these are not currently documented as such, which results in 129 a fair amount of customization on the part of the consumers to import 130 data. 132 This document standardizes the name and syntax of the data elements 133 to be used across all existing domain name registration reports and 134 creates an IANA registry of them to facilitate their evolution, 135 including adding additional data elements as needed. In addition, a 136 known set of existing standard reports using the aforementioned data 137 elements is specified in another IANA registry to facilitate the 138 evolution of the reports and adding additional report definitions as 139 needed. 141 Each report definition MUST use the data elements defined here, 142 including all future reports. Future reports and future data 143 elements may be specified in their own individual documents, updating 144 the IANA registries as needed. 146 1.1. Requirements Language 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 150 document are to be interpreted as described in RFC 2119 [RFC2119]. 152 2. Data Element Specification 154 Data elements are grouped into categories for convenience. There is 155 no other significance to the groupings. 157 Each data element conceptually represents the column heading in a 158 printed report. It is a single unit of information that can be 159 passed from the producer to the consumer. The primary purposes of 160 the IANA registry of data elements are to ensure that each data 161 element is assigned a unique name and that the syntax of each data 162 element is specified. 164 The name of the data element MUST be unique and this characteristic 165 MUST be enforced by registry. The name is used in the report 166 definition (in the next section) to alert the consumer as to what to 167 expect in the file and how to import the data element. 169 The field names MUST NOT contain any whitespace and MAY use US-ASCII 170 underscores (_) as a separator. 172 The US-ASCII comma (,) and backslash (\) are special and MUST NOT 173 appear in any field name or data element value. In order to include 174 either character it must be quoted as follows. 176 * COMMA - to insert a comma precede it with a backslash thus (\,). 178 * BACKSLASH - to insert a backslash precede it with a backslash thus 179 (\\). 181 The syntax of the data element MAY be whatever is appropriate for the 182 information to be passed. In most cases it will be imported from 183 other standard specifications where the data element is already 184 defined for use in other protocols. In all cases the syntax 185 restriction mentioned above MUST be respected. 187 The subsections below comprise an initial list of known data elements 188 commonly being used between producers and consumers as of the date of 189 publication of this document. The title of the subsection is the 190 field name for the data element. 192 2.1. General Information Fields 193 2.1.1. TLD 195 The string of the top level domain involved that SHOULD be in A-LABEL 196 format. 198 2.1.2. Server_TRID 200 The transaction identifier issued by EPP Server. The format MUST 201 conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. 203 2.1.3. Domain 205 The domain object in EPP RFC 5731 [RFC5731] that contains the full 206 domain name that SHOULD be in A-Label format. 208 2.1.4. Transaction_Type 210 The type of transform action made to the domain object (CREATE, 211 DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730] 212 Section 2.9.3 214 2.1.5. Ojbect_Type 216 The object type involved in the report. In the EPP environment, an 217 object could be domain RFC 5731 [RFC5731], contact RFC 5733 218 [RFC5733], or host RFC 5732 [RFC5732]. 220 2.1.6. Time 222 The timestamp of the transaction recorded in the system. The date 223 and time format follows the "type=dateTime" specification as defined 224 in RFC 5731 [RFC5731]. 226 2.1.7. Term 228 The number of unit added to the domain registration period in 229 "domain:period" RFC 5731 [RFC5731] in create command or renew 230 command. If there's no "domain:period", it should take the default 231 value set by the registry. 233 2.1.8. Fee 235 The amount of money charged or returned (shown as negative value) to 236 the registrar. The numeric format MUST conform to the currency 237 specified below in Section 2.1.9. The format must conform to 238 "balanceType" as defined in [draft-ietf-regext-epp-fees] 240 2.1.9. Currency 242 The currency used in the money charged as documented above in 243 Section 2.1.18. It is recommended for currency code to follow ISO 244 4217 [ISO4217]standard. 246 2.1.10. Status 248 The status of domain object. It MUST be one of the values specified 249 in RFC 5731 [RFC5731] Section 2.3. 251 2.1.11. Registrar 253 The name of the registrar 255 2.1.12. Period 257 The type of time (year, month) in 'Term' described above in 258 Section 2.1.7 260 2.1.13. Description 262 Additional information regarding the current entry in the report. It 263 is provided by the producer and its actual value is a matter of local 264 policy. 266 2.2. Domain Price Fields 268 2.2.1. Domain Create 270 The fee charged to create the domain. The format must conform to 271 "balanceType" as defined in [draft-ietf-regext-epp-fees] 273 2.2.2. Domain Renew 275 The fee charged to renew the domain. The format must conform to 276 "balanceType" as defined in [draft-ietf-regext-epp-fees] 278 2.2.3. Domain Transfer 280 The fee charged to transfer the domain. The format must conform to 281 "balanceType" as defined in [draft-ietf-regext-epp-fees] 283 2.2.4. Domain Restore 285 The fee charged to restore the domain. The format must conform to 286 "balanceType" as defined in [draft-ietf-regext-epp-fees] 288 2.3. Timestamp Fields 290 2.3.1. Start_date 292 The timestamp of when the domain object becomes available. The date 293 and time format follows the "type=dateTime" specification as defined 294 in RFC 5731 [RFC5731]. 296 2.3.2. Deleted_date 298 The timestamp of when the domain was deleted by the end user. The 299 date and time format follows the "type=dateTime" specification as 300 defined in RFC 5731 [RFC5731]. 302 2.3.3. RGP_date 304 The timestamp of when the domain will complete its redemption grace 305 period. In BestPractice.domains, this is referred to as 'expired'. 306 The date and time format follows the "type=dateTime" specification as 307 defined in RFC 5731 [RFC5731]. 309 2.3.4. Purge_date 311 The timestamp of when the domain will be purged and become available 312 again. In BestPractice.domains, this is referred to as 'purged'. 313 The date and time format follows the "type=dateTime" specification as 314 defined in RFC 5731 [RFC5731]. 316 2.3.5. Updated_date 318 The timestamp of the last time the domain object was updated. In 319 BestPractice.domains, this is referred to as 'Updated'. The date and 320 time format follows the "type=dateTime" specification as defined in 321 RFC 5731 [RFC5731]. 323 2.3.6. Create_date 325 The timestamp of the domain object was allocated. The date and time 326 format follows the "type=dateTime" specification as defined in RFC 327 5731 [RFC5731]. 329 2.3.7. Expiry_date 331 The timestamp of the domain object will expire. The date and time 332 format follows the "type=dateTime" specification as defined in RFC 333 5731 [RFC5731]. 335 2.4. Registration Information Fields 337 2.4.1. Registrar_ID 339 The identifier assigned to the registrar. If the registrar is 340 accredited under ICANN, it MUST be the registrar's IANA ID. 341 Otherwise it is a value known between the producer and the consumer. 343 2.4.2. Registrant_ID 345 The identifier assigned to the contact object that is associated as 346 registrant of the domain name that MUST conform to "clIDType" 347 specified in RFC 5730 [RFC5730]. 349 2.4.3. DNSSEC 351 The value MUST be either 'YES' or 'NO' to indicate whether the domain 352 is DNSSEC signed. 354 2.4.4. Contact_ID 356 The identifier of the contact object. 358 2.4.5. Contact_Type 360 The value MUST be one of value as defined by "contactAttrType" in RFC 361 5731 [RFC5731]. 363 2.4.6. Contact_Name 365 The name of the contact object. Usually it is the name of an 366 individual or an organization as described in RFC 5733 [RFC5733] 367 Section 2.3 369 2.4.7. INUSE 371 MUST be either "YES" or "NO" to indicate whether the contact object 372 is associated with a domain object. 374 2.4.8. Nameserver_Host 376 The full domain name of the host object. The name MUST be in A-Label 377 format. 379 2.4.9. Nameserver_IP 381 The IP address of the host object. The syntax of the IPv4 address 382 MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address 383 MUST conform to RFC 4291 [RFC4291]. 385 3. Report Definition Specification 387 Each report specification conceptually represents a file of comma 388 separated values (commonly called a CSV file) where the values are 389 selected from the data elements specified above. The first row of 390 the file is a comma separated list of field names as specified in the 391 data element registry. The remaining rows of the file are the 392 unordered sets of data elements, one set per row, where each row is 393 one transaction in the report. 395 Each data element conceptually represents the column heading in a 396 printed report. The first row represents the column headings and 397 each succeeding row represents a transaction of the report. 399 A consumer MUST be able to receive data elements that are not 400 recognized and skip them accordingly, both in the header row and in 401 the transaction rows. 403 A report is specified in the report registry with two pieces of 404 information. First is the name of the report. This can be whatever 405 is appropriate as defined by the producer of the report. The name of 406 the report MUST be unique and this characteristic MUST be enforced by 407 registry. 409 Second is the ordered list of field names of what is included in the 410 report. The field names MUST be listed in the data element registry 411 specified above. The field names and the data MUST appear in the 412 report in the order listed in the report registry. 414 The subsections below comprise an initial list of standard reports 415 commonly being used between producers and consumers as of the data of 416 publication of this document. The title of the subsection is the 417 report name. 419 3.1. Transaction Report 421 +------------------+------------------------+ 422 | Field | Reference | 423 +==================+========================+ 424 | TLD | RFC XXXX Section 2.1.1 | 425 +------------------+------------------------+ 426 | Server_TRID | Section 2.1.2 | 427 +------------------+------------------------+ 428 | Domain | Section 2.1.3 | 429 +------------------+------------------------+ 430 | Registrar_ID | Section 2.4.1 | 431 +------------------+------------------------+ 432 | Registrar | Section 2.1.11 | 433 +------------------+------------------------+ 434 | Transaction_Type | Section 2.1.4 | 435 +------------------+------------------------+ 436 | Period | Section 2.1.12 | 437 +------------------+------------------------+ 438 | Term | Section 2.1.7 | 439 +------------------+------------------------+ 440 | Fee | Section 2.1.8 | 441 +------------------+------------------------+ 442 | Currency | Section 2.1.9 | 443 +------------------+------------------------+ 444 | Description | Section 2.1.13 | 445 +------------------+------------------------+ 447 Table 1: Transaction Report Definition Table 449 3.2. Premium Name Report 451 +-----------------+------------------------+ 452 | Field | Reference | 453 +=================+========================+ 454 | TLD | RFC XXXX Section 2.1.1 | 455 +-----------------+------------------------+ 456 | Domain | Section 2.1.3 | 457 +-----------------+------------------------+ 458 | Status | Section 2.1.10 | 459 +-----------------+------------------------+ 460 | Description | Section 2.1.13 | 461 +-----------------+------------------------+ 462 | Currency | Section 2.1.9 | 463 +-----------------+------------------------+ 464 | Domain_Create | Section 2.2.1 | 465 +-----------------+------------------------+ 466 | Domain_Renew | Section 2.2.2 | 467 +-----------------+------------------------+ 468 | Domain_Transfer | Section 2.2.3 | 469 +-----------------+------------------------+ 470 | Domain_Restore | Section 2.2.4 | 471 +-----------------+------------------------+ 472 | Start_Date | Section 2.3.1 | 473 +-----------------+------------------------+ 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 | 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 536 Definition Table 538 3.6. Contact Inventory Report 540 +--------------+---------------+ 541 | Field | Reference | 542 +==============+===============+ 543 | Contact_ID | Section 2.4.4 | 544 +--------------+---------------+ 545 | TLD | Section 2.1.1 | 546 +--------------+---------------+ 547 | Domain | Section 2.1.3 | 548 +--------------+---------------+ 549 | Contact_Type | Section 2.4.5 | 550 +--------------+---------------+ 551 | Contact_Name | Section 2.4.6 | 552 +--------------+---------------+ 553 | Updated_Date | Section 2.3.5 | 554 +--------------+---------------+ 555 | INUSE | Section 2.4.7 | 556 +--------------+---------------+ 557 | Registrar_ID | Section 2.4.1 | 558 +--------------+---------------+ 560 Table 6: Contact Inventory 561 Report Definition Table 563 3.7. Host Inventory Report 565 +-----------------+---------------+ 566 | Field | Reference | 567 +=================+===============+ 568 | TLD | Section 2.1.1 | 569 +-----------------+---------------+ 570 | Nameserver_Host | Section 2.4.8 | 571 +-----------------+---------------+ 572 | Contact_Type | Section 2.4.9 | 573 +-----------------+---------------+ 575 Table 7: Host Inventory Report 576 Definition Table 578 4. Acknowledgements 580 TBD 582 5. IANA Considerations 584 This document asks IANA to create two new registries. Each registry 585 is a first-come first-served registry. 587 DETAILS TO BE SPECIFIED AS THE DOCUMENT EVOLVES. 589 5.1. Field Definition 591 The field name must be unique and case insensitive. 593 PROPOSED FIELD NAME TABLE ENTRY. DETAILS TO BE SPECIFIED AS THE 594 DOCUMENT EVOLVES. 596 Name of field 597 Enforced to be case-insensitive (if appropriate) unique 599 Reference document defining the field, including section number 600 Should be an RFC in many cases 602 Registrant 603 Will be IESG for initial entries 605 Status 606 MUST be active, inactive, unknown 608 5.2. Report Definition 610 The report name must be unique and case insensitive. that any future 611 submission must not have the same case insensitive match with prior 612 entry. 614 Name of report 616 Name of report 617 Document Status 619 Reference (including section number) 621 Registrant: IESG 623 TLD: any 625 Status: active 627 6. Security Considerations 629 TBD 631 7. Internationalization Considerations 633 The character encoding for the file contents MUST use UTF-8. 635 8. References 637 8.1. Normative References 639 [RFC0791] Postel, J., "Internet Protocol", September 1981, 640 . 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, 644 DOI 10.17487/RFC2119, March 1997, 645 . 647 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 648 Architecture", February 2006, 649 . 651 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 652 August 2009, . 654 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 655 Domain Name Mapping", August 2009, 656 . 658 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 659 Host Mapping", August 2009, 660 . 662 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 663 Contact Mapping", August 2009, 664 . 666 8.2. Informative References 668 [ISO4217] International Organization for Standardization, "ISO 4217 669 Currency Codes", 2018, . 672 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 673 DOI 10.17487/RFC2629, June 1999, 674 . 676 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 677 Text on Security Considerations", BCP 72, RFC 3552, 678 DOI 10.17487/RFC3552, July 2003, 679 . 681 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 682 IANA Considerations Section in RFCs", RFC 5226, 683 DOI 10.17487/RFC5226, May 2008, 684 . 686 Appendix A. File Naming Convention 688 TBD on file naming convention suggestion 690 Authors' Addresses 692 Joseph Yee (editor) 693 Afilias 694 Toronto 695 Canada 697 Email: jyee@afilias.info 699 James Galvin 700 Afilias 701 Horsham, PA 702 United States 704 Email: jgalvin@afilias.info