idnits 2.17.1 draft-mcpherson-sattler-registry-reporting-repo-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 1 instance 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 (August 31, 2018) is 2065 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 Internet SE 3 Intended status: Best Current Practice T. Sattler 4 Expires: February 28, 2019 August 31, 2018 6 Registry Reporting Repository 7 draft-mcpherson-sattler-registry-reporting-repo-01 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 February 28, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 49 2.1. Internationalized Domain Names . . . . . . . . . . . . . 3 50 2.2. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 51 3. SFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. SFTP Account . . . . . . . . . . . . . . . . . . . . . . . . 4 53 5. SFTP Directory Structure . . . . . . . . . . . . . . . . . . 4 54 6. SFTP Checksum . . . . . . . . . . . . . . . . . . . . . . . . 4 55 7. SFTP Server Maintenance . . . . . . . . . . . . . . . . . . . 4 56 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 10. Implementation Status . . . . . . . . . . . . . . . . . . . 5 59 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 11.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 6 63 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 6 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 6 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 67 1. Introduction 69 Modern top-level domain registries provide a number of detailed 70 reports and documents that their registrars require on a daily, 71 weekly and monthly basis. These most commonly include transaction 72 reports, as well as lists containing currently unavailable domains 73 and current premium domains. These reports are critical for 74 registrars' businesses and play an important role in accounting and 75 operations processes as well as in sales and marketing activities. 76 In the current set-up registrars must download these reports from 77 each registry's intranet in a different manner according to each 78 registry's own document management set up. 80 This document describes a domain registry reporting repository used 81 to provide reports to accredited domain registrars. 83 2. Terminology and Definitions 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119] when 88 specified in their uppercase forms. 90 2.1. Internationalized Domain Names 92 Top-Level Domains and Domain names contained in a directory or file 93 name MUST be written as A-LABEL according to [RFC5890]. 95 2.2. Dates and Times 97 All dates and times attribute values MUST be expressed in Universal 98 Coordinated Time (UTC) using the Gregorian calendar. The extended 99 date-time form using upper case "T" and "Z" characters defined in ISO 100 8601 [RFC3339] MUST be used to represent date-time values. 102 One day is defined as one day in UTC+0. Therefore, months and years 103 will also be calculated on this basis. 105 3. SFTP Server 107 Each domain name registry sets up and manages a SFTP 108 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 109 Every SFTP server MUST be reachable through a generic URI, such as 110 sftp://registry.example, and MUST listen on port 22. 112 IP whitelisting to reach this SFTP server is RECOMMENDED. 114 4. SFTP Account 116 Each domain name registry MUST create one SFTP account for every 117 accredited domain name registrar. If a registrar owns more than one 118 registrar, then a registry SHOULD combine them in one account on 119 request by the parent registrar or entity. 121 The authentication for a SFTP account should be done with an 122 username and key instead of a password. 124 5. SFTP Directory Structure 126 The home directory of a SFTP user MUST be its root. This can be 127 achieved with e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 128 prevents that a SFTP user can access other directories that are not 129 owned by themselves. All directories MUST be lowercase. 131 Files in these directories MUST be stored in an appropriate 132 subdirectory according to their creation date. 134 /YYYY-MM/example.csv 135 /YYYY-MM/domains/example.csv 136 /YYYY-MM/foo/bar/example.csv 138 YYYY represents the year in which the file was created, format 139 according to ISO 8601 [RFC3339] 141 MM represents the months in which the file was created, format 142 according to ISO 8601 [RFC3339] 144 6. SFTP Checksum 146 All files stored on the SFTP server MUST have a sha256sum 147 (https://en.wikipedia.org/wiki/Sha1sum) checksum. 149 The file name with the checksum MUST be the same as the file name 150 with the content extended with the suffix .sha256. 152 File with content: example.csv 153 File with sha256sum: example.csv.sha256 155 7. SFTP Server Maintenance 157 Maintenance is important and necessary, especially to keep the SFTP 158 server up to date and secure. It MUST be announced in advance. In 159 this case the EPP Registry Maintenance Specification 160 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 161 notification notice MUST be send at least 7 days in advance. 163 8. IANA Considerations 165 This document has no IANA actions. 167 9. Security Considerations 169 The registry reporting repository described in this document do not 170 provide any security services beyond those described by SFTP. The 171 security considerations described in these other specifications apply 172 to this specification as well. 174 10. Implementation Status 176 Note to RFC Editor: Please remove this section and the reference to 177 [RFC7942] before publication. 179 This section records the status of known implementations of the 180 protocol defined by this specification at the time of posting of this 181 Internet-Draft, and is based on a proposal described in [RFC7942]. 182 The description of implementations in this section is intended to 183 assist the IETF in its decision processes in progressing drafts to 184 RFCs. Please note that the listing of any individual implementation 185 here does not imply endorsement by the IETF. Furthermore, no effort 186 has been spent to verify the information presented here that was 187 supplied by IETF contributors. This is not intended as, and must not 188 be construed to be, a catalog of available implementations or their 189 features. Readers are advised to note that other implementations may 190 exist. 192 According to [RFC7942], "this will allow reviewers and working groups 193 to assign due consideration to documents that have the benefit of 194 running code, which may serve as evidence of valuable experimentation 195 and feedback that have made the implemented protocols more mature. It 196 is up to the individual working groups to use this information as 197 they see fit". 199 Add implementation details once available. 201 11. References 203 11.1. Normative References 205 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 206 Requirement Levels", BCP 14, RFC 2119, March 1997, 207 . 209 [RFC5890] Klensin, J., "Internationalized Domain Names for 210 Applications (IDNA): Definitions and Document Framework", 211 RFC 5890, August 2010, 212 . 214 11.2. Informative References 216 [I-D.sattler-epp-registry-maintenance] 217 Sattler, T., Roger, C. and Kolker, J., "Registry 218 Maintenance Notifications for the Extensible Provisioning 219 Protocol (EPP)", (work in progress), July 221 2018 223 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 224 Internet: Timestamps", RFC 3339, July 2002, 225 . 227 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 228 Running Code: The Implementation Status Section", RFC 229 7942, July 2016, 230 . 232 Appendix A. Change History 234 A.1. Change from 00 to 01 236 Added reference to IDN A-LABEL. Added clarification on date 237 delimitation. Added checksum requirement. 239 Appendix B. Acknowledgements 241 The authors wish to thank the following persons for their feedback 242 and suggestions (sorted alphabetically by company): 244 * Thomas Keller, 1&1 Internet 245 * James Galvin, Afilias 246 * Andreas Huber, united-domains 248 Authors' Addresses 250 Neal McPherson 251 1&1 Internet SE 252 Ernst-Frey-Str. 5 253 76135 Karlsruhe 254 DE 256 Email: neal.mcpherson@1und1.de 257 URI: https://www.1und1.de 259 Tobias Sattler 261 Email: tobias.sattler@me.com 262 URI: https://tobiassattler.com