idnits 2.17.1 draft-mcpherson-sattler-reporting-repository-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 : ---------------------------------------------------------------------------- == 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 (January 29, 2019) is 1914 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: July 28, 2019 January 29, 2019 6 Reporting Repository 7 draft-mcpherson-sattler-reporting-repository-00 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 July 28, 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 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 11.2. Informative References . . . . . . . . . . . . . . . . . 5 62 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 5 63 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 5 64 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 5 65 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 5 66 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 6 67 A.5. Change from 04 to 05 . . . . . . . . . . . . . . . . . . 6 68 A.6. Change from 05 to 06 . . . . . . . . . . . . . . . . . . 6 69 A.7. Change from 06 to REPO 00 . . . . . . . . . . . . . . . . 6 70 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 6 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 Modern top-level domain registries provide a number of detailed 76 reports and documents that their registrars require on a daily, 77 weekly and monthly basis. These most commonly include transaction 78 reports, as well as lists containing currently unavailable domains 79 and current premium domain fees. These reports are critical for 80 registrars' businesses and play an important role in accounting and 81 operations processes as well as in sales and marketing activities. 82 In the current set-up registrars must download these reports from 83 each registry's intranet in a different manner according to each 84 registry's own document management set up. 86 This document describes a Reporting Repository used to provide 87 standardized Reports. 89 2. Terminology and Definitions 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119] when 94 specified in their uppercase forms. 96 2.1. Internationalized Domain Names 98 Top-level domains and domain names contained in a directory or file 99 name MUST be written as A-LABEL according to [RFC5890]. 101 2.2. Dates and Times 103 All dates and times attribute values MUST be expressed in Universal 104 Coordinated Time (UTC) using the Gregorian calendar. The extended 105 date-time form using upper case "T" and "Z" characters defined in ISO 106 8601 [RFC3339] MUST be used to represent date-time values. 108 One day is defined as one day in UTC+0. Therefore, months and years 109 will also be calculated on this basis. 111 3. SFTP Server 113 Each domain name registry sets up and manages a SFTP 114 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 115 Every SFTP server MUST be reachable through a generic URI, such as 116 sftp://registry.example, and MUST listen on port 22. 118 IP whitelisting to reach this SFTP server is RECOMMENDED. 120 4. SFTP Account 122 Each domain name registry MUST create one SFTP account for every 123 accredited domain name registrar. If a registrar owns more than one 124 registrar, then a registry SHOULD combine them in one account on 125 request by the parent registrar or entity. 127 The authentication for a SFTP account should be done with an 128 username and key instead of a password. 130 To avoid security risks, it is strongly RECOMMENDED to limit SFTP 131 accounts to SFTP only and to exclude them from SSH functions, such as 132 port forwarding, tunneling, SSH login or command execution. 134 5. SFTP Directory Structure 136 The home directory of a SFTP user MUST be its root. This can be 137 achieved with e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 138 prevents that a SFTP user can access other directories that are not 139 owned by themselves. All directories MUST be lowercase. 141 Files in these directories MUST be stored in an appropriate 142 subdirectory according to their creation date. 144 /YYYY-MM/example.csv.gz 145 /YYYY-MM/domains/example.csv.gz 146 /YYYY-MM/foo/bar/example.csv.gz 147 YYYY represents the year in which the file was created, format 148 according to ISO 8601 [RFC3339] 150 MM represents the months in which the file was created, format 151 according to ISO 8601 [RFC3339] 153 6. SFTP Checksum 155 All files stored on the SFTP server MUST have a sha256sum 156 (https://en.wikipedia.org/wiki/Sha1sum) checksum. 158 The file name with the checksum MUST be the same as the file name 159 with the content extended with the suffix .sha256. 161 File with content: example.csv.gz 162 File with sha256sum: example.csv.gz.sha256 164 7. SFTP Server Maintenance 166 Maintenance is important and necessary, especially to keep the SFTP 167 server up to date and secure. It MUST be announced in advance. In 168 this case the EPP registry maintenance specification 169 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 170 notification notice MUST be send at least 7 days in advance. 172 8. IANA Considerations 174 This document has no IANA actions. 176 9. Security Considerations 178 The registry reporting repository described in this document do not 179 provide any security services beyond those described by SFTP. The 180 security considerations described in these other specifications apply 181 to this specification as well. 183 10. Implementation Status 185 Note to RFC Editor: Please remove this section and the reference to 186 [RFC7942] before publication. 188 This section records the status of known implementations of the 189 protocol defined by this specification at the time of posting of this 190 Internet-Draft, and is based on a proposal described in [RFC7942]. 191 The description of implementations in this section is intended to 192 assist the IETF in its decision processes in progressing drafts to 193 RFCs. Please note that the listing of any individual implementation 194 here does not imply endorsement by the IETF. Furthermore, no effort 195 has been spent to verify the information presented here that was 196 supplied by IETF contributors. This is not intended as, and must not 197 be construed to be, a catalog of available implementations or their 198 features. Readers are advised to note that other implementations may 199 exist. 201 According to [RFC7942], "this will allow reviewers and working groups 202 to assign due consideration to documents that have the benefit of 203 running code, which may serve as evidence of valuable experimentation 204 and feedback that have made the implemented protocols more mature. It 205 is up to the individual working groups to use this information as 206 they see fit". 208 Add implementation details once available. 210 11. References 212 11.1. Normative References 214 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 215 Requirement Levels", BCP 14, RFC 2119, March 1997, 216 . 218 [RFC5890] Klensin, J., "Internationalized Domain Names for 219 Applications (IDNA): Definitions and Document Framework", 220 RFC 5890, August 2010, 221 . 223 11.2. Informative References 225 [I-D.sattler-epp-registry-maintenance] 226 Sattler, T., Roger, C. and Kolker, J., "Registry 227 Maintenance Notifications for the Extensible Provisioning 228 Protocol (EPP)", (work in progress), July 230 2018 232 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 233 Internet: Timestamps", RFC 3339, July 2002, 234 . 236 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 237 Running Code: The Implementation Status Section", RFC 238 7942, July 2016, 239 . 241 Appendix A. Change History 243 A.1. Change from 00 to 01 245 Added reference to IDN A-LABEL. Added clarification on date 246 delimitation. Added checksum requirement. 248 A.2. Change from 01 to 02 250 Updated Neal's author details. 252 A.3. Change from 02 to 03 254 Fixed formatting of the table of contents. 256 A.4. Change from 03 to 04 258 Added editor flag to author. 260 A.5. Change from 04 to 05 262 Minor formatting changes. Added security advice to SFTP. 264 A.6. Change from 05 to 06 266 Changed examples to reflect compressed files. 268 A.7. Change from 06 to REPO 00 270 Changed draft name. 272 Appendix B. Acknowledgements 274 The authors wish to thank the following persons for their feedback 275 and suggestions (sorted alphabetically by company): 277 o Anders Henke, 1&1 IONOS 278 o Thomas Keller, 1&1 IONOS 279 o James Galvin, Afilias 280 o Andreas Huber, united-domains 282 Authors' Addresses 284 Neal McPherson 285 1&1 IONOS SE 286 Ernst-Frey-Str. 5 287 76135 Karlsruhe 288 DE 290 Email: neal.mcpherson@ionos.com 291 URI: https://www.ionos.com 293 Tobias Sattler 295 Email: tobias.sattler@me.com 296 URI: https://tobiassattler.com