draft-ietf-regext-simple-registration-reporting-01.txt   draft-ietf-regext-simple-registration-reporting-02.txt 
Internet Engineering Task Force J.Y,. Yee, Ed. Internet Engineering Task Force J. Yee, Ed.
Internet-Draft J.G,. Galvin Internet-Draft J. Galvin
Intended status: Informational Afilias Intended status: Informational Afilias
Expires: 14 January 2021 13 July 2020 Expires: 6 May 2021 2 November 2020
Simple Registration Reporting Simple Registration Reporting
draft-ietf-regext-simple-registration-reporting-01 draft-ietf-regext-simple-registration-reporting-02
Abstract Abstract
Domain name registries and registrars report to each other by sharing Domain name registries and registrars report to each other by sharing
bulk information through files. This document creates two IANA bulk information through files. This document creates two IANA
registries to create a standard reporting mechanism between domain registries to establish a standard reporting mechanism between domain
name registries and registrars. The first IANA registry lists name registries and registrars. The first IANA registry lists
standard data elements and their syntax for inclusion in the files. standard data elements and their syntax for inclusion in the files.
The second IANA registry lists standard reports based on the standard The second IANA registry lists standard reports based on the standard
data elements. Each report is a file formatted as a CSV file. The data elements. Each report is a file formatted as a CSV file. The
advantage of this reporting mechanism is that reports, each file, can advantage of this reporting mechanism is that report, each file, can
be imported by recipients without any prior knowledge of their be imported by recipients without any prior knowledge of their
contents, although reporting is enhanced with a minimum of knowledge contents, although reporting is enhanced with a minimum of knowledge
about the files. The mechanism for the transmission and reception of about the files. The mechanism for the transmission and reception of
the files is a matter of local policy. the files is a matter of local policy.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 January 2021. This Internet-Draft will expire on 6 May 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Data Element Specification . . . . . . . . . . . . . . . . . 4 2. Data Element Specification . . . . . . . . . . . . . . . . . 4
2.1. General Information Fields . . . . . . . . . . . . . . . 4 2.1. General Information Fields . . . . . . . . . . . . . . . 4
2.1.1. TLD . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. TLD . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Server_TRID . . . . . . . . . . . . . . . . . . . . . 4 2.1.2. Server_TRID . . . . . . . . . . . . . . . . . . . . . 5
2.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.3. Domain . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.4. Transaction_Type . . . . . . . . . . . . . . . . . . 5 2.1.4. Transaction_Type . . . . . . . . . . . . . . . . . . 5
2.1.5. Ojbect_Type . . . . . . . . . . . . . . . . . . . . . 5 2.1.5. Object_Type . . . . . . . . . . . . . . . . . . . . . 5
2.1.6. DateTime . . . . . . . . . . . . . . . . . . . . . . 5 2.1.6. DateTime . . . . . . . . . . . . . . . . . . . . . . 5
2.1.7. Term . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.7. Term . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.8. Fee . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.8. Fee . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.9. Currency . . . . . . . . . . . . . . . . . . . . . . 5 2.1.9. Currency . . . . . . . . . . . . . . . . . . . . . . 6
2.1.10. Status . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.10. Status . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.11. Registrar . . . . . . . . . . . . . . . . . . . . . . 6 2.1.11. Registrar . . . . . . . . . . . . . . . . . . . . . . 6
2.1.12. Period . . . . . . . . . . . . . . . . . . . . . . . 6 2.1.12. Period . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.13. Description . . . . . . . . . . . . . . . . . . . . . 6 2.1.13. Description . . . . . . . . . . . . . . . . . . . . . 6
2.2. Domain Price Fields . . . . . . . . . . . . . . . . . . . 6 2.2. Domain Price Fields . . . . . . . . . . . . . . . . . . . 6
2.2.1. Domain_Create . . . . . . . . . . . . . . . . . . . . 6 2.2.1. Domain_Create . . . . . . . . . . . . . . . . . . . . 6
2.2.2. Domain_Renew . . . . . . . . . . . . . . . . . . . . 6 2.2.2. Domain_Renew . . . . . . . . . . . . . . . . . . . . 6
2.2.3. Domain_Transfer . . . . . . . . . . . . . . . . . . . 6 2.2.3. Domain_Transfer . . . . . . . . . . . . . . . . . . . 6
2.2.4. Domain_Restore . . . . . . . . . . . . . . . . . . . 6 2.2.4. Domain_Restore . . . . . . . . . . . . . . . . . . . 7
2.3. Timestamp Fields . . . . . . . . . . . . . . . . . . . . 6 2.3. Timestamp Fields . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Start_Date . . . . . . . . . . . . . . . . . . . . . 6 2.3.1. Start_Date . . . . . . . . . . . . . . . . . . . . . 7
2.3.2. Deleted_Date . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Deleted_Date . . . . . . . . . . . . . . . . . . . . 7
2.3.3. RGP_Date . . . . . . . . . . . . . . . . . . . . . . 7 2.3.3. RGP_Date . . . . . . . . . . . . . . . . . . . . . . 7
2.3.4. Purge_Date . . . . . . . . . . . . . . . . . . . . . 7 2.3.4. Purge_Date . . . . . . . . . . . . . . . . . . . . . 7
2.3.5. Updated_Date . . . . . . . . . . . . . . . . . . . . 7 2.3.5. Updated_Date . . . . . . . . . . . . . . . . . . . . 7
2.3.6. Create_Date . . . . . . . . . . . . . . . . . . . . . 7 2.3.6. Create_Date . . . . . . . . . . . . . . . . . . . . . 7
2.3.7. Expiry_Date . . . . . . . . . . . . . . . . . . . . . 7 2.3.7. Expiry_Date . . . . . . . . . . . . . . . . . . . . . 7
2.4. Registration Information Fields . . . . . . . . . . . . . 7 2.4. Registration Information Fields . . . . . . . . . . . . . 8
2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 7 2.4.1. Registrar_ID . . . . . . . . . . . . . . . . . . . . 8
2.4.2. Server_Registrant_ID . . . . . . . . . . . . . . . . 8 2.4.2. Server_Registrant_ID . . . . . . . . . . . . . . . . 8
2.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.3. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.4. Server_Contact_ID . . . . . . . . . . . . . . . . . . 8 2.4.4. Server_Contact_ID . . . . . . . . . . . . . . . . . . 8
2.4.5. Contact_Type . . . . . . . . . . . . . . . . . . . . 8 2.4.5. Contact_Type . . . . . . . . . . . . . . . . . . . . 8
2.4.6. Contact_Name . . . . . . . . . . . . . . . . . . . . 8 2.4.6. Contact_Name . . . . . . . . . . . . . . . . . . . . 8
2.4.7. INUSE . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4.7. INUSE . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4.8. Nameserver_Host . . . . . . . . . . . . . . . . . . . 8 2.4.8. Nameserver_Host . . . . . . . . . . . . . . . . . . . 8
2.4.9. Nameserver_IP . . . . . . . . . . . . . . . . . . . . 8 2.4.9. Nameserver_IP . . . . . . . . . . . . . . . . . . . . 9
2.4.10. Client_Contact_ID . . . . . . . . . . . . . . . . . . 8 2.4.10. Client_Contact_ID . . . . . . . . . . . . . . . . . . 9
3. Report Definition Specification . . . . . . . . . . . . . . . 9 3. Report Definition Specification . . . . . . . . . . . . . . . 9
3.1. Transaction Report . . . . . . . . . . . . . . . . . . . 9 3.1. Transaction Report . . . . . . . . . . . . . . . . . . . 10
3.2. Premium Name Report . . . . . . . . . . . . . . . . . . . 10 3.2. Premium Name Report . . . . . . . . . . . . . . . . . . . 10
3.3. Domain RGP Report . . . . . . . . . . . . . . . . . . . . 11 3.3. Domain RGP Report . . . . . . . . . . . . . . . . . . . . 11
3.4. Reserved Domain Report . . . . . . . . . . . . . . . . . 11 3.4. Reserved Domain Report . . . . . . . . . . . . . . . . . 12
3.5. Domain Inventory Report . . . . . . . . . . . . . . . . . 12 3.5. Domain Inventory Report . . . . . . . . . . . . . . . . . 12
3.6. Contact Inventory Report . . . . . . . . . . . . . . . . 12 3.6. Contact Inventory Report . . . . . . . . . . . . . . . . 13
3.7. Host Inventory Report . . . . . . . . . . . . . . . . . . 13 3.7. Host Inventory Report . . . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1. Report Specification . . . . . . . . . . . . . . . . . . 14
5.1. Field Definition . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Designated Expert Evaluation Criteria . . . . . . . . 14
5.2. Report Definition . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Registration Procedure . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4.1.2.1. Required Information . . . . . . . . . . . . . . 15
7. Internationalization Considerations . . . . . . . . . . . . . 14 4.1.2.2. Registration Processing . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.2.3. Updating Report Definition Registry Entries . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 14 4.2. Initial assignments . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 15 4.2.1. Field Definition in IANA Registry . . . . . . . . . . 16
Appendix A. File Naming Convention . . . . . . . . . . . . . . . 16 4.2.2. Report Definition in IANA Registry . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 30
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
7. Internationalization Considerations . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
8.1. Normative References . . . . . . . . . . . . . . . . . . 31
8.2. Informative References . . . . . . . . . . . . . . . . . 32
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Appendix B. File Naming Convention . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Currently, domain name registry operators (the producer) create and Currently, domain name registry operators (the producer) create and
set their own domain name registration reports for use by their set their own domain name registration reports for use by their
registrars (the consumer). Among the distinctions that vary by registrars (the consumer). Among the distinctions that vary by
producers is the syntax of the data provided, e.g., date formats, and producer is the syntax of the data provided, e.g., date formats, and
the format of the collection of the data provided, e.g., the report the format of the collection of the data provided, e.g., the report
may be a CSV file that tends to allow for straightforward importation may be a CSV file that tends to allow for straightforward importation
or a PDF file that can be problematic to import. In addition, or a PDF file that can be problematic to import. In addition,
although there are a number of best practice reports that have although there are a number of best practice reports that have
evolved, these are not currently documented as such, which results in evolved, these are not currently documented as such, which results in
a fair amount of customization on the part of the consumers to import a fair amount of customization on the part of the consumers to import
data. data.
This document standardizes the name and syntax of the data elements This document standardizes the name and syntax of the data elements
to be used across all existing domain name registration reports and to be used across all existing domain name registration reports and
skipping to change at page 4, line 29 skipping to change at page 4, line 38
no other significance to the groupings. no other significance to the groupings.
Each data element conceptually represents the column heading in a Each data element conceptually represents the column heading in a
printed report. It is a single unit of information that can be printed report. It is a single unit of information that can be
passed from the producer to the consumer. The primary purposes of passed from the producer to the consumer. The primary purposes of
the IANA registry of data elements are to ensure that each data the IANA registry of data elements are to ensure that each data
element is assigned a unique name and that the syntax of each data element is assigned a unique name and that the syntax of each data
element is specified. element is specified.
The name of the data element MUST be unique and this characteristic The name of the data element MUST be unique and this characteristic
MUST be enforced by registry. The name is used in the report MUST be enforced by the registry. The name is used in the report
definition (in the next section) to alert the consumer as to what to definition (in the next section) to alert the consumer as to what to
expect in the file and how to import the data element. expect in the file and how to import the data element.
The subsections below comprise an initial list of known data elements The subsections below comprise an initial list of known data elements
commonly being used between producers and consumers as of the date of commonly being used between producers and consumers as of the date of
publication of this document. The title of the subsection is the publication of this document. The title of the subsection is the
field name for the data element. field name for the data element. Field names in the IANA registry
MUST be unique and case insensitive.
2.1. General Information Fields 2.1. General Information Fields
2.1.1. TLD 2.1.1. TLD
The string of the top level domain involved that SHOULD be in A-LABEL The string of the top level domain involved that MUST be in A-LABEL
format as defined by RFC 5890 [RFC5890]. format as defined by RFC 5890 [RFC5890].
2.1.2. Server_TRID 2.1.2. Server_TRID
The transaction identifier issued by EPP Server. The format MUST The transaction identifier issued by an EPP Server. The format MUST
conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730]. conform to "type:trIDStringType" as specified in RFC 5730 [RFC5730].
2.1.3. Domain 2.1.3. Domain
This is the domain name in EPP RFC 5731 [RFC5731] domain object and This is the domain name in an EPP RFC 5731 [RFC5731] domain object
it SHOULD be in A-Label format. and it SHOULD be in A-Label format.
2.1.4. Transaction_Type 2.1.4. Transaction_Type
The type of transform action made to the domain object (CREATE, The type of transform action made to the domain object (CREATE,
DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730] DELETE, UPDATE, TRANSFER, RENEW) as specified in RFC 5730 [RFC5730]
Section 2.9.3 Section 2.9.3.
2.1.5. Ojbect_Type 2.1.5. Object_Type
The object type involved in the report. In the EPP environment, an The object type involved in the report. In the EPP environment, an
object could be domain RFC 5731 [RFC5731], contact RFC 5733 object could be domain RFC 5731 [RFC5731], contact RFC 5733
[RFC5733], or host RFC 5732 [RFC5732]. [RFC5733], or host RFC 5732 [RFC5732].
2.1.6. DateTime 2.1.6. DateTime
The timestamp of the transaction recorded in the system. The date The timestamp of the transaction recorded in the system. The date
and time format follows the "type=dateTime" specification as defined and time format follows the "type=dateTime" specification as defined
in RFC 5731 [RFC5731]. in RFC 5731 [RFC5731].
2.1.7. Term 2.1.7. Term
The number of unit added to the domain registration period in The number of units added to the domain registration period in
"domain:period" RFC 5731 [RFC5731] in create command or renew "domain:period" RFC 5731 [RFC5731] in create command, renew or
command. If there's no "domain:period", it should take the default transfer command. If there's no "domain:period", it should take the
value set by the registry. default value set out of band by the registry.
2.1.8. Fee 2.1.8. Fee
The amount of money charged or returned (shown as negative value) to The amount of money charged or returned (shown as a negative value)
the registrar. The numeric format MUST conform to the currency to the registrar. The numeric format MUST conform to the currency
specified below in Section 2.1.9. The format must conform to specified below in Section 2.1.9. The format must conform to
"balanceType" as defined in RFC 8748 [RFC8748] "balanceType" as defined in RFC 8748 [RFC8748].
2.1.9. Currency 2.1.9. Currency
The currency used in the money charged as documented above in The currency used in the money charged as documented above in
Section 2.1.18. It is recommended for currency code to follow ISO Section 2.1.8. The currency code should follow the ISO 4217
4217 [ISO4217]standard. [ISO4217] standard.
2.1.10. Status 2.1.10. Status
The status of domain object. It MUST be one of the values specified The status of the domain object. It MUST be one of the values
in RFC 5731 [RFC5731] Section 2.3. specified in RFC 5731 [RFC5731] Section 2.3.
2.1.11. Registrar 2.1.11. Registrar
The name of the registrar. This field is text/string with no naming The name of the registrar. This field is text/string with no naming
convention enforced. convention enforced.
2.1.12. Period 2.1.12. Period
The type of time (year, month) in 'Term' described above in The type of time (year, month) in 'Term' described above in
Section 2.1.7 Section 2.1.7. The value of 'year' and 'month' are referenced to
pUnitType value 'y' and 'm' respectively. pUnitType is specified in
RFC 5731 [RFC5731].
2.1.13. Description 2.1.13. Description
Additional information regarding the current entry in the report. It Additional information regarding the current entry in the report. It
is provided by the producer and its actual value is a matter of local is provided by the producer and its actual value is a matter of local
policy. policy.
2.2. Domain Price Fields 2.2. Domain Price Fields
2.2.1. Domain_Create 2.2.1. Domain_Create
The fee charged to create the domain. The format must conform to The fee charged to create the domain. The format must conform to
"balanceType" as defined in [draft-ietf-regext-epp-fees] "balanceType" as defined in RFC 8748 [RFC8748].
2.2.2. Domain_Renew 2.2.2. Domain_Renew
The fee charged to renew the domain. The format must conform to The fee charged to renew the domain. The format must conform to
"balanceType" as defined in [draft-ietf-regext-epp-fees] "balanceType" as defined in RFC 8748 [RFC8748].
2.2.3. Domain_Transfer 2.2.3. Domain_Transfer
The fee charged to transfer the domain. The format must conform to The fee charged to transfer the domain. The format must conform to
"balanceType" as defined in [draft-ietf-regext-epp-fees] "balanceType" as defined in RFC 8748 [RFC8748].
2.2.4. Domain_Restore 2.2.4. Domain_Restore
The fee charged to restore the domain. The format must conform to The fee charged to restore the domain. The format must conform to
"balanceType" as defined in [draft-ietf-regext-epp-fees] "balanceType" as defined in RFC 8748 [RFC8748].
2.3. Timestamp Fields 2.3. Timestamp Fields
2.3.1. Start_Date 2.3.1. Start_Date
The timestamp of when the domain object becomes available. The date The timestamp of when the domain object becomes available. The date
and time format follows the "type=dateTime" specification as defined and time format follows the "type=dateTime" specification as defined
in RFC 5731 [RFC5731]. in RFC 5731 [RFC5731].
2.3.2. Deleted_Date 2.3.2. Deleted_Date
The timestamp of when the domain was deleted by the end user. The The timestamp of when the domain was deleted by the end user. The
date and time format follows the "type=dateTime" specification as date and time format follows the "type=dateTime" specification as
defined in RFC 5731 [RFC5731]. defined in RFC 5731 [RFC5731].
2.3.3. RGP_Date 2.3.3. RGP_Date
The timestamp of when the domain will complete its redemption grace The timestamp of when the domain will complete its redemption grace
period. In BestPractice.domains, this is referred to as 'expired'. period. The date and time format follows the "type=dateTime"
The date and time format follows the "type=dateTime" specification as specification as defined in RFC 5731 [RFC5731].
defined in RFC 5731 [RFC5731].
2.3.4. Purge_Date 2.3.4. Purge_Date
The timestamp of when the domain will be purged and become available The timestamp of when the domain will be purged and become available
again. In BestPractice.domains, this is referred to as 'purged'. again. The date and time format follows the "type=dateTime"
The date and time format follows the "type=dateTime" specification as specification as defined in RFC 5731 [RFC5731].
defined in RFC 5731 [RFC5731].
2.3.5. Updated_Date 2.3.5. Updated_Date
The timestamp of the last time the domain object was updated. In The timestamp of the last time the domain object was updated. The
BestPractice.domains, this is referred to as 'Updated'. The date and date and time format follows the "type=dateTime" specification as
time format follows the "type=dateTime" specification as defined in defined in RFC 5731 [RFC5731].
RFC 5731 [RFC5731].
2.3.6. Create_Date 2.3.6. Create_Date
The timestamp of the domain object was allocated. The date and time The timestamp of when the domain object was allocated. The date and
format follows the "type=dateTime" specification as defined in RFC time format follows the "type=dateTime" specification as defined in
5731 [RFC5731]. RFC 5731 [RFC5731].
2.3.7. Expiry_Date 2.3.7. Expiry_Date
The timestamp of the domain object will expire. The date and time The timestamp of when the domain object will expire. The date and
format follows the "type=dateTime" specification as defined in RFC time format follows the "type=dateTime" specification as defined in
5731 [RFC5731]. RFC 5731 [RFC5731].
2.4. Registration Information Fields 2.4. Registration Information Fields
2.4.1. Registrar_ID 2.4.1. Registrar_ID
The identifier assigned to the registrar. If the registrar is The identifier assigned to the registrar. If the registrar is
accredited under ICANN, it MUST be the registrar's IANA ID accredited under ICANN, it MUST be the registrar's IANA ID
[IANA_Registrar_IDs]. Otherwise it is a value known between the [IANA_Registrar_IDs]. Otherwise it is a value known between the
producer and the consumer. producer and the consumer, set via an out-of-band mechanism and
unique within all reports of the producer.
2.4.2. Server_Registrant_ID 2.4.2. Server_Registrant_ID
The identifier assigned to the contact object that is associated as The identifier, issued by EPP server, assigned to the contact object
registrant of the domain name that MUST conform to "clIDType" that is associated as registrant of the domain name that MUST conform
specified in RFC 5730 [RFC5730]. to "clIDType" specified in RFC 5730 [RFC5730].
2.4.3. DNSSEC 2.4.3. DNSSEC
The value MUST be either 'YES' or 'NO' to indicate whether the domain The value MUST be either 'YES' or 'NO' to indicate whether the domain
is DNSSEC signed. is DNSSEC signed.
2.4.4. Server_Contact_ID 2.4.4. Server_Contact_ID
The identifier of the contact object assigned by registry system. The identifier of the contact object assigned by the registry system
and MUST conform to "clIDType" specified in RFC 5730 [RFC5730].
2.4.5. Contact_Type 2.4.5. Contact_Type
The value MUST be one of value as defined by "contactAttrType" in RFC The value MUST be one of value as defined by "contactAttrType" in RFC
5731 [RFC5731]. 5731 [RFC5731].
2.4.6. Contact_Name 2.4.6. Contact_Name
The name of the contact object. Usually it is the name of an The name of the contact object. Usually it is the name of an
individual or an organization as described in RFC 5733 [RFC5733] individual or an organization as described in RFC 5733 [RFC5733]
Section 2.3 Section 2.3.
2.4.7. INUSE 2.4.7. INUSE
MUST be either "YES" or "NO" to indicate whether the contact object The value MUST be either "YES" or "NO" to indicate whether the
is associated with a domain object. contact object is associated with a domain object.
2.4.8. Nameserver_Host 2.4.8. Nameserver_Host
The full domain name of the host object. The name MUST be in A-Label The full domain name of the host object as defined in RFC 5732
format. [RFC5732] Section 2.1. The name SHOULD be in A-Label format.
2.4.9. Nameserver_IP 2.4.9. Nameserver_IP
The IP address of the host object. The syntax of the IPv4 address The IP address of the host object. The syntax of the IPv4 address
MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address MUST conform to RFC 791 [RFC0791]. The syntax of the IPv6 address
MUST conform to RFC 4291 [RFC4291]. MUST conform to RFC 4291 [RFC4291].
2.4.10. Client_Contact_ID 2.4.10. Client_Contact_ID
The identifier of the contact object assigned by registrar. The identifier of the contact object assigned by the registrar and
MUST conform to "clIDType" specified in RFC 5730 [RFC5730].
3. Report Definition Specification 3. Report Definition Specification
Each report specification conceptually represents a file of comma Each report specification conceptually represents a file of comma
separated values [RFC4180] (commonly called a CSV file) where the separated values [RFC4180] (commonly called a CSV file) where the
values are selected from the data elements specified above. The values are selected from the data elements specified above. The
first row of the file is a comma separated list of field names as first row of the file is a comma separated list of field names as
specified in the data element registry. The remaining rows of the specified in the data element registry. The remaining rows of the
file are the unordered sets of data elements, one set per row, where file are the unordered sets of data elements, one set per row, where
each row is one transaction in the report. each row is one transaction in the report.
Each data element conceptually represents the column heading in a Each data element in a set conceptually represents the column heading
printed report. The first row represents the column headings and in a printed report.
each succeeding row represents a transaction of the report.
A consumer MUST be able to receive data elements that are not A consumer MUST be able to receive data elements that are not
recognized and MAY skip them accordingly, both in the header row and recognized and MAY skip them accordingly, both in the header row and
in the transaction rows. in the transaction rows.
A report is specified in the report registry with two pieces of A report is specified in the report registry with two pieces of
information. First is the name of the report. This can be whatever information. First is the name of the report. This can be whatever
is appropriate as defined by the producer of the report. The name of is appropriate as defined by the producer of the report. The name of
the report MUST be unique and this characteristic MUST be enforced by the report MUST be unique and this characteristic MUST be enforced by
registry. registry.
Second is the ordered list of field names of what is included in the Second is the ordered list of field names of what is included in the
report. The field names MUST be listed in the data element registry report. The field names MUST be listed in the data element registry
specified above. The field names and the data MUST appear in the specified above. The field names and the data MUST appear in the
report in the order listed in the report registry. report in the order listed in the report registry.
The subsections below comprise an initial list of standard reports The subsections below comprise an initial list of standard reports
commonly being used between producers and consumers as of the data of commonly being used between producers and consumers as of the date of
publication of this document. The title of the subsection is the publication of this document. The title of the subsection is the
report name. report name. The report name in the IANA registry must be unique and
case insensitive.
3.1. Transaction Report 3.1. Transaction Report
[Note] There is a new column in this report that is not added to [Note] There is a new column in this report that is not added to
other reports. There are discussions on whether to define if each other reports. It has been suggested that the report definition
field is mandatory. The column was added to this report only for indicate if a value is required for the field or if it can be empty.
visualation and to further discussion. This paragraph will be The column was added to this report only for visualization and to
removed once working group discussed and reached consensus on further discussion. This paragraph will be removed once the working
direction. group discusses the issue and reaches consensus on direction.
Name of report: domain_transaction
+==================+========================+===========+ +==================+========================+===========+
| Field | Reference | Mandatory | | Field | Reference | Mandatory |
+==================+========================+===========+ +==================+========================+===========+
| TLD | RFC XXXX Section 2.1.1 | N | | TLD | RFC XXXX Section 2.1.1 | N |
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
| Server_TRID | Section 2.1.2 | Y | | Server_TRID | Section 2.1.2 | Y |
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
| Domain | Section 2.1.3 | Y | | Domain | Section 2.1.3 | Y |
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
skipping to change at page 10, line 37 skipping to change at page 10, line 48
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
| Currency | Section 2.1.9 | Y | | Currency | Section 2.1.9 | Y |
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
| Description | Section 2.1.13 | N | | Description | Section 2.1.13 | N |
+------------------+------------------------+-----------+ +------------------+------------------------+-----------+
Table 1: Transaction Report Definition Table Table 1: Transaction Report Definition Table
3.2. Premium Name Report 3.2. Premium Name Report
Name of report: premium_name
+=================+========================+ +=================+========================+
| Field | Reference | | Field | Reference |
+=================+========================+ +=================+========================+
| TLD | RFC XXXX Section 2.1.1 | | TLD | RFC XXXX Section 2.1.1 |
+-----------------+------------------------+ +-----------------+------------------------+
| Domain | Section 2.1.3 | | Domain | Section 2.1.3 |
+-----------------+------------------------+ +-----------------+------------------------+
| Status | Section 2.1.10 | | Status | Section 2.1.10 |
+-----------------+------------------------+ +-----------------+------------------------+
| Description | Section 2.1.13 | | Description | Section 2.1.13 |
skipping to change at page 11, line 17 skipping to change at page 11, line 33
| Domain_Restore | Section 2.2.4 | | Domain_Restore | Section 2.2.4 |
+-----------------+------------------------+ +-----------------+------------------------+
| Start_Date | Section 2.3.1 | | Start_Date | Section 2.3.1 |
+-----------------+------------------------+ +-----------------+------------------------+
Table 2: Premium Name Report Definition Table 2: Premium Name Report Definition
Table Table
3.3. Domain RGP Report 3.3. Domain RGP Report
Name of report: domain_rgp
+==============+========================+ +==============+========================+
| Field | Reference | | Field | Reference |
+==============+========================+ +==============+========================+
| TLD | RFC XXXX Section 2.1.1 | | TLD | RFC XXXX Section 2.1.1 |
+--------------+------------------------+ +--------------+------------------------+
| Domain | Section 2.1.3 | | Domain | Section 2.1.3 |
+--------------+------------------------+ +--------------+------------------------+
| Deleted_Date | Section 2.3.2 | | Deleted_Date | Section 2.3.2 |
+--------------+------------------------+ +--------------+------------------------+
| RGP_Date | Section 2.3.3 | | RGP_Date | Section 2.3.3 |
+--------------+------------------------+ +--------------+------------------------+
| Purge_Date | Section 2.3.4 | | Purge_Date | Section 2.3.4 |
+--------------+------------------------+ +--------------+------------------------+
Table 3: Domain RGP Report Definition Table 3: Domain RGP Report Definition
Table Table
3.4. Reserved Domain Report 3.4. Reserved Domain Report
Name of report: reserved_domain
+========+========================+ +========+========================+
| Field | Reference | | Field | Reference |
+========+========================+ +========+========================+
| TLD | RFC XXXX Section 2.1.1 | | TLD | RFC XXXX Section 2.1.1 |
+--------+------------------------+ +--------+------------------------+
| Domain | Section 2.1.3 | | Domain | Section 2.1.3 |
+--------+------------------------+ +--------+------------------------+
| Status | Section 2.1.10 | | Status | Section 2.1.10 |
+--------+------------------------+ +--------+------------------------+
Table 4: Reserved Domain Report Table 4: Reserved Domain Report
Definition Table Definition Table
3.5. Domain Inventory Report 3.5. Domain Inventory Report
Name of report: domain_inventory
+======================+========================+ +======================+========================+
| Field | Reference | | Field | Reference |
+======================+========================+ +======================+========================+
| TLD | RFC XXXX Section 2.1.1 | | TLD | RFC XXXX Section 2.1.1 |
+----------------------+------------------------+ +----------------------+------------------------+
| Domain | Section 2.1.3 | | Domain | Section 2.1.3 |
+----------------------+------------------------+ +----------------------+------------------------+
| Updated_Date | Section 2.3.5 | | Updated_Date | Section 2.3.5 |
+----------------------+------------------------+ +----------------------+------------------------+
| Registrar_ID | Section 2.4.1 | | Registrar_ID | Section 2.4.1 |
skipping to change at page 12, line 33 skipping to change at page 13, line 7
+----------------------+------------------------+ +----------------------+------------------------+
| DNSSEC | Section 2.4.3 | | DNSSEC | Section 2.4.3 |
+----------------------+------------------------+ +----------------------+------------------------+
| Status | Section 2.1.10 | | Status | Section 2.1.10 |
+----------------------+------------------------+ +----------------------+------------------------+
Table 5: Domain Inventory Report Definition Table Table 5: Domain Inventory Report Definition Table
3.6. Contact Inventory Report 3.6. Contact Inventory Report
Name of report: contact_inventory
+===================+================+ +===================+================+
| Field | Reference | | Field | Reference |
+===================+================+ +===================+================+
| Server_Contact_ID | Section 2.4.4 | | Server_Contact_ID | Section 2.4.4 |
+-------------------+----------------+ +-------------------+----------------+
| Client_Contact_ID | Section 2.4.10 | | Client_Contact_ID | Section 2.4.10 |
+-------------------+----------------+ +-------------------+----------------+
| TLD | Section 2.1.1 | | TLD | Section 2.1.1 |
+-------------------+----------------+ +-------------------+----------------+
| Domain | Section 2.1.3 | | Domain | Section 2.1.3 |
skipping to change at page 13, line 11 skipping to change at page 13, line 36
| INUSE | Section 2.4.7 | | INUSE | Section 2.4.7 |
+-------------------+----------------+ +-------------------+----------------+
| Registrar_ID | Section 2.4.1 | | Registrar_ID | Section 2.4.1 |
+-------------------+----------------+ +-------------------+----------------+
Table 6: Contact Inventory Report Table 6: Contact Inventory Report
Definition Table Definition Table
3.7. Host Inventory Report 3.7. Host Inventory Report
Name of report: host_inventory
+=================+=======================+ +=================+=======================+
| Field | Reference | | Field | Reference |
+=================+=======================+ +=================+=======================+
| TLD | RFCXXXX Section 2.1.1 | | TLD | RFCXXXX Section 2.1.1 |
+-----------------+-----------------------+ +-----------------+-----------------------+
| Nameserver_Host | Section 2.4.8 | | Nameserver_Host | Section 2.4.8 |
+-----------------+-----------------------+ +-----------------+-----------------------+
| Nameserver_IP | Section 2.4.9 | | Nameserver_IP | Section 2.4.9 |
+-----------------+-----------------------+ +-----------------+-----------------------+
Table 7: Host Inventory Report Table 7: Host Inventory Report
Definition Table Definition Table
4. Acknowledgements 4. IANA Considerations
The authors would like to thank Roger Carney, Jody Kolker for their This section describes the format of the IANA Registration Report
reviews and suggestions Registry, which has two tables described below, and the procedures
used to populate and manage the registry entries.
5. IANA Considerations 4.1. Report Specification
This document asks IANA to create two new registries. Each registry This registry uses the "Specification Required" policy described in
is a first-come first-served registry. RFC 8126 [RFC8126]. An English language version of the extension
specification is required in the registry, though non-English
versions of the specification may also be provided.
DETAILS TO BE SPECIFIED AS THE DOCUMENT EVOLVES. The "Specification Required" policy implies review by a "designated
expert". Section 5.2 of RFC 8126 [RFC8126] describes the role of
designated experts and the function they perform.
5.1. Field Definition 4.1.1. Designated Expert Evaluation Criteria
The field name must be unique and case insensitive. A high-level description of the role of the designated expert is
described in Section 5.2 of RFC 8126 [RFC8126]. Specific guidelines
for the appointment of designated experts and the evaluation of a
Registration Report is provided here.
PROPOSED FIELD NAME TABLE ENTRY. DETAILS TO BE SPECIFIED AS THE The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5)
DOCUMENT EVOLVES. to serve as designated experts, as described in Section 5.2 of RFC
8126 [RFC8126]. The pool should have a single administrative chair
who is appointed by the IESG. The designated experts should use the
existing regext mailing list (regext@ietf.org) for public discussion
of registration requests. This implies that the mailing list should
remain open after the work of the REGEXT working group has concluded.
The results of the evaluation should be shared via email with the
registrant and the regext mailing list. Issues discovered during the
evaluation can be corrected by the registrant, and those corrections
can be submitted to the designated experts until the designated
experts explicitly decide to accept or reject the registration
request. The designated experts must make an explicit decision and
that decision must be shared via email with the registrant and the
regext mailing list. If the specification for a field or report is
an IETF Standards Track document, no review is required by the
designated expert.
Designated experts should be permissive in their evaluation of
requests for fields and reports that have been implemented and
deployed by at least one registry. This implies that it may indeed
be possible to register multiple fields or reports that provide the
same functionality. Requests to register fields or reports that have
not been deployed should be evaluated with a goal of reducing
duplication. A potential registrant who submits a request to
register a new field or report that includes similar functionality to
existing fields or reports should be made aware of the existing
fields and reports. The registrant should be asked to reconsider
their request given the existence of similar fields or reports.
Should they decline to do so, perceived similarity should not be a
sufficient reason for rejection as long as all other requirements are
met.
4.1.2. Registration Procedure
The registry contains information describing each registered field
and report. Registry entries are created and managed by sending
forms to IANA that describe the field and report on the registry
entry.
4.1.2.1. Required Information
The required information must be formatted consistently using the
following registration form. Form field names and values may appear
on the same line.
4.1.2.1.1. Field Definition
The field name must be unique and evaluated in a case insensitive
way.
Name of field Name of field
Enforced to be case-insensitive (if appropriate) unique Enforced to be case-insensitive and unique
Reference document defining the field, including section number Reference document defining the field, including section number
Should be an RFC in many cases SHOULD be a URL to a RFC, MAY be a URL to any document
available under equivalent terms
Registrant Registrant
Will be IESG for initial entries Will be IESG for initial entries
Status Status
MUST be active, inactive, unknown MUST be active, inactive, unknown
5.2. Report Definition 4.1.2.1.2. Report Definition
The report name must be unique and case insensitive. that any future The report name must be unique and case insensitive.
submission must not have the same case insensitive match with prior
entry.
Name of report Name of Report
Document Status Document Status
Reference
Reference (including section number) Registrant:IESG
Registrant: IESG TLD:any
TLD: any Status:active
Status: active 4.1.2.2. Registration Processing
6. Security Considerations Registrants should send each registration form to IANA with a single
record for incorporation into the registry. Send the form via email
to iana@iana.org or complete the online form found on the IANA web
site. The subject line should indicate whether the enclosed form
represents an insertion of a new record (indicated by the word
"INSERT" in the subject line) or a replacement of an existing record
(indicated by the word "MODIFY" in the subject line). At no time can
a record be deleted from the registry. On receipt of the
registration request, IANA will initiate review by the designated
expert(s) if appropriate, who will evaluate the request using the
criteria in Section 4.1.1 in consultation with the regext mailing
list.
TBD 4.1.2.3. Updating Report Definition Registry Entries
When submitting changes to existing registry entries, include text in
the "Notes" field of the registration form describing the change.
Under normal circumstances, registry entries are only to be updated
by the registrant. If the registrant becomes unavailable or
otherwise unresponsive, the designated expert can submit a
registration form to IANA to update the registrant information.
Entries can change state from "Active" to "Inactive" and back again
as long as state-change requests conform to the processing
requirements identified in this document. In addition to entries
that become "Inactive" due to a lack of implementation, entries for
which a specification becomes consistently unavailable over time
should be marked "Inactive" by the designated expert until the
specification again becomes reliably available.
4.2. Initial assignments
4.2.1. Field Definition in IANA Registry
---- BEGIN FORM ----
Name of field:
TLD
Reference:
This RFC Section 2.1.1
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Server_TRID
Reference:
This RFC Section 2.1.2
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Domain
Reference:
This RFC Section 2.1.3
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Transaction_Type
Reference:
This RFC Section 2.1.4
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Ojbect_Type
Reference:
This RFC Section 2.1.5
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
DateTime
Reference:
This RFC Section 2.1.6
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Term
Reference:
This RFC Section 2.1.7
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Currency
Reference:
This RFC Section 2.1.9
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Status
Reference:
This RFC Section 2.1.10
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Registrar
Reference:
This RFC Section 2.1.11
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Period
Reference:
This RFC Section 2.1.12
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Description
Reference:
This RFC Section 2.1.13
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Domain_Create
Reference:
This RFC Section 2.2.1
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Domain_Renew
Reference:
This RFC Section 2.2.2
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Domain_Transfer
Reference:
This RFC Section 2.2.3
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Domain_Restore
Reference:
This RFC Section 2.2.4
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Start_Date
Reference:
This RFC Section 2.3.1
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Deleted_Date
Reference:
This RFC Section 2.3.2
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
RGP_Date
Reference:
This RFC Section 2.3.3
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Purge_Date
Reference:
This RFC Section 2.3.4
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Updated_Date
Reference:
This RFC Section 2.3.5
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Create_Date
Reference:
This RFC Section 2.3.6
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Expiry_Date
Reference:
This RFC Section 2.3.7
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Registrar_ID
Reference:
This RFC Section 2.4.1
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Server_Registrant_ID
Reference:
This RFC Section 2.4.2
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
DNSSEC
Reference:
This RFC Section 2.4.3
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Server_Contact_ID
Reference:
This RFC Section 2.4.4
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Contact_Type
Reference:
This RFC Section 2.4.5
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Contact_Name
Reference:
This RFC Section 2.4.6
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
INUSE
Reference:
This RFC Section 2.4.7
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Nameserver_Host
Reference:
This RFC Section 2.4.8
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Nameserver_IP
Reference:
This RFC Section 2.4.9
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of field:
Client_Contact_ID
Reference:
This RFC Section 2.4.10
Registrant:
IESG, iesg@ietf.org
Status:
Active
---- END FORM ----
4.2.2. Report Definition in IANA Registry
---- BEGIN FORM ----
Name of report:
domain_transaction
Reference:
This RFC Table 1
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
premium_name
Reference:
This RFC Section 3.2
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
domain_rgp
Reference:
This RFC Section 3.3
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
reserved_domain
Reference:
This RFC Section 3.4
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
domain_inventory
Reference:
This RFC Section 3.5
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
contact_inventory
Reference:
This RFC Section 3.6
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
---- BEGIN FORM ----
Name of report:
host_inventory
Reference:
This RFC Section 3.7
Registrant:
IESG, iesg@ietf.org
TLD:
any
Status:
Active
---- END FORM ----
5. Security Considerations
Items to be covered in a future version:
SHOULD NOT expose secret information, e.g., authInfo
This report does not address delivery mechanisms but due
consideration should be given to access of reports. Note encryption
is something to consider for controlling access.
6. Privacy Considerations
Items to be covered in a future version:
Note that reports may contain Personally Identifiable Information
7. Internationalization Considerations 7. Internationalization Considerations
The character encoding for the file contents MUST use UTF-8. The character encoding for the file contents MUST use UTF-8.
Throughout this document A-LABEL is indicated as a SHOULD and that
MUST be interpreted as follows. All domain name labels MUST be in
A-LABEL format if it is possible to represent it as an A-LABEL,
otherwise U-LABEL MAY be used.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO4217] International Organization for Standardization, "ISO 4217
Currency Codes", 2018, <https://www.currency-
iso.org/dam/downloads/lists/list_one.xml>.
[RFC0791] Postel, J., "Internet Protocol", September 1981, [RFC0791] Postel, J., "Internet Protocol", September 1981,
<https://www.rfc-editor.org/info/rfc791>. <https://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4180] Shafranovich, Y., "IP Version 6 Addressing Architecture", [RFC4180] Shafranovich, Y., "IP Version 6 Addressing Architecture",
February 2006, <https://www.rfc-editor.org/info/rfc4180>. February 2006, <https://www.rfc-editor.org/info/rfc4180>.
skipping to change at page 15, line 24 skipping to change at page 32, line 13
<https://www.rfc-editor.org/info/rfc5732>. <https://www.rfc-editor.org/info/rfc5732>.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", August 2009, Contact Mapping", August 2009,
<https://www.rfc-editor.org/info/rfc5733>. <https://www.rfc-editor.org/info/rfc5733>.
[RFC5890] Klensin, J., "Extensible Provisioning Protocol (EPP) [RFC5890] Klensin, J., "Extensible Provisioning Protocol (EPP)
Contact Mapping", August 2009, Contact Mapping", August 2009,
<https://www.rfc-editor.org/info/rfc5890>. <https://www.rfc-editor.org/info/rfc5890>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", June
2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the [RFC8748] Carney, R. and J. Frakes, "Registry Fee Extension for the
Extensible Provisioning Protocol", March 2020, Extensible Provisioning Protocol", March 2020,
<https://www.rfc-editor.org/info/rfc8748>. <https://www.rfc-editor.org/info/rfc8748>.
8.2. Informative References 8.2. Informative References
[IANA_Registrar_IDs] [IANA_Registrar_IDs]
Internet Assigned Numbers Authority, "IANA Assignments - Internet Assigned Numbers Authority, "IANA Assignments -
Registrar IDs", 2020, <https://www.iana.org/assignments/ Registrar IDs", 2020, <https://www.iana.org/assignments/
registrar-ids/registrar-ids.xhtml>. registrar-ids/registrar-ids.xhtml>.
[ISO4217] International Organization for Standardization, "ISO 4217
Currency Codes", 2018, <https://www.currency-
iso.org/dam/downloads/lists/list_one.xml>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999, DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>. <https://www.rfc-editor.org/info/rfc2629>.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003, DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>. <https://www.rfc-editor.org/info/rfc3552>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>. <https://www.rfc-editor.org/info/rfc5226>.
Appendix A. File Naming Convention Appendix A. Acknowledgements
The authors would like to thank Roger Carney, Jody Kolker, and
bestpractices.domains for their reviews and suggestions.
Appendix B. File Naming Convention
TBD on file naming convention suggestion TBD on file naming convention suggestion
Authors' Addresses Authors' Addresses
Joseph Yee (editor) Joseph Yee (editor)
Afilias Afilias
Toronto Toronto
Canada Canada
Email: jyee@afilias.info Email: jyee@afilias.info
James Galvin James Galvin
Afilias Afilias
Horsham, PA Horsham, PA
 End of changes. 83 change blocks. 
126 lines changed or deleted 925 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/