idnits 2.17.1 draft-mcpherson-sattler-ry-transaction-report-02.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 3, 2018) is 1971 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force N. McPherson 2 Internet-Draft 1&1 IONOS SE 3 Intended status: Best Current Practice T. Sattler, Editor 4 Expires: June 2, 2019 December 3, 2018 6 Registry Transaction Report 7 draft-mcpherson-sattler-ry-transaction-report-02 9 Abstract 11 This document describes the content of a transaction report based on 12 the registry report structure and delivered by the registry reporting 13 repository. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 This Internet-Draft will expire on June 2, 2019. 32 Copyright Notice 34 Copyright (c) 2018 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 2 50 2.1. Internationalized Domain Names . . . . . . . . . . . . . 3 51 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 52 2.3. Character Encoding . . . . . . . . . . . . . . . . . . . 3 53 2.4. Currency . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Report Headings . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Transaction Types . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Transaction Periods . . . . . . . . . . . . . . . . . . . . . 4 57 6. Transaction Fees . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. Deviating Fees . . . . . . . . . . . . . . . . . . . . . 5 59 7. Registrar ID . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Single TLD File Example . . . . . . . . . . . . . . . . . 5 62 8.2. Multiple TLDs File Example . . . . . . . . . . . . . . . 5 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 12.1. Normative References . . . . . . . . . . . . . . . . . 7 68 12.2. Informative References . . . . . . . . . . . . . . . . 7 69 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 7 70 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 7 71 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 7 72 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 Modern top-level domain registries provide a number of detailed 78 reports and documents that their registrars require on a daily, 79 weekly and monthly basis. These most commonly include transaction 80 reports, as well as lists containing currently unavailable domains 81 and current premium domains. These reports are critical for 82 registrars' businesses and play an important role in accounting and 83 operations processes as well as in sales and marketing activities. 84 In the current set-up registrars must download these reports from 85 each registry's intranet in a different manner according to each 86 registry's own document management set up. 88 This document describes the content of a transaction report based on 89 the [I-D.mcpherson-sattler-registry-report-structure] and delivered 90 by the [I-D.mcpherson-sattler-registry-reporting-repo]. 92 2. Terminology and Definitions 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119] when 97 specified in their uppercase forms. 99 2.1. Internationalized Domain Names 101 MUST be as defined in 102 [I-D.mcpherson-sattler-registry-report-structure]. 104 2.2. Dates and Times 106 MUST be as defined in 107 [I-D.mcpherson-sattler-registry-report-structure]. 109 2.3. Character Encoding 111 MUST be as defined in 112 [I-D.mcpherson-sattler-registry-report-structure]. 114 2.4. Currency 116 MUST be as defined in 117 [I-D.mcpherson-sattler-registry-report-structure]. 119 3. Report Headings 121 The first row MUST be the column headings in the following order: 123 SVTRID Server transaction identifier MUST be assigned 124 by and MUST be unique to the server. 126 TLD It MUST contain the top-level domain name formatted 127 according to section 2.1 of this document. 129 DOMAIN It MUST contain the domain name formatted according 130 to section 2.1 of this document. 132 TIMESTAMP It MUST contain the timestamp of the successful 133 transaction formatted according to section 2.2 of 134 this document. 136 TRANSACTIONTYPE It MUST contain the type of the successful 137 transaction according to section 4 of this 138 document. 140 PERIOD It MUST either contain the Period of the the 141 successful transaction according to section 5 of 142 this document or MUST be empty if no Period is 143 assigned to the transaction. 145 FEE It MUST contain the fee of the successful 146 transaction according to section 6 of this 147 document. 149 CURRENCY It MUST contain the currency of the successful 150 transaction according to section 2.4 of this 151 document. 153 DESCRIPTION It MAY contain a free description of the successful 154 transaction. 156 REGISTRARID It MUST contain the registrar ID of the succesful 157 transaction according to section 7 of this 158 document. 160 4. Transaction Types 162 Each transaction MUST be assigned to a type. Those type MUST either 163 be 'CREATE', 'RENEWAL', 'AUTORENEW', 'TRANSFER', 'TRADE', 'UPDATE' 164 or 'RESTORE'. 166 CREATE A successful domain create within the report period. 168 RENEWAL A successful explicit domain name renewal executed by the 169 domain name registrar within the report period. 171 AUTORENEW A successful domain name auto-renewal by the domain name 172 registry within the report period. 174 TRANSFER A successful domain name transfer within the report 175 period. 177 TRADE A successful domain name trade within the report 178 period. 180 UPDATE A successful billable domain name update within the report 181 period. 183 RESTORE A successful domain name restore within the report period. 184 This event MUST only include the restore fee. Any 185 additional renewal fee MUST be independently listed. 187 A successful transaction is also a completed transaction. Therefore, 188 transactions MUST NOT be deleted. If a transaction MUST be cleared, a 189 corresponding counter transaction MUST be made. 191 5. Transaction Periods 193 Transaction Types usually occur in Periods of 1 to 10 years, 194 sometimes there are monthly periods. Therefore, each transaction 195 MUST either have a Period associated or it MUST be empty if no Period 196 is assigned to the transaction. 198 The format MUST be in the format , where 199 MUST be unsigned and between 1 and 65535, without any 200 leading zero, and MUST be either 'y' for years or 'm' for 201 months. 203 If the number of months results in a full year, then the full year 204 MUST be used, e.g. instead of 12m or 24m, it should be 1y 205 respectively 2y. 207 6. Transaction Fees 209 All transactions MUST have a Fee associated. The fee amount, the 210 currency and the period MUST be listed separately. 212 Fees MUST either be whole numbers or rounded to two decimal places. 213 A period (.) is used as the dividing point. 215 6.1. Deviating Fees 217 If a domain name incurs a premium fee, that is not the standard price 218 for the TLD, a description of the price category SHOULD be given. 220 7. Registrar ID 222 A unique registrar ID MUST be listed, with each transaction. Those 223 IDs MUST be according the IANA registrar IDs (https://www.iana.org/ 224 assignments/registrar-ids/registrar-ids.xhtml) where applicable, 225 otherwise another unique registrar ID MUST be used. 227 8. Example 229 8.1. Single TLD File Example 231 This is an example of a transaction report for a single top-level 232 domain .example. 234 Filename: example_transactions_2018-11.csv.gz 236 SVTRID,TLD,DOMAIN,TIMESTAMP,TRANSACTIONTYPE,PERIOD,FEE,CURRENCY, 237 DESCRIPTION,REGISTRARID 238 54321-XYZ,example,nic.example,2018-11-08T08:01:01Z,AUTORENEW,1y,10, 239 USD,,1 240 54322-XYZ,example,foo.example,2018-11-09T08:00:00Z,CREATE,3y,10,USD,, 241 1 242 54323-XYZ,example,bar.example,2018-11-09T08:01:01Z,CREATE,1y,1000, 243 USD,PREMIUM A,1 244 54324-XYZ,example,foobar.example,2018-11-10T07:00:00Z,RESTORE,,40,USD 245 ,,1 246 54325-XYZ,example,foobar.example,2018-11-10T07:00:01Z,RENEWAL,,10,USD 247 ,,1 248 54326-XYZ,example,xn--r8jz45g.example,2018-11-11T06:30:00Z,TRANSFER, 249 1y,12.75,USD,,1 251 8.2. Multiple TLDs File Example 253 This is an example of a transaction report for multi top-level 254 domains by the example registry. 256 Filename: example_transactions_2018-11.csv.gz 257 SVTRID,TLD,DOMAIN,TIMESTAMP,TRANSACTIONTYPE,PERIOD,FEE,CURRENCY, 258 DESCRIPTION,REGISTRARID 259 54321-XYZ,example,nic.example,2018-11-08T08:01:01Z,AUTORENEW,1y,10, 260 USD,,1 261 54322-XYZ,example1,foo.example1,2018-11-09T08:00:00Z,CREATE,6m,9.90, 262 EUR,,1 263 54323-XYZ,example2,bar.example2,2018-11-09T08:01:01Z,CREATE,1y,4000, 264 BRL,PREMIUM C,1 265 54324-XYZ,xn--0zwm56d,xn--fsqu00a.xn--0zwm56d,2018-11-10T07:00:00Z, 266 RESTORE,,275,CNY,,1 267 54325-XYZ,xn--0zwm56d,xn--fsqu00a.xn--0zwm56d,2018-11-10T07:00:01Z, 268 RENEWAL,,70,CNY,,1 269 54326-XYZ,xn--zckzah,xn--r8jz45g.xn--zckzah,2018-11-11T06:30:00Z, 270 TRANSFER,1y,1200,JPY,,1 272 9. IANA Considerations 274 This document has no IANA actions. 276 10. Security Considerations 278 The registry transaction report described in this document does not 279 provide any security services. 281 11. Implementation Status 283 Note to RFC Editor: Please remove this section and the reference to 284 [RFC7942] before publication. 286 This section records the status of known implementations of the 287 protocol defined by this specification at the time of posting of this 288 Internet-Draft, and is based on a proposal described in [RFC7942]. 289 The description of implementations in this section is intended to 290 assist the IETF in its decision processes in progressing drafts to 291 RFCs. Please note that the listing of any individual implementation 292 here does not imply endorsement by the IETF. Furthermore, no effort 293 has been spent to verify the information presented here that was 294 supplied by IETF contributors. This is not intended as, and must not 295 be construed to be, a catalog of available implementations or their 296 features. Readers are advised to note that other implementations may 297 exist. 299 According to [RFC7942], "this will allow reviewers and working groups 300 to assign due consideration to documents that have the benefit of 301 running code, which may serve as evidence of valuable experimentation 302 and feedback that have made the implemented protocols more mature. It 303 is up to the individual working groups to use this information as 304 they see fit". 306 Add implementation details once available. 308 12. References 310 12.1. Normative References 312 [I-D.mcpherson-sattler-registry-report-structure] 313 McPherson, N. and Sattler, T., "Registry Report Strucutre" 314 , (work in 316 progress), November 2018 318 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 319 Requirement Levels", BCP 14, RFC 2119, March 1997, 320 . 322 12.2. Informative References 324 [I-D.mcpherson-sattler-registry-reporting-repo] 325 McPherson, N. and Sattler, T., "Registry Reporting 326 Repository", (work in 328 progress), November 2018 330 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 331 Running Code: The Implementation Status Section", RFC 332 7942, July 2016, 333 . 335 Appendix A. Change History 337 A.1. Change from 00 to 01 339 Added acknowledgements. Changed Y to lowercase. Fixed csv examples. 340 Changed security considerations. Added SRTRID to identify 341 transactions. Clarified successful transaction. 343 A.2. Change from 01 to 02 345 Clarified the Period. Fixed numerous typos. Changed limit for Period 346 from 1-99 to unsigned 16 bit integer. 348 Appendix B. Acknowledgements 350 The authors wish to thank the following persons for their feedback 351 and suggestions (sorted alphabetically by company): 353 o Jeff Yeh, Brandma 354 o Elaine Pruis, Domain Research 355 o Gaurav Vedi, Dominion Registries 357 Authors' Addresses 359 Neal McPherson 360 1&1 IONOS SE 361 Ernst-Frey-Str. 5 362 76135 Karlsruhe 363 DE 365 Email: neal.mcpherson@ionos.com 366 URI: https://www.ionos.com 368 Tobias Sattler 370 Email: tobias.sattler@me.com 371 URI: https://tobiassattler.com