idnits 2.17.1 draft-mcpherson-sattler-transaction-report-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 : ---------------------------------------------------------------------------- == 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 (March 27, 2019) is 1857 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: September 26, 2019 March 27, 2019 6 Transaction Report 7 draft-mcpherson-sattler-transaction-report-01 9 Abstract 11 This document describes the content of a Transaction Report based on 12 the Report Structure and delivered by the Reporting Repository. 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress". 29 This Internet-Draft will expire on September 23, 2019. 31 Copyright Notice 33 Copyright (c) 2019 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 48 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 49 2.1. Internationalized Domain Names . . . . . . . . . . . . . 3 50 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 51 2.3. Character Encoding . . . . . . . . . . . . . . . . . . . 3 52 2.4. Currency . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Report Headings . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. Transaction Types . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Standard Transaction Types . . . . . . . . . . . . . . . 4 56 4.2. Non-Standard Transaction Types . . . . . . . . . . . . . 5 57 5. Transaction Periods . . . . . . . . . . . . . . . . . . . . . 5 58 6. Transaction Fees . . . . . . . . . . . . . . . . . . . . . . 5 59 6.1. Deviating Fees . . . . . . . . . . . . . . . . . . . . . 5 60 7. Registrar ID . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 8.1. Single TLD File Example . . . . . . . . . . . . . . . . . 5 63 8.2. Multiple TLDs File Example . . . . . . . . . . . . . . . 6 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 6 67 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 12.1. Normative References . . . . . . . . . . . . . . . . . 7 69 12.2. Informative References . . . . . . . . . . . . . . . . 7 70 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 8 71 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 8 72 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 8 73 A.3. Change from 02 to TXN 00 . . . . . . . . . . . . . . . . 8 74 A.4. Change from TXN 00 to TXN 01 . . . . . . . . . . . . . . 8 75 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Modern top-level domain registries provide many detailed reports and 81 documents that their registrars require on a daily, weekly and 82 monthly basis. These most commonly include transaction reports, as 83 well as lists containing currently unavailable domains and current 84 premium domain fees. These reports are critical for registrars' 85 businesses and play an important role in accounting and operations 86 processes as well as in sales and marketing activities. In the 87 current set-up, registrars must download these reports from each 88 registry's intranet differently according to each registry's document 89 management set up. 91 This document describes the content of a Transaction Report based on 92 the [I-D.mcpherson-sattler-report-structure] and delivered 93 by the [I-D.mcpherson-sattler-reporting-repository]. 95 2. Terminology and Definitions 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119] when 100 specified in their uppercase forms. 102 2.1. Internationalized Domain Names 104 MUST be as defined in 105 [I-D.mcpherson-sattler-report-structure]. 107 2.2. Dates and Times 109 MUST be as defined in 110 [I-D.mcpherson-sattler-report-structure]. 112 2.3. Character Encoding 114 MUST be as defined in 115 [I-D.mcpherson-sattler-report-structure]. 117 2.4. Currency 119 MUST be as defined in 120 [I-D.mcpherson-sattler-report-structure]. 122 3. Report Headings 124 The first row MUST be the column headings in the following order: 126 SVTRID Server transaction identifier MUST be assigned 127 by and MUST be unique to the server. 129 TLD It MUST contain the top-level domain name formatted 130 according to section 2.1 of this document. 132 DOMAIN It MUST contain the domain name formatted according 133 to section 2.1 of this document. 135 TIMESTAMP It MUST contain the timestamp of the successful 136 transaction formatted according to section 2.2 of 137 this document. 139 TRANSACTIONTYPE It MUST contain the type of the successful 140 transaction according to section 4 of this 141 document. 143 PERIOD It MUST either contain the Period of the successful 144 transaction according to section 5 of this document 145 or MUST be empty if no Period is assigned to the 146 operation. 148 TERM It MUST contain the unit of the Period noted 149 according to section 5 of this document. 151 FEE It MUST contain the fee of the successful 152 transaction according to section 6 of this 153 document. 155 CURRENCY It MUST contain the currency of the successful 156 transaction according to section 2.4 of this 157 document. 159 REGISTRARID It MUST contain the registrar ID of the succesful 160 transaction according to section 7 of this 161 document. 163 DESCRIPTION It MAY contain a free description of the successful 164 transaction. 166 4. Transaction Types 168 Each transaction MUST be assigned to a type. There are Standard 169 Transactions and Non-Standard Transactions. 171 A successful transaction is also a completed transaction. Therefore, 172 transactions MUST NOT be deleted. If a operation MUST be cleared, a 173 corresponding counter transaction MUST be made. 175 4.1. Standard Transaction Types 177 Standard transactions are considered to be CREATE, RENEWAL, 178 AUTORENEW, TRANSFER, TRADE, UPDATE, RESTORE and REGISTRYLOCK. 180 CREATE A successful domain create within the reporting period. 182 RENEWAL A successful explicit domain name renewal executed by 183 the domain name registrar within the reporting period. 185 AUTORENEW A successful domain name auto-renewal by the domain 186 name registry within the reporting period. 188 TRANSFER A successful domain name transfer within the reporting 189 period. 191 TRADE A successful domain name trade within the reporting 192 period. 194 UPDATE A successful billable domain name update within the 195 reporting period. 197 RESTORE A successful domain name restore within the reporting 198 period. 199 This event MUST only include the restore fee. Any 200 additional renewal fee MUST be independently listed. 202 REGISTRYLOCK A successful billable registry lock applied to the 203 domain name within the reporting period. 205 4.2. Non-Standard Transaction Types 207 Non-Standard Transactions MAY be listed in the report and MAY receive 208 a custom type, but it MUST have a corresponding description in the 209 description column. 211 5. Transaction Periods 213 Transaction Types usually occur in Periods of 1 to 10 years, and 214 sometimes there are monthly periods. Therefore, each transaction 215 MUST either have a Period associated or it MUST be empty if no Period 216 is assigned to the operation. 218 The Period format MUST be in the format , where 219 MUST be unsigned and between 1 and 65535, without any 220 leading zero 222 The Term format MUST be in the format and MUST be either 223 'y' for years or 'm' for months. 225 If the number of months results in a full year, then the year MUST be 226 used, e.g. instead of 12,m or 24,m, it should be 1,y respectively 227 2,y. 229 6. Transaction Fees 231 All transactions MUST have a Fee associated. The fee amount, the 232 currency and the period MUST be listed separately. 234 Fees MUST either be whole numbers or rounded to two decimal places. 235 The dividing point is a period (.). 237 6.1. Deviating Fees 239 If a domain name incurs a premium fee, that is not the standard price 240 for the TLD, a description of the price category SHOULD be given. 242 7. Registrar ID 244 A unique registrar ID MUST be listed, with each transaction. Those 245 IDs MUST be according to the IANA registrar IDs 246 (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml) 247 where applicable, otherwise, another unique registrar ID MUST be 248 used. 250 8. Example 252 8.1. Single TLD File Example 253 This is an example of a transaction report for a single top-level 254 domain .example. 256 Filename: example_transactions_2018-11.csv.gz 258 SVTRID,TLD,DOMAIN,TIMESTAMP,TRANSACTIONTYPE,PERIOD,TERM,FEE,CURRENCY, 259 REGISTRARID,DESCRIPTION 260 54321-XYZ,example,nic.example,2018-11-08T08:01:01Z,AUTORENEW,1,y,10, 261 USD,1, 262 54322-XYZ,example,foo.example,2018-11-09T08:00:00Z,CREATE,3,y,10,USD, 263 1, 264 54323-XYZ,example,bar.example,2018-11-09T08:01:01Z,CREATE,1,y,1000, 265 USD,1,PREMIUM A 266 54324-XYZ,example,foobar.example,2018-11-10T07:00:00Z,RESTORE,,,40, 267 USD,1, 268 54325-XYZ,example,foobar.example,2018-11-10T07:00:01Z,RENEWAL,,,10, 269 USD,1, 270 54326-XYZ,example,xn--r8jz45g.example,2018-11-11T06:30:00Z,TRANSFER, 271 1,y,12.75,USD,1, 273 8.2. Multiple TLDs File Example 275 This is an example of a transaction report for multi top-level 276 domains by the example registry. 278 Filename: example_transactions_2018-11.csv.gz 280 SVTRID,TLD,DOMAIN,TIMESTAMP,TRANSACTIONTYPE,PERIOD,TERM,FEE,CURRENCY, 281 REGISTRARID,DESCRIPTION 282 54321-XYZ,example,nic.example,2018-11-08T08:01:01Z,AUTORENEW,1,y,10, 283 USD,1, 284 54322-XYZ,example1,foo.example1,2018-11-09T08:00:00Z,CREATE,6,m,9.90, 285 EUR,1, 286 54323-XYZ,example2,bar.example2,2018-11-09T08:01:01Z,CREATE,1,y,4000, 287 BRL,1,PREMIUM C 288 54324-XYZ,xn--0zwm56d,xn--fsqu00a.xn--0zwm56d,2018-11-10T07:00:00Z, 289 RESTORE,,275,CNY,1, 290 54325-XYZ,xn--0zwm56d,xn--fsqu00a.xn--0zwm56d,2018-11-10T07:00:01Z, 291 RENEWAL,,70,CNY,1, 292 54326-XYZ,xn--zckzah,xn--r8jz45g.xn--zckzah,2018-11-11T06:30:00Z, 293 TRANSFER,1,y,1200,JPY,1, 295 9. IANA Considerations 297 This document has no IANA actions. 299 10. Security Considerations 301 The registry transaction report described in this document does not 302 provide any security services. 304 11. Implementation Status 306 Note to RFC Editor: Please remove this section and the reference to 308 [RFC7942] before publication. 310 This section records the status of known implementations of the 311 protocol defined by this specification at the time of posting of this 312 Internet-Draft, and is based on a proposal described in [RFC7942]. 313 The description of implementations in this section is intended to 314 assist the IETF in its decision processes in progressing drafts to 315 RFCs. Please note that the listing of any individual implementation 316 here does not imply endorsement by the IETF. Furthermore, no effort 317 has been spent to verify the information presented here that was 318 supplied by IETF contributors. This is not intended as, and must not 319 be construed to be, a catalog of available implementations or their 320 features. Readers are advised to note that other implementations may 321 exist. 323 According to [RFC7942], "this will allow reviewers and working groups 324 to assign due consideration to documents that have the benefit of 325 running code, which may serve as evidence of valuable experimentation 326 and feedback that have made the implemented protocols more mature. It 327 is up to the individual working groups to use this information as 328 they see fit". 330 Add implementation details once available. 332 12. References 334 12.1. Normative References 336 [I-D.mcpherson-sattler-report-structure] 337 McPherson, N. and Sattler, T., "Report Strucutre", 338 (work in progress), January 2019 341 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 342 Requirement Levels", BCP 14, RFC 2119, March 1997, 343 . 345 12.2. Informative References 347 [I-D.mcpherson-sattler-reporting-repository] 348 McPherson, N. and Sattler, T., "Reporting Repository", 349 (work in progress), January 2019 352 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 353 Running Code: The Implementation Status Section", RFC 354 7942, July 2016, 355 . 357 Appendix A. Change History 359 A.1. Change from 00 to 01 361 Added acknowledgements. Changed Y to lowercase. Fixed csv examples. 362 Changed security considerations. Added SRTRID to identify 363 transactions. Clarified successful transaction. 365 A.2. Change from 01 to 02 367 Clarified the Period. Fixed numerous typos. Changed limit for Period 368 from 1-99 to unsigned 16 bit integer. 370 A.3. Change from 02 to TXN 00 371 Changed draft name. Added Term column to further clarify Period. 372 Defined Standard Transaction Types. Added Non-Standard Transaction 373 Types. Changed Column order so that DESCRIPTION is at end. 375 A.4. Change from TXN 00 to TXN 01 377 Editorial changes. 379 Appendix B. Acknowledgements 381 The authors wish to thank the following persons for their feedback 382 and suggestions (sorted alphabetically by company): 384 o Jeff Yeh, Brandma 385 o Elaine Pruis, Domain Research 386 o Gaurav Vedi, Dominion Registries 387 o Jody Kolker, GoDaddy 388 o Roger Carney, GoDaddy 390 Authors' Addresses 392 Neal McPherson 393 1&1 IONOS SE 394 Ernst-Frey-Str. 5 395 76135 Karlsruhe 396 DE 398 Email: neal.mcpherson@ionos.com 399 URI: https://www.ionos.com 401 Tobias Sattler 403 Email: tobias.sattler@me.com 404 URI: https://tobiassattler.com