Simple Registration Reporting
Donuts
Toronto
Transaction Report Definition Table
| Data Element |
Reference |
| TLD |
RFC XXXX |
| Server_TRID |
|
| Domain |
|
| DateTime |
|
| Registrar_ID |
|
| Registrar |
|
| Transaction_Type |
|
| Period |
|
| Term |
|
| Fee |
|
| Currency |
|
| Description |
|
Premium Name
Name of report: premium_name
Premium Name Report Definition Table
| Data Element |
Reference |
| TLD |
RFC XXXX |
| Domain |
|
| Status |
|
| Description |
|
| Currency |
|
| Domain_Create |
|
| Domain_Renew |
|
| Domain_Transfer |
|
| Domain_Restore |
|
| Start_Date |
|
Domain RGP
Name of report: domain_rgp
Domain RGP Report Definition Table
| Data Element |
Reference |
| TLD |
RFC XXXX |
| Domain |
|
| Deleted_Date |
|
| RGP_Date |
|
| Purge_Date |
|
Reserved Domain
Name of report: reserved_domain
Reserved Domain Report Definition Table
| Data Element |
Reference |
| TLD |
RFC XXXX |
| Domain |
|
| Status |
|
Domain Inventory
Name of report: domain_inventory
Domain Inventory Report Definition Table
| Data Element |
Reference |
| TLD |
RFC XXXX |
| Domain |
|
| Updated_Date |
|
| Registrar_ID |
|
| Create_Date |
|
| Expiry_Date |
|
| Server_Registrant_ID |
|
| DNSSEC |
|
| Status |
|
Contact Inventory
Name of report: contact_inventory
Contact Inventory Report Definition Table
| Data Element |
Reference |
| Server_Contact_ID |
|
| Client_Contact_ID |
|
| TLD |
|
| Domain |
|
| Contact_Type |
|
| Contact_Name |
|
| Updated_Date |
|
| INUSE |
|
| Registrar_ID |
|
Host Inventory
Name of report: host_inventory
Host Inventory Report Definition Table
| Data Element |
Reference |
| TLD |
RFCXXXX |
| Nameserver_Host |
|
| Nameserver_IP |
|
IANA Considerations
This section describes the format of the IANA Registration Report Registry, which has two tables described below, and the procedures used to populate and manage the registry entries.
Report Specification
This registry uses the "Specification Required" policy described in
RFC 8126. An English language version of the extension specification is required in the registry, though non-English versions of the specification may also be provided.
The "Specification Required" policy implies review by a "designated expert". Section 5.2 of RFC 8126 describes the role of designated experts and the function they perform.
Designated Expert Evaluation Criteria
A high-level description of the role of the designated expert is described
in Section 5.2 of RFC 8126. Specific guidelines for the appointment of designated experts and the evaluation of a Registration Report is provided here.
The IESG SHOULD appoint a small pool of individuals (perhaps 3 - 5)
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 data element 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 data elements and reports that have been implemented and
deployed by at least one registry. This implies that
it may indeed be possible to register multiple data elements or reports that
provide the same functionality. Requests to register data elements 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 data element or report that includes similar
functionality to existing data elements or reports should be made
aware of the existing data elements and reports. The registrant should be asked to
reconsider their request given the existence of similar data elements 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.
Registration Procedure
The registry contains information describing each registered
data element or report. Registry entries are created and managed by sending forms
to IANA that describe the data element or report for the registry entry.
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.
Data Element Definition
- Name of data element
- MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive
- Reference document
- MUST define the data element, SHOULD be a URL to a RFC, and SHOULD include the section number (or other detailed internal document reference), MAY be a URL to any document available under equivalent terms
- Registrant
- Will be IESG for initial entries and all Standards Track specifications; otherwise as specified by the registran
- Status
- MUST be one of active, inactive, or unknown
Report Definition
- Name of Report
- MUST be unique within the registry, enforced to be unique, and MUST be processed as case insensitive
- Document Status
- MUST be one of active, inactive, or unknown
- Reference document
- MUST define the report, SHOULD be a URL to a RFC and SHOULD include the section number (or other detailed internal document reference), MAY be a URL to any document available under equivalent terms
- Registrant
- Will be IESG for initial entries and all Standards Track specifications; otherwise as specified by the registrant
- TLD
- MUST be “ANY” if the report is intended to be generally applicable or MAY be any top level domain formatted as defined by RFC 5890 [RFC5890] (or comma separated list of domains) and each MUST be an A-LABEL if the report is intended to have that scope
- Status:active
Registration Processing
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
in consultation with the regext mailing list.
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.
Initial assignments
Data Element Definition in IANA Registry
- ---- BEGIN FORM ----
- Name of data element:
- TLD
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Server_TRID
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Domain
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Transaction_Type
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Ojbect_Type
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- DateTime
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Term
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Currency
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Status
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Registrar
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Period
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Description
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Domain_Create
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Domain_Renew
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Domain_Transfer
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Domain_Restore
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Start_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Deleted_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- RGP_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Purge_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Updated_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Create_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Expiry_Date
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Registrar_ID
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Server_Registrant_ID
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- DNSSEC
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Server_Contact_ID
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Contact_Type
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Contact_Name
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- INUSE
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Nameserver_Host
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Nameserver_IP
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of data element:
- Client_Contact_ID
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- Status:
- Active
- ---- END FORM ----
Report Definition in IANA Registry
- ---- BEGIN FORM ----
- Name of report:
- domain_transaction
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- premium_name
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- domain_rgp
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- reserved_domain
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- domain_inventory
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- contact_inventory
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
- ---- BEGIN FORM ----
- Name of report:
- host_inventory
- Reference:
- This RFC
- Registrant:
- IESG, iesg@ietf.org
- TLD:
- any
- Status:
- Active
- ---- END FORM ----
Security Considerations
This specification does not consider the issues of distribution or access to the reports that are created and thus does not introduce any new security security concerns that are not already present in the local environment in which the report is created.
A security principle to keep in mind as new reports are developed is that it is considered a bad practice to report or disclose security information. In the case of the registration system upon which this reporting mechanism is based, the authInfo code is a specific example of a data element that SHOULD NOT be included in a report.
Privacy Considerations
This specification defines a mechanism for creating reports based on data in a registration system. Some of that data is likely to be considered personally identifiable information (PII) and thus would be subject to privacy protection according to an applicable privacy regulation. It is outside the scope of this specification to address those specific concerns. Implementors are urged to consider these issues with their local legal authority and develop appropriate requirements for their work.
As expressly noted in the Introduction, distribution of and access to the reports created by this specification is expressly outside the scope of this specification. However, to the extent a report contains PII, implementors are urged to consider these issues with their local legal authority and develop appropriate requirements for their work.
Internationalization Considerations
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.
References
Normative References
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Internet Protocol
IP Version 6 Addressing Architecture
IP Version 6 Addressing Architecture
Extensible Provisioning Protocol (EPP)
Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extensible Provisioning Protocol (EPP) Host Mapping
Extensible Provisioning Protocol (EPP) Contact Mapping
Extensible Provisioning Protocol (EPP) Contact Mapping
Guidelines for Writing an IANA Considerations Section in RFCs
Registry Fee Extension for the Extensible Provisioning Protocol
ISO 4217 Currency Codes
International Organization for Standardization
Informative References
Writing I-Ds and RFCs using XML
This memo presents a technique for using XML (Extensible Markup Language) as a source format for documents in the Internet-Drafts (I-Ds) and Request for Comments (RFC) series. This memo provides information for the Internet community.
Guidelines for Writing RFC Text on Security Considerations
All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Guidelines for Writing an IANA Considerations Section in RFCs
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
IANA Assignments - Registrar IDs
Internet Assigned Numbers Authority
Acknowledgements
The authors would like to thank Roger Carney, Jody Kolker, Tobias Sattler, and bestpractice.domains for their reviews and suggestions.
File Naming Convention
TBD on file naming convention suggestion