idnits 2.17.1 draft-mcpherson-sattler-registry-reporting-repo-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 25, 2018) is 2100 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 (~~), 1 warning (==), 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: January 24, 2019 July 25, 2018 6 Registry Reporting Repository 7 draft-mcpherson-sattler-registry-reporting-repo-00 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 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 3 49 3. SFTP Server . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 4. SFTP Account . . . . . . . . . . . . . . . . . . . . . . . . 3 51 5. SFTP Directory Structure . . . .. . . . . . . . . . . . . . . 4 52 6. SFTP Server Maintenance . . . . . . . . . . . . . . . . . . 4 53 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 4 55 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 56 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 10.1. Normative References . . . . . . . . . . . . . . . . . . 5 58 10.2. Informative References . . . . . . . . . . . . . . . . . 6 59 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 6 60 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 63 1. Introduction 65 Modern top-level domain registries provide a number of detailed 66 reports and documents that their registrars require on a daily, 67 weekly and monthly basis. These most commonly include transaction 68 reports, as well as lists containing currently unavailable domains 69 and current premium domains. These reports are critical for 70 registrars' businesses and play an important role in accounting and 71 operations processes as well as in sales and marketing activities. 72 In the current set-up registrars must download these reports from 73 each registry's intranet in a different manner according to each 74 registry's own document management set up. 76 This document describes a domain registry reporting repository used 77 to provide reports to accredited domain registrars. 79 2. Terminology and Definitions 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119] when 84 specified in their uppercase forms. 86 3. SFTP Server 88 Each domain name registry sets up and manages a SFTP 89 (https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol) server. 90 Every SFTP server MUST be reachable through a generic URI, such as 91 sftp://registry.example, and MUST listen on port 22. 93 IP whitelisting to reach this SFTP server is RECOMMENDED. 95 4. SFTP Account 97 Each domain name registry MUST create one SFTP account for every 98 accredited domain name registrar. If a registrar owns more than one 99 registrar, then a registry SHOULD combine them in one account on 100 request by the parent registrar or entity. 102 The authentication for a SFTP account should be done with an 103 username and key instead of a password. 105 5. SFTP Directory Structure 107 The home directory of a SFTP user MUST be its root. This can be 108 achieved with e.g. chroot (https://en.wikipedia.org/wiki/Chroot) and 109 prevents that a SFTP user can access other directories that are not 110 owned by themselves. All directories MUST be lowercase. 112 Files in these directories MUST be stored in an appropriate 113 subdirectory according to their creation date. 115 /YYYY-MM/foo.example 116 /YYYY-MM/domains/foo.example 117 /YYYY-MM/foo/bar/example 119 YYYY represents the year in which the file was created, format 120 according to ISO 8601 [RFC3339] 122 MM represents the months in which the file was created, format 123 according to ISO 8601 [RFC3339] 125 6. SFTP Server Maintenance 127 Maintenance is important and necessary, especially to keep the SFTP 128 server up to date and secure. It MUST be announced in advance. In 129 this case the EPP Registry Maintenance Specification 130 [I-D.sattler-epp-registry-maintenance] is RECOMMENDED to use. The 131 notification notice MUST be send at least 7 days in advance. 133 7. IANA Considerations 135 This document has no IANA actions. 137 8. Security Considerations 139 The registry reporting repository described in this document do not 140 provide any security services beyond those described by SFTP. The 141 security considerations described in these other specifications apply 142 to this specification as well. 144 9. Implementation Status 146 Note to RFC Editor: Please remove this section and the reference to 147 [RFC7942] before publication. 149 This section records the status of known implementations of the 150 protocol defined by this specification at the time of posting of this 151 Internet-Draft, and is based on a proposal described in [RFC7942]. 152 The description of implementations in this section is intended to 153 assist the IETF in its decision processes in progressing drafts to 154 RFCs. Please note that the listing of any individual implementation 155 here does not imply endorsement by the IETF. Furthermore, no effort 156 has been spent to verify the information presented here that was 157 supplied by IETF contributors. This is not intended as, and must not 158 be construed to be, a catalog of available implementations or their 159 features. Readers are advised to note that other implementations may 160 exist. 162 According to [RFC7942], "this will allow reviewers and working groups 163 to assign due consideration to documents that have the benefit of 164 running code, which may serve as evidence of valuable experimentation 165 and feedback that have made the implemented protocols more mature. It 166 is up to the individual working groups to use this information as 167 they see fit". 169 Add implementation details once available. 171 10. References 173 10.1. Normative References 175 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 176 Requirement Levels", BCP 14, RFC 2119, March 1997, 177 . 179 10.2. Informative References 181 [I-D.sattler-epp-registry-maintenance] 182 Sattler, T., Roger, C. and Kolker, J., "Registry 183 Maintenance Notifications for the Extensible Provisioning 184 Protocol (EPP)", (work in progress), July 186 2018 188 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 189 Internet: Timestamps", RFC 3339, July 2002, 190 . 192 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 193 Running Code: The Implementation Status Section", RFC 194 7942, July 2016, 195 . 197 Appendix A. Change History 199 TBD 201 Appendix B. Acknowledgements 203 The authors wish to thank the following persons for their feedback 204 and suggestions (sorted alphabetically by company): 206 * Thomas Keller, 1&1 Internet 207 * James Galvin, Afilias 208 * Andreas Huber, united-domains 210 Authors' Addresses 212 Neal McPherson 213 1&1 Internet SE 214 Ernst-Frey-Str. 5 215 76135 Karlsruhe 216 DE 218 Email: neal.mcpherson@1und1.de 219 URI: https://www.1und1.de 221 Tobias Sattler 223 Email: tobias.sattler@me.com 224 URI: https://tobiassattler.com