idnits 2.17.1 draft-mcpherson-sattler-reporting-repository-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 (April 15, 2019) is 1837 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: October 14, 2019 April 15, 2019 6 Reporting Repository 7 draft-mcpherson-sattler-reporting-repository-02 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 October 14, 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 . . . . . . . . . . . . . . . . . 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 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 76 1. Introduction 78 Modern top-level domain registries provide many detailed reports and 79 documents that their registrars require on a daily, weekly and 80 monthly basis. These most commonly include transaction reports, as 81 well as lists containing currently unavailable domains and current 82 premium domain fees. These reports are critical for registrars' 83 businesses and play an important role in accounting and operations 84 processes as well as in sales and marketing activities. In the 85 current set-up, registrars must download these reports from each 86 registry's intranet differently according to each registry's document 87 management set up. 89 This document describes a Reporting Repository used to provide 90 standardized Reports. 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 Top-level domains and domain names contained in a directory or file 102 name MUST be written as A-LABEL according to [RFC5890]. 104 2.2. Dates and Times 106 All dates and times attribute values MUST be expressed in Universal 107 Coordinated Time (UTC) using the Gregorian calendar. The extended 108 date-time form using upper case "T" and "Z" characters defined in ISO 109 8601 [RFC3339] MUST be used to represent date-time values. 111 One day is defined as one day in UTC+0. Therefore, months and years 112 will also be calculated on this basis. 114 3. SFTP Server 116 Each domain name registry sets up and manages an SFTP 117 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 118 Every SFTP server MUST be reachable through a generic URI, such as 119 sftp://registry.example, and MUST listen on port 22. 121 IP whitelisting to reach this SFTP server is RECOMMENDED. 123 4. SFTP Account 125 Each domain name registry MUST create one SFTP account for every 126 accredited domain name registrar. If a registrar owns more than one 127 registrar, then a registry SHOULD combine them in one account on 128 request by the parent registrar or entity. 130 The authentication for an SFTP account should be done with an 131 username and key instead of a password. 133 To avoid security risks, it is strongly RECOMMENDED to limit SFTP 134 accounts to SFTP only and to exclude them from SSH functions, such as 135 port forwarding, tunneling, SSH login or command execution. 137 5. SFTP Directory Structure 139 The home directory of an SFTP user MUST be its root. This can be 140 achieved with, e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 141 prevents that an SFTP user can access other directories that are not 142 owned by themselves. All directories MUST be lowercase. 144 Files in these directories MUST be stored in an appropriate 145 subdirectory according to their creation date. 147 /YYYY-MM/example.csv.gz 148 /YYYY-MM/domains/example.csv.gz 149 /YYYY-MM/foo/bar/example.csv.gz 150 YYYY represents the year in which the file was created, format 151 according to ISO 8601 [RFC3339] 153 MM represents the months in which the file was created, format 154 according to ISO 8601 [RFC3339] 156 6. SFTP Checksum 158 All files stored on the SFTP server MUST have a sha256sum 159 (https://en.wikipedia.org/wiki/Sha1sum) checksum. 161 The file name with the checksum MUST be the same as the file name 162 with the content extended with the suffix .sha256. 164 File with content: example.csv.gz 165 File with sha256sum: example.csv.gz.sha256 167 7. SFTP Server Maintenance 169 Maintenance is important and necessary, mainly to keep the SFTP 170 server up to date and secure. It MUST be announced in advance. In 171 this case the EPP registry maintenance specification 172 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 173 notification notice MUST be sent at least 7 days in advance. 175 8. IANA Considerations 177 This document has no IANA actions. 179 9. Security Considerations 181 The registry reporting repository described in this document does not 182 provide any security services beyond those specified by SFTP. The 183 security considerations described in these other specifications apply 184 to this specification as well. 186 10. Implementation Status 188 Note to RFC Editor: Please remove this section and the reference to 189 [RFC7942] before publication. 191 This section records the status of known implementations of the 192 protocol defined by this specification at the time of posting of this 193 Internet-Draft, and is based on a proposal described in [RFC7942]. 194 The description of implementations in this section is intended to 195 assist the IETF in its decision processes in progressing drafts to 196 RFCs. Please note that the listing of any individual implementation 197 here does not imply endorsement by the IETF. Furthermore, no effort 198 has been spent to verify the information presented here that was 199 supplied by IETF contributors. This is not intended as, and must not 200 be construed to be, a catalog of available implementations or their 201 features. Readers are advised to note that other implementations may 202 exist. 204 According to [RFC7942], "this will allow reviewers and working groups 205 to assign due consideration to documents that have the benefit of 206 running code, which may serve as evidence of valuable experimentation 207 and feedback that have made the implemented protocols more mature. It 208 is up to the individual working groups to use this information as 209 they see fit". 211 10.1. united-domains Reselling 213 Organization: united-domains Reselling GmbH 215 Name: Reseller Reporting System 217 Description: Domain Reseller Platform 219 Level of maturity: Deployed in production. 221 Version compatibility: Version REPO 01 is implemented. 223 Coverage: All aspects of this document are implemented. 225 Licensing: Proprietary In-House software 227 Contact: Tim Ettel 229 URL: https://www.ud-reselling.com/en/ 231 11. References 233 11.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997, 237 . 239 [RFC5890] Klensin, J., "Internationalized Domain Names for 240 Applications (IDNA): Definitions and Document Framework", 241 RFC 5890, August 2010, 242 . 244 11.2. Informative References 246 [I-D.sattler-epp-registry-maintenance] 247 Sattler, T., Roger, C. and Kolker, J., "Registry 248 Maintenance Notifications for the Extensible Provisioning 249 Protocol (EPP)", (work in progress), July 251 2018 253 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 254 Internet: Timestamps", RFC 3339, July 2002, 255 . 257 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 258 Running Code: The Implementation Status Section", RFC 259 7942, July 2016, 260 . 262 Appendix A. Change History 264 A.1. Change from 00 to 01 266 Added reference to IDN A-LABEL. Added clarification on date 267 delimitation. Added checksum requirement. 269 A.2. Change from 01 to 02 271 Updated Neal's author details. 273 A.3. Change from 02 to 03 275 Fixed formatting of the table of contents. 277 A.4. Change from 03 to 04 279 Added editor flag to author. 281 A.5. Change from 04 to 05 283 Minor formatting changes. Added security advice to SFTP. 285 A.6. Change from 05 to 06 287 Changed examples to reflect compressed files. 289 A.7. Change from 06 to REPO 00 291 Changed draft name. 293 A.8. Change from REPO 00 to REPO 01 295 Added implementation reference and acknowledgement. Editorial 296 changes. 298 A.9. Change from REPO 01 to REPO 02 300 Changed implementation reference. 302 Appendix B. Acknowledgements 304 The authors wish to thank the following persons for their feedback 305 and suggestions (sorted alphabetically by company): 307 o Anders Henke, 1&1 IONOS 308 o Thomas Keller, 1&1 IONOS 309 o James Galvin, Afilias 310 o Tim Ettel, united-domains 311 o Andreas Huber, united-domains 313 Authors' Addresses 315 Neal McPherson 316 1&1 IONOS SE 317 Ernst-Frey-Str. 5 318 76135 Karlsruhe 319 DE 321 Email: neal.mcpherson@ionos.com 322 URI: https://www.ionos.com 324 Tobias Sattler 326 Email: tobias.sattler@me.com 327 URI: https://tobiassattler.com