idnits 2.17.1 draft-sattler-contact-inventory-report-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 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 (April 15, 2019) is 1839 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 T. Sattler, Editor 2 Internet-Draft 3 Intended status: Best Current Practice 4 Expires: October 14, 2019 April 15, 2019 6 Contact Inventory Report 7 draft-sattler-contact-inventory-report-02 9 Abstract 11 This document describes the content of a Contact Inventory Report 12 based on the Report Structure and delivered by the Reporting 13 Repository. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 This Internet-Draft will expire on October 14, 2019. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 2 50 2.1. Dates and Times . . . . . . . . . . . . . . . . . . . . . 2 51 3. Report Headings . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Unique ID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 55 7. Security Considerations . . . . . . . . . . . . . . . . . . . 3 56 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 57 8.1. united-domains Reselling . . . . . . . . . . . . . . . . 4 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 60 9.2. Informative References . . . . . . . . . . . . . . . . . 5 61 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 5 62 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 5 63 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 5 64 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Modern top-level domain registries provide many detailed reports and 70 documents that their registrars require on a daily, weekly and 71 monthly basis. These most commonly include transaction reports, as 72 well as lists containing currently unavailable domains and current 73 premium domain fees. These reports are critical for registrars' 74 businesses and play an important role in accounting and operations 75 processes as well as in sales and marketing activities. In the 76 current set-up, registrars must download these reports from each 77 registry's intranet differently according to each registry's document 78 management set up. 80 A contact inventory comparison between the contacts that are on an 81 accreditation/account and the contacts that a registrar/reseller 82 has in its system is therefore useful. 84 This document describes the content of a Contact Inventory Report 85 based on the [I-D.mcpherson-sattler-report-structure] and delivered 86 by the [I-D.mcpherson-sattler-reporting-repository]. 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. Dates and Times 97 MUST be as defined in 98 [I-D.mcpherson-sattler-report-structure]. 100 3. Report Headings 102 The first row MUST be the column headings in the following order: 104 CONTACTID It MUST contain the server-unique identifier of the 105 contact-object. 107 UPDATED It MUST contain the date and time of the most 108 recent contact-object modification. If the contact 109 object has never been modified, then the date and 110 time of contact-object creation have to be used. 111 Formatting in both cases according to section 2.1 112 of this document. 114 INUSE It MUST either be 0 if the contact-object is not 115 linked to a domain-object or 1 if it is bound. 117 ID It MUST contain a unique ID according to section 4 118 of this document. 120 4. Unique ID 122 A unique ID MUST either be according to the IANA registrar IDs 123 (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml) 124 where applicable or another unique registrar or reseller ID MUST be 125 used. 127 5. Example 129 This is an example of a contact inventory report. 131 Filename: contact-inventory_2019-01-01.csv.gz 133 CONTACTID,UPDATED,INUSE,ID 134 sh8013,2018-12-30T07:00:00Z,0,1 135 sh8014,2018-12-30T09:00:15Z,1,1 136 sh8015,2018-12-31T09:03:22Z,1,1 137 sh8016,2018-12-31T10:18:56Z,0,1 139 6. IANA Considerations 141 This document has no IANA actions. 143 7. Security Considerations 145 The contact inventory report described in this document does not 146 provide any security services. 148 8. Implementation Status 150 Note to RFC Editor: Please remove this section and the reference to 151 [RFC7942] before publication. 153 This section records the status of known implementations of the 154 protocol defined by this specification at the time of posting of this 155 Internet-Draft, and is based on a proposal described in [RFC7942]. 156 The description of implementations in this section is intended to 157 assist the IETF in its decision processes in progressing drafts to 158 RFCs. Please note that the listing of any individual implementation 159 here does not imply endorsement by the IETF. Furthermore, no effort 160 has been spent to verify the information presented here that was 161 supplied by IETF contributors. This is not intended as, and must not 162 be construed to be, a catalog of available implementations or their 163 features. Readers are advised to note that other implementations may 164 exist. 166 According to [RFC7942], "this will allow reviewers and working groups 167 to assign due consideration to documents that have the benefit of 168 running code, which may serve as evidence of valuable experimentation 169 and feedback that have made the implemented protocols more mature. It 170 is up to the individual working groups to use this information as 171 they see fit". 173 8.1. united-domains Reselling 175 Organization: united-domains Reselling GmbH 177 Name: Reseller Reporting System 179 Description: Domain Reseller Platform 181 Level of maturity: Deployed in production. 183 Version compatibility: Version 02 is implemented. 185 Coverage: All aspects of this document are implemented. 187 Licensing: Proprietary In-House software 189 Contact: Tim Ettel 191 URL: https://www.ud-reselling.com/en/ 193 9. References 195 9.1. Normative References 197 [I-D.mcpherson-sattler-report-structure] 198 McPherson, N. and Sattler, T., "Report Strucutre", 199 (work in progress), January 2019 202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 203 Requirement Levels", BCP 14, RFC 2119, March 1997, 204 . 206 9.2. Informative References 208 [I-D.mcpherson-sattler-reporting-repository] 209 McPherson, N. and Sattler, T., "Reporting Repository", 210 (work in progress), January 2019 213 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 214 Running Code: The Implementation Status Section", RFC 215 7942, July 2016, 216 . 218 Appendix A. Change History 220 A.1. Change from 00 to 01 222 Editorial changes. 224 A.2. Change from 01 to 02 226 Added implementation reference. Added acknowledgement. 228 Appendix B. Acknowledgements 230 The author wishes to thank the following persons for their feedback 231 and suggestions (sorted alphabetically by company): 233 o Tim Ettel, united-domains 235 Author's Address 237 Tobias Sattler 239 Email: tobias.sattler@me.com 240 URI: https://tobiassattler.com