idnits 2.17.1 draft-mcpherson-sattler-registry-reporting-repo-06.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 (November 25, 2018) is 1978 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: May 24, 2019 November 25, 2018 6 Registry Reporting Repository 7 draft-mcpherson-sattler-registry-reporting-repo-06 9 Abstract 11 This document describes a domain name registry reporting repository 12 used to provide reports to accredited domain name registrars. 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 May 24, 2019. 31 Copyright Notice 33 Copyright (c) 2018 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 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 72 1. Introduction 74 Modern top-level domain registries provide a number of detailed 75 reports and documents that their registrars require on a daily, 76 weekly and monthly basis. These most commonly include transaction 77 reports, as well as lists containing currently unavailable domains 78 and current premium domains. These reports are critical for 79 registrars' businesses and play an important role in accounting and 80 operations processes as well as in sales and marketing activities. 81 In the current set-up registrars must download these reports from 82 each registry's intranet in a different manner according to each 83 registry's own document management set up. 85 This document describes a domain registry reporting repository used 86 to provide reports to accredited domain registrars. 88 2. Terminology and Definitions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119] when 93 specified in their uppercase forms. 95 2.1. Internationalized Domain Names 97 Top-level domains and domain names contained in a directory or file 98 name MUST be written as A-LABEL according to [RFC5890]. 100 2.2. Dates and Times 102 All dates and times attribute values MUST be expressed in Universal 103 Coordinated Time (UTC) using the Gregorian calendar. The extended 104 date-time form using upper case "T" and "Z" characters defined in ISO 105 8601 [RFC3339] MUST be used to represent date-time values. 107 One day is defined as one day in UTC+0. Therefore, months and years 108 will also be calculated on this basis. 110 3. SFTP Server 112 Each domain name registry sets up and manages a SFTP 113 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 114 Every SFTP server MUST be reachable through a generic URI, such as 115 sftp://registry.example, and MUST listen on port 22. 117 IP whitelisting to reach this SFTP server is RECOMMENDED. 119 4. SFTP Account 121 Each domain name registry MUST create one SFTP account for every 122 accredited domain name registrar. If a registrar owns more than one 123 registrar, then a registry SHOULD combine them in one account on 124 request by the parent registrar or entity. 126 The authentication for a SFTP account should be done with an 127 username and key instead of a password. 129 To avoid security risks, it is strongly RECOMMENDED to limit SFTP 130 accounts to SFTP only and to exclude them from SSH functions, such as 131 port forwarding, tunneling, SSH login or command execution. 133 5. SFTP Directory Structure 135 The home directory of a SFTP user MUST be its root. This can be 136 achieved with e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 137 prevents that a SFTP user can access other directories that are not 138 owned by themselves. All directories MUST be lowercase. 140 Files in these directories MUST be stored in an appropriate 141 subdirectory according to their creation date. 143 /YYYY-MM/example.csv.gz 144 /YYYY-MM/domains/example.csv.gz 145 /YYYY-MM/foo/bar/example.csv.gz 146 YYYY represents the year in which the file was created, format 147 according to ISO 8601 [RFC3339] 149 MM represents the months in which the file was created, format 150 according to ISO 8601 [RFC3339] 152 6. SFTP Checksum 154 All files stored on the SFTP server MUST have a sha256sum 155 (https://en.wikipedia.org/wiki/Sha1sum) checksum. 157 The file name with the checksum MUST be the same as the file name 158 with the content extended with the suffix .sha256. 160 File with content: example.csv.gz 161 File with sha256sum: example.csv.gz.sha256 163 7. SFTP Server Maintenance 165 Maintenance is important and necessary, especially to keep the SFTP 166 server up to date and secure. It MUST be announced in advance. In 167 this case the EPP registry maintenance specification 168 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 169 notification notice MUST be send at least 7 days in advance. 171 8. IANA Considerations 173 This document has no IANA actions. 175 9. Security Considerations 177 The registry reporting repository described in this document do not 178 provide any security services beyond those described by SFTP. The 179 security considerations described in these other specifications apply 180 to this specification as well. 182 10. Implementation Status 184 Note to RFC Editor: Please remove this section and the reference to 185 [RFC7942] before publication. 187 This section records the status of known implementations of the 188 protocol defined by this specification at the time of posting of this 189 Internet-Draft, and is based on a proposal described in [RFC7942]. 190 The description of implementations in this section is intended to 191 assist the IETF in its decision processes in progressing drafts to 192 RFCs. Please note that the listing of any individual implementation 193 here does not imply endorsement by the IETF. Furthermore, no effort 194 has been spent to verify the information presented here that was 195 supplied by IETF contributors. This is not intended as, and must not 196 be construed to be, a catalog of available implementations or their 197 features. Readers are advised to note that other implementations may 198 exist. 200 According to [RFC7942], "this will allow reviewers and working groups 201 to assign due consideration to documents that have the benefit of 202 running code, which may serve as evidence of valuable experimentation 203 and feedback that have made the implemented protocols more mature. It 204 is up to the individual working groups to use this information as 205 they see fit". 207 Add implementation details once available. 209 11. References 211 11.1. Normative References 213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 214 Requirement Levels", BCP 14, RFC 2119, March 1997, 215 . 217 [RFC5890] Klensin, J., "Internationalized Domain Names for 218 Applications (IDNA): Definitions and Document Framework", 219 RFC 5890, August 2010, 220 . 222 11.2. Informative References 224 [I-D.sattler-epp-registry-maintenance] 225 Sattler, T., Roger, C. and Kolker, J., "Registry 226 Maintenance Notifications for the Extensible Provisioning 227 Protocol (EPP)", (work in progress), July 229 2018 231 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 232 Internet: Timestamps", RFC 3339, July 2002, 233 . 235 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 236 Running Code: The Implementation Status Section", RFC 237 7942, July 2016, 238 . 240 Appendix A. Change History 242 A.1. Change from 00 to 01 244 Added reference to IDN A-LABEL. Added clarification on date 245 delimitation. Added checksum requirement. 247 A.2. Change from 01 to 02 249 Updated Neal's author details. 251 A.3. Change from 02 to 03 253 Fixed formatting of the table of contents. 255 A.4. Change from 03 to 04 257 Added editor flag to author. 259 A.4. Change from 04 to 05 261 Minor formatting changes. Added security advice to SFTP. 263 A.5. Change from 05 to 06 265 Changed examples to reflect compressed files. 267 Appendix B. Acknowledgements 269 The authors wish to thank the following persons for their feedback 270 and suggestions (sorted alphabetically by company): 272 o Anders Henke, 1&1 IONOS 273 o Thomas Keller, 1&1 IONOS 274 o James Galvin, Afilias 275 o Andreas Huber, united-domains 277 Authors' Addresses 279 Neal McPherson 280 1&1 IONOS SE 281 Ernst-Frey-Str. 5 282 76135 Karlsruhe 283 DE 285 Email: neal.mcpherson@ionos.com 286 URI: https://www.ionos.com 288 Tobias Sattler 290 Email: tobias.sattler@me.com 291 URI: https://tobiassattler.com