idnits 2.17.1 draft-mcpherson-sattler-reporting-repository-03.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 (October 15, 2019) is 1654 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: April 15, 2020 October 15, 2019 6 Reporting Repository 7 draft-mcpherson-sattler-reporting-repository-03 9 Abstract 11 This document describes a Reporting Repository used to provide 12 standardized Reports. 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 April 15, 2020. 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 . . . . . . . . . . . . . . . . . 2 49 2.1. Internationalized Domain Names . . . . . . . . . . . . . 3 50 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 51 3. SFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. SFTP Account . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. SFTP Directory Structure . . . . . . . . . . . . . . . . . . 3 54 6. SFTP Checksum . . . . . . . . . . . . . . . . . . . . . . . . 4 55 7. SFTP Server Maintenance . . . . . . . . . . . . . . . . . . . 4 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 4 58 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 59 10.1. united-domains Reselling . . . . . . . . . . . . . . . . 5 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 11.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 6 64 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 6 65 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 6 66 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 6 67 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 6 68 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 6 69 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 6 70 A.7. Change from 06 to REPO 00 . . . . . . . . . . . . . . . . 6 71 A.8. Change from REPO 00 to REPO 01 . . . . . . . . . . . . . 6 72 A.9. Change from REPO 01 to REPO 02 . . . . . . . . . . . . . 7 73 A.10. Change from REPO 02 to REPO 03 . . . . . . . . . . . . . 7 74 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 7 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 Modern top-level domain registries provide many detailed reports and 80 documents that their registrars require on a daily, weekly and 81 monthly basis. These most commonly include transaction reports, as 82 well as lists containing currently unavailable domains and current 83 premium domain fees. These reports are critical for registrars' 84 businesses and play an important role in accounting and operations 85 processes as well as in sales and marketing activities. In the 86 current set-up, registrars must download these reports from each 87 registry's intranet differently according to each registry's document 88 management set up. 90 This document describes a Reporting Repository used to provide 91 standardized Reports. 93 2. Terminology and Definitions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119] when 98 specified in their uppercase forms. 100 2.1. Internationalized Domain Names 102 Top-level domains and domain names contained in a directory or file 103 name MUST be written as A-LABEL according to [RFC5890]. 105 2.2. Dates and Times 107 All dates and times attribute values MUST be expressed in Universal 108 Coordinated Time (UTC) using the Gregorian calendar. The extended 109 date-time form using upper case "T" and "Z" characters defined in ISO 110 8601 [RFC3339] MUST be used to represent date-time values. 112 One day is defined as one day in UTC+0. Therefore, months and years 113 will also be calculated on this basis. 115 3. SFTP Server 117 Each domain name registry sets up and manages an SFTP 118 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 119 Every SFTP server MUST be reachable through a generic URI, such as 120 sftp://registry.example, and MUST listen on port 22. 122 IP whitelisting to reach this SFTP server is RECOMMENDED. 124 4. SFTP Account 126 Each domain name registry MUST create one SFTP account for every 127 accredited domain name registrar. If a registrar owns more than one 128 registrar, then a registry SHOULD combine them in one account on 129 request by the parent registrar or entity. 131 The authentication for an SFTP account should be done with an 132 username and key instead of a password. 134 To avoid security risks, it is strongly RECOMMENDED to limit SFTP 135 accounts to SFTP only and to exclude them from SSH functions, such as 136 port forwarding, tunneling, SSH login or command execution. 138 5. SFTP Directory Structure 140 The home directory of an SFTP user MUST be its root. This can be 141 achieved with, e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 142 prevents that an SFTP user can access other directories that are not 143 owned by themselves. All directories MUST be lowercase. 145 Files in these directories MUST be stored in an appropriate 146 subdirectory according to their creation date. 148 /YYYY-MM/example.csv.gz 149 /YYYY-MM/domains/example.csv.gz 150 /YYYY-MM/foo/bar/example.csv.gz 151 YYYY represents the year in which the file was created, format 152 according to ISO 8601 [RFC3339] 154 MM represents the months in which the file was created, format 155 according to ISO 8601 [RFC3339] 157 6. SFTP Checksum 159 All files stored on the SFTP server MUST have a sha256sum 160 (https://en.wikipedia.org/wiki/Sha1sum) checksum. 162 The file name with the checksum MUST be the same as the file name 163 with the content extended with the suffix .sha256. 165 File with content: example.csv.gz 166 File with sha256sum: example.csv.gz.sha256 168 7. SFTP Server Maintenance 170 Maintenance is important and necessary, mainly to keep the SFTP 171 server up to date and secure. It MUST be announced in advance. In 172 this case the EPP registry maintenance specification 173 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 174 notification notice MUST be sent at least 7 days in advance. 176 8. IANA Considerations 178 This document has no IANA actions. 180 9. Security Considerations 182 The registry reporting repository described in this document does not 183 provide any security services beyond those specified by SFTP. The 184 security considerations described in these other specifications apply 185 to this specification as well. 187 10. Implementation Status 189 Note to RFC Editor: Please remove this section and the reference to 190 [RFC7942] before publication. 192 This section records the status of known implementations of the 193 protocol defined by this specification at the time of posting of this 194 Internet-Draft, and is based on a proposal described in [RFC7942]. 195 The description of implementations in this section is intended to 196 assist the IETF in its decision processes in progressing drafts to 197 RFCs. Please note that the listing of any individual implementation 198 here does not imply endorsement by the IETF. Furthermore, no effort 199 has been spent to verify the information presented here that was 200 supplied by IETF contributors. This is not intended as, and must not 201 be construed to be, a catalog of available implementations or their 202 features. Readers are advised to note that other implementations may 203 exist. 205 According to [RFC7942], "this will allow reviewers and working groups 206 to assign due consideration to documents that have the benefit of 207 running code, which may serve as evidence of valuable experimentation 208 and feedback that have made the implemented protocols more mature. It 209 is up to the individual working groups to use this information as 210 they see fit". 212 10.1. united-domains Reselling 214 Organization: united-domains Reselling GmbH 216 Name: Reseller Reporting System 218 Description: Domain Reseller Platform 220 Level of maturity: Deployed in production. 222 Version compatibility: Version REPO 01 is implemented. 224 Coverage: All aspects of this document are implemented. 226 Licensing: Proprietary In-House software 228 Contact: Tim Ettel 230 URL: https://www.ud-reselling.com/en/ 232 11. References 234 11.1. Normative References 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997, 238 . 240 [RFC5890] Klensin, J., "Internationalized Domain Names for 241 Applications (IDNA): Definitions and Document Framework", 242 RFC 5890, August 2010, 243 . 245 11.2. Informative References 247 [I-D.sattler-epp-registry-maintenance] 248 Sattler, T., Roger, C. and Kolker, J., "Registry 249 Maintenance Notifications for the Extensible Provisioning 250 Protocol (EPP)", (work in progress), July 252 2018 254 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 255 Internet: Timestamps", RFC 3339, July 2002, 256 . 258 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 259 Running Code: The Implementation Status Section", RFC 260 7942, July 2016, 261 . 263 Appendix A. Change History 265 A.1. Change from 00 to 01 267 Added reference to IDN A-LABEL. Added clarification on date 268 delimitation. Added checksum requirement. 270 A.2. Change from 01 to 02 272 Updated Neal's author details. 274 A.3. Change from 02 to 03 276 Fixed formatting of the table of contents. 278 A.4. Change from 03 to 04 280 Added editor flag to author. 282 A.5. Change from 04 to 05 284 Minor formatting changes. Added security advice to SFTP. 286 A.6. Change from 05 to 06 288 Changed examples to reflect compressed files. 290 A.7. Change from 06 to REPO 00 292 Changed draft name. 294 A.8. Change from REPO 00 to REPO 01 296 Added implementation reference and acknowledgement. Editorial 297 changes. 299 A.9. Change from REPO 01 to REPO 02 301 Changed implementation reference. 303 A.10. Change from REPO 02 to REPO 03 305 Editorial changes. 307 Appendix B. Acknowledgements 309 The authors wish to thank the following persons for their feedback 310 and suggestions (sorted alphabetically by company): 312 o Anders Henke, 1&1 IONOS 313 o Thomas Keller, 1&1 IONOS 314 o James Galvin, Afilias 315 o Tim Ettel, united-domains 316 o Andreas Huber, united-domains 318 Authors' Addresses 320 Neal McPherson 321 1&1 IONOS SE 322 Ernst-Frey-Str. 5 323 76135 Karlsruhe 324 DE 326 Email: neal.mcpherson@ionos.com 327 URI: https://www.ionos.com 329 Tobias Sattler 331 Email: tobias.sattler@me.com 332 URI: https://tobiassattler.com