Internet DRAFT - draft-flanagan-regext-datadictionary
draft-flanagan-regext-datadictionary
Network Working Group H. Flanagan, Ed.
Internet-Draft S. Crocker
Intended status: Standards Track Edgemoor Research Institute
Expires: 22 May 2022 18 November 2021
DNS Data Dictionary
draft-flanagan-regext-datadictionary-01
Abstract
Multiple applications related to the domain name system are built
around a list of data elements. There is currently no unified public
list of these data elements, nor is there an organized and
independent change control process. This document codifies the
multiple similar but not quite identical lists of data elements into
a neutral DNS Data Dictionary to be maintained as an independent IANA
Registry.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 22 May 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Flanagan & Crocker Expires 22 May 2022 [Page 1]
Internet-Draft DNS Data Dictionary November 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Data Element Specification . . . . . . . . . . . . . . . . . 4
2.1. Element name: Domain Name . . . . . . . . . . . . . . . . 4
2.2. Element name: Registry . . . . . . . . . . . . . . . . . 4
2.3. Element name: NS . . . . . . . . . . . . . . . . . . . . 4
2.4. Element name: Registration Creation Date . . . . . . . . 4
2.5. Element name: Registration Expiration Date . . . . . . . 5
2.6. Element name: Registration Updated Date . . . . . . . . . 5
2.7. Element name: Registration Transfer Date . . . . . . . . 5
2.8. Element name: Protection . . . . . . . . . . . . . . . . 5
2.9. Element name: Nexus . . . . . . . . . . . . . . . . . . . 5
2.10. Element name: Person . . . . . . . . . . . . . . . . . . 5
2.11. Element name: Personal . . . . . . . . . . . . . . . . . 5
2.12. Element name: Status & Locks . . . . . . . . . . . . . . 5
2.13. Element name: Source & Method . . . . . . . . . . . . . . 5
2.14. Element name: Payment History . . . . . . . . . . . . . . 5
2.15. Element name: Transaction History . . . . . . . . . . . . 5
2.16. Element name: User Account ID . . . . . . . . . . . . . . 6
2.17. Element name: Reserved . . . . . . . . . . . . . . . . . 6
2.18. Element name: Name . . . . . . . . . . . . . . . . . . . 6
2.19. Element name: Org . . . . . . . . . . . . . . . . . . . . 6
2.20. Element name: Street . . . . . . . . . . . . . . . . . . 6
2.21. Element name: City . . . . . . . . . . . . . . . . . . . 6
2.22. Element name: State/Province . . . . . . . . . . . . . . 6
2.23. Element name: Postal code . . . . . . . . . . . . . . . . 6
2.24. Element name: Country . . . . . . . . . . . . . . . . . . 6
2.25. Element name: Phone . . . . . . . . . . . . . . . . . . . 7
2.26. Element name: Phone ext . . . . . . . . . . . . . . . . . 7
2.27. Element name: Fax . . . . . . . . . . . . . . . . . . . . 7
2.28. Element name: Fax ext . . . . . . . . . . . . . . . . . . 7
2.29. Element name: Email . . . . . . . . . . . . . . . . . . . 7
2.30. Element name: Email_or_phone . . . . . . . . . . . . . . 7
2.31. Element name: Registry UniqueID . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
3.1. Report Specification . . . . . . . . . . . . . . . . . . 8
3.1.1. Designated Expert Evaluation Criteria . . . . . . . . 8
Flanagan & Crocker Expires 22 May 2022 [Page 2]
Internet-Draft DNS Data Dictionary November 2021
3.1.2. Registration Procedure . . . . . . . . . . . . . . . 9
3.2. Initial assignments . . . . . . . . . . . . . . . . . . . 10
3.2.1. Data Element Definition in IANA Registry . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
6. Internationalization Considerations . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
The DNS Data Dictionary provides a common set of names and
definitions for data elements which may be used in a DNS related
protocol. The dictionary is intended to be inclusive and not
obligatory. That is, the existence of a data element in this
dictionary does not imply the data element must be used or recognized
in any particular protocol. The items in this dictionary should
represent the union for what is in existing relevant protocols, and
should prevent divergence in new protocols. We also expect that each
application or protocol may have additional requirements specific to
the application or protocol. Such additional requirements should be
documented as part of the application or protocol specification.
The data dictionary currently has thirty-one data elements. These
data elements include the DNS records, the detailed status of a
registration to the details for each of the contacts, and the account
details and payment history. The proposed IANA registry lists
standard data elements and their syntax for inclusion in the files.
We expect the DNS data dictionary to evolve to meet the needs of
various applications. With the exception of correction of errors, we
expect the changes to the DNS Data Dictionary to be additions as
opposed to deletions or changes.
[Comment: We are looking for additional authors and contributors to
add to and improve the data dictionary, keeping in line with the RFC
Series Editor statement on authorship. https://www.rfc-
editor.org/pipermail/rfc-interest/2015-May/008869.html]
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Flanagan & Crocker Expires 22 May 2022 [Page 3]
Internet-Draft DNS Data Dictionary November 2021
2. Data Element Specification
Each data element is a single unit of information that can be
collected and compared during the registration process. The primary
purposes of 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 specified.
Each data element is assigned to an element type to organize the
taxonomy of the data dictionary.
The name of the data element MUST be unique and this characteristic
MUST be enforced by the registry. The character encoding
recommendation for data elements is specified in Section 3.
The subsections below comprise an initial list of known data elements
commonly being used in the templates. The title of the subsection is
the data element name for the data element. The combination of data
element type and data element name MUST be unique and MUST be
processed as case insensitive in the IANA registry.
2.1. Element name: Domain Name
This is the domain name in an EPP [RFC5731] domain object and it MUST
be in A-Label format.
See also "Domain name" in [RFC8499].
2.2. Element name: Registry
The name of the registry. This data element is text/string with no
naming convention enforced.
See also "Registry" in [RFC8499].
2.3. Element name: NS
The authoritative name server for the domain.[RFC1034]
See also "Authoritative server" in [RFC8499]
2.4. Element name: Registration Creation Date
The EPP status code (<domain:crDate>) for the domain registration
creation date.[RFC5731]
Flanagan & Crocker Expires 22 May 2022 [Page 4]
Internet-Draft DNS Data Dictionary November 2021
2.5. Element name: Registration Expiration Date
The EPP status code (<domain:exDate>) for the domain registration
expiration date.[RFC5731]
2.6. Element name: Registration Updated Date
The EPP status code (<domain:upDate>) for the domain registration
updated date.[RFC5731]
2.7. Element name: Registration Transfer Date
The EPP status code (<domain:trDate>) for the domain registration
transfer date.[RFC5731]
2.8. Element name: Protection
The level of protection assigned to a domain registration.
2.9. Element name: Nexus
The country, community, or geographic location of the account holder.
2.10. Element name: Person
Indication that the rules regarding this registration apply as per
the registrant being a legal person or a natural person.
2.11. Element name: Personal
2.12. Element name: Status & Locks
The EPP Status codes (ex: clientTransferProhibited) related to
domain.[RFC5731]
2.13. Element name: Source & Method
The back pointer from registry to registrant.
2.14. Element name: Payment History
Information related to the customer's financial exchanges.
2.15. Element name: Transaction History
[Is this same as 2.4.2?]
Flanagan & Crocker Expires 22 May 2022 [Page 5]
Internet-Draft DNS Data Dictionary November 2021
2.16. Element name: User Account ID
This is a customer ID at the registrar, reseller, or privacy/proxy
provider, respectively.
2.17. Element name: Reserved
[this field is an artifact of prior use which was determined to not
be necessary, but the field was left intact for future use]
2.18. Element name: Name
Individual name is represented using character strings. These
strings have a specified minimum length and a specified maximum
length. Individual names MAY be provided in either UTF-8 [RFC3629]
or a subset of UTF-8 that can be represented in 7-bit ASCII,
depending on local needs.
2.19. Element name: Org
Organization name is represented using character strings. These
strings have a specified minimum length and a specified maximum
length. Organizational names MAY be provided in either UTF-8
[RFC3629] or a subset of UTF-8 that can be represented in 7-bit
ASCII, depending on local needs.
2.20. Element name: Street
Postal street address, formatted as per [ISO19160-4].
2.21. Element name: City
Postal city address, formatted as per [ISO19160-4].
2.22. Element name: State/Province
Postal state or province address, formatted as per [ISO19160-4].
2.23. Element name: Postal code
Postal code, formatted as per [ISO19160-4]. Contact postal codes are
represented using character strings. These strings have a specified
minimum length and a specified maximum length.
2.24. Element name: Country
Country code identifier. Contact country identifiers are represented
using two-character identifiers specified in [ISO3166-1].
Flanagan & Crocker Expires 22 May 2022 [Page 6]
Internet-Draft DNS Data Dictionary November 2021
2.25. Element name: Phone
Telephone number structure is derived from structures defined in
[ITU.E164.2005]. Telephone numbers described in this mapping are
character strings that MUST begin with a plus sign ("+", ASCII value
0x002B), followed by a country code defined in [ITU.E164.2005],
followed by a dot (".", ASCII value 0x002E), followed by a sequence
of digits representing the telephone number. An optional "x"
attribute is provided to note telephone extension information.
2.26. Element name: Phone ext
This field is intended to represent an "extension" within the phone
number to reach the specific person or role desk telephone,
appropriate queue or mailbox after successfully dialing the Phone
element.
2.27. Element name: Fax
Fax telephone number structure is derived from structures defined in
[ITU.E164.2005]. Telephone numbers described in this mapping are
character strings that MUST begin with a plus sign ("+", ASCII value
0x002B), followed by a country code defined in [ITU.E164.2005],
followed by a dot (".", ASCII value 0x002E), followed by a sequence
of digits representing the telephone number.
2.28. Element name: Fax ext
This field is an "extension" within a phone tree or PBX that is
necessary to connect to a fax machine after successfully dialing the
fax element.
2.29. Element name: Email
Email address syntax is defined in [RFC5322].
2.30. Element name: Email_or_phone
There is a requirement that either the phone or email element have
been confirmed reachable, which this field is intended to represent.
2.31. Element name: Registry UniqueID
This field represents server-unique identifiers assigned to entities,
such as clients and contacts. These identifiers are character
strings that typically have a specified minimum length, a specified
maximum length, and a specified format.
Flanagan & Crocker Expires 22 May 2022 [Page 7]
Internet-Draft DNS Data Dictionary November 2021
3. 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.
3.1. Report Specification
This registry uses the "Specification Required" policy described in
[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.
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.
3.1.1. 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 new data
element 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. 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
Flanagan & Crocker Expires 22 May 2022 [Page 8]
Internet-Draft DNS Data Dictionary November 2021
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.
3.1.2. 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.
3.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.
3.1.2.1.1. Data Element Definition
Name of data element type
MUST be unique within the registry, enforced to be unique, and MUST
be processed as case insensitive
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
Flanagan & Crocker Expires 22 May 2022 [Page 9]
Internet-Draft DNS Data Dictionary November 2021
Status
MUST be one of active, inactive, or unknown
3.1.2.2. 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 Section 3.1.1 in consultation with the regext mailing
list.
3.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.
3.2. Initial assignments
3.2.1. Data Element Definition in IANA Registry
--- BEGIN FORM ---
Name of data element:
Domain Name
Reference:
This RFC Section 2.1.
Flanagan & Crocker Expires 22 May 2022 [Page 10]
Internet-Draft DNS Data Dictionary November 2021
Registrant:
IESG, iesg@ietf.org
Status:
Active
--- END FORM ---
--- BEGIN FORM ---
Name of data element:
............
Reference:
This RFC Section $2.n
Registrant:
IESG, iesg@ietf.org
Status:
Active
--- END FORM ---
4. 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 oncerns 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.
Flanagan & Crocker Expires 22 May 2022 [Page 11]
Internet-Draft DNS Data Dictionary November 2021
5. Privacy Considerations
This specification defines a mechanism for policy comparison 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.
6. 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.
7. Acknowledgements
With many thanks to James Galvin and Rod Rasmussen for their advice
and feedback on this data dictionary.
8. Normative References
[ISO19160-4]
International Organization for Standardization,
"ISO19160-4: Addressing — Part 4: International postal
address components and template language", November 2017.
[ISO3166-1]
International Organization for Standardization,
"ISO3166-1: Codes for the representation of names of
countries and their subdivisions -- Part1: Country codes",
November 2006.
[ITU.E164.2005]
International Telecommunication Union, "ITU-T
Recommendation E.164: The international public
telecommunication numbering plan", February 2005.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
Flanagan & Crocker Expires 22 May 2022 [Page 12]
Internet-Draft DNS Data Dictionary November 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Domain Name Mapping", STD 69, RFC 5731,
DOI 10.17487/RFC5731, August 2009,
<https://www.rfc-editor.org/info/rfc5731>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
Authors' Addresses
Heather Flanagan (editor)
Edgemoor Research Institute
Email: hlf@sphericalcowconsulting.com
Steve Crocker
Edgemoor Research Institute
Email: steve@shinkuro.com
Flanagan & Crocker Expires 22 May 2022 [Page 13]
