idnits 2.17.1 draft-sattler-contact-inventory-report-03.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 (October 15, 2019) is 1652 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: April 15, 2020 October 15, 2019 6 Contact Inventory Report 7 draft-sattler-contact-inventory-report-03 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 December 18, 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 3. Report Headings . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Unique ID . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 3 55 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 4 56 8.1. united-domains Reselling . . . . . . . . . . . . . . . . 4 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 9.1. Normative References . . . . . . . . . . . . . . . . . . 5 59 9.2. Informative References . . . . . . . . . . . . . . . . . 5 60 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 5 61 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 5 62 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 5 63 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 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 3. Report Headings 97 The first row MUST be the column headings in the following order: 99 CONTACTID It MUST contain the server-unique identifier of the 100 contact-object. 102 UPDATED It MUST contain the date and time of the most 103 recent contact-object modification. If the contact 104 object has never been modified, then the date and 105 time of contact-object creation have to be used. 106 Formatting in both cases according to section 2.1 107 of this document. 109 INUSE It MUST either be 0 if the contact-object is not 110 linked to a domain-object or 1 if it is bound. 112 ID It MUST contain a unique ID according to section 4 113 of this document. 115 4. Unique ID 117 A unique ID MUST either be according to the IANA registrar IDs 118 (https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml) 119 where applicable or another unique registrar or reseller ID MUST be 120 used. 122 5. Example 124 This is an example of a contact inventory report. 126 Filename: contact-inventory_2019-01-01.csv.gz 128 CONTACTID,UPDATED,INUSE,ID 129 sh8013,2018-12-30T07:00:00Z,0,1 130 sh8014,2018-12-30T09:00:15Z,1,1 131 sh8015,2018-12-31T09:03:22Z,1,1 132 sh8016,2018-12-31T10:18:56Z,0,1 134 6. IANA Considerations 136 This document has no IANA actions. 138 7. Security Considerations 140 The contact inventory report described in this document does not 141 provide any security services. 143 8. Implementation Status 145 Note to RFC Editor: Please remove this section and the reference to 146 [RFC7942] before publication. 148 This section records the status of known implementations of the 149 protocol defined by this specification at the time of posting of this 150 Internet-Draft, and is based on a proposal described in [RFC7942]. 151 The description of implementations in this section is intended to 152 assist the IETF in its decision processes in progressing drafts to 153 RFCs. Please note that the listing of any individual implementation 154 here does not imply endorsement by the IETF. Furthermore, no effort 155 has been spent to verify the information presented here that was 156 supplied by IETF contributors. This is not intended as, and must not 157 be construed to be, a catalog of available implementations or their 158 features. Readers are advised to note that other implementations may 159 exist. 161 According to [RFC7942], "this will allow reviewers and working groups 162 to assign due consideration to documents that have the benefit of 163 running code, which may serve as evidence of valuable experimentation 164 and feedback that have made the implemented protocols more mature. It 165 is up to the individual working groups to use this information as 166 they see fit". 168 8.1. united-domains Reselling 170 Organization: united-domains Reselling GmbH 172 Name: Reseller Reporting System 174 Description: Domain Reseller Platform 176 Level of maturity: Deployed in production. 178 Version compatibility: Version 02 is implemented. 180 Coverage: All aspects of this document are implemented. 182 Licensing: Proprietary In-House software 184 Contact: Tim Ettel 186 URL: https://www.ud-reselling.com/en/ 188 9. References 190 9.1. Normative References 192 [I-D.mcpherson-sattler-report-structure] 193 McPherson, N. and Sattler, T., "Report Strucutre", 194 (work in progress), January 2019 197 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 198 Requirement Levels", BCP 14, RFC 2119, March 1997, 199 . 201 9.2. Informative References 203 [I-D.mcpherson-sattler-reporting-repository] 204 McPherson, N. and Sattler, T., "Reporting Repository", 205 (work in progress), January 2019 208 [RFC7942] Sheffer, Y. and Farrel, A., "Improving Awareness of 209 Running Code: The Implementation Status Section", RFC 210 7942, July 2016, 211 . 213 Appendix A. Change History 215 A.1. Change from 00 to 01 217 Editorial changes. 219 A.2. Change from 01 to 02 221 Added implementation reference. Added acknowledgement. 223 A.3. Change from 02 to 03 225 Simplified this document. 227 Appendix B. Acknowledgements 229 The author wishes to thank the following persons for their feedback 230 and suggestions (sorted alphabetically by company): 232 o Tim Ettel, united-domains 234 Author's Address 236 Tobias Sattler 238 Email: tobias.sattler@me.com 239 URI: https://tobiassattler.com