Registration Data Dictionary
draft-ietf-regext-datadictionary-01

Network Working Group                                   H. Flanagan, Ed.
Internet-Draft                                                S. Crocker
Intended status: Standards Track             Edgemoor Research Institute
Expires: 8 September 2022                                   7 March 2022

                      Registration Data Dictionary
                  draft-ietf-regext-datadictionary-01

Abstract

   Multiple applications related to the registration of names and other
   identifiers 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 Data Dictionary to be maintained as an
   independent IANA Registry.  The Data Dictionary defines data elements
   but does not specify which ones are to be used in any particular
   application; the Data Dictionary is policy-neutral.

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 8 September 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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

Flanagan & Crocker      Expires 8 September 2022                [Page 1]
Internet-Draft        Registration Data Dictionary            March 2022

   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  . . . . . . . .   5
     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 . . . . . . . . . . . . . .   6
     2.14. Element name: Payment History . . . . . . . . . . . . . .   6
     2.15. Element name: Transaction History . . . . . . . . . . . .   6
     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  . . . . . . . . . . . . . .   7
     2.23. Element name: Postal code . . . . . . . . . . . . . . . .   7
     2.24. Element name: Country . . . . . . . . . . . . . . . . . .   7
     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 . . . . . . . . . . . . . . . . . . .   8
     2.30. Element name: Email_or_phone  . . . . . . . . . . . . . .   8
     2.31. Element name: Registry UniqueID . . . . . . . . . . . . .   8
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  Report Specification  . . . . . . . . . . . . . . . . . .   8
       3.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   8
       3.1.2.  Registration Procedure  . . . . . . . . . . . . . . .   9
     3.2.  Initial assignments . . . . . . . . . . . . . . . . . . .  11
       3.2.1.  Data Element Definition in IANA Registry  . . . . . .  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12

Flanagan & Crocker      Expires 8 September 2022                [Page 2]
Internet-Draft        Registration Data Dictionary            March 2022

   6.  Internationalization Considerations . . . . . . . . . . . . .  12
   7.  Draft Change Log  . . . . . . . . . . . . . . . . . . . . . .  12
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Informative References  . . . . . . . . . . . . . . . . .  13
     9.2.  Normative References  . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

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 8 September 2022                [Page 3]
Internet-Draft        Registration Data Dictionary            March 2022

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.

   Note that the legal definition of any of the terms used in the data
   dictionary, such as 'personally identifiable information' or 'legal
   person', are to be determined locally.  The organization using this
   dictionary will record their interpretation in the appropriate
   element.

2.1.  Element name: Domain Name

   This is the domain name as formatted according to the
   Internationalized Domain Names for Applications (IDNA)
   specification.[RFC5890]

   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]

Flanagan & Crocker      Expires 8 September 2022                [Page 4]
Internet-Draft        Registration Data Dictionary            March 2022

2.4.  Element name: Registration Creation Date

   The the date and time of domain object creation.  Format TBD.

2.5.  Element name: Registration Expiration Date

   The date and time identifying the end of the domain object's
   registration period.  Format TBD.

2.6.  Element name: Registration Updated Date

   The date and time of the most recent domain-object modification.
   Format TBD.

2.7.  Element name: Registration Transfer Date

   The date and time of the most recent successful domain-object
   transfer.  Format TBD.

2.8.  Element name: Protection

   Definition is TBD.

2.9.  Element name: Nexus

   Definition is TBD.

2.10.  Element name: Person

   Definition is TBD.

2.11.  Element name: Personal

   Definition is TBD.

2.12.  Element name: Status & Locks

   Examples include the EPP (Section 2.3 of [RFC5731]) and RDAP
   (Section 10.2.2 of [RFC9083]) codes (ex: clientTransferProhibited)
   that describe the current state of a registered domain name and the
   protocol actions that can (or cannot) be performed on the domain
   name.  A registered domain name MAY be associated with multiple
   status values.  Other managed objects, including name server and
   contact objects, can also have status and lock values.

Flanagan & Crocker      Expires 8 September 2022                [Page 5]
Internet-Draft        Registration Data Dictionary            March 2022

2.13.  Element name: Source & Method

   Definition is TBD.

2.14.  Element name: Payment History

   Definition is TBD.

2.15.  Element name: Transaction History

   Definition is TBD.

2.16.  Element name: User Account ID

   Definition is TBD.

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].

Flanagan & Crocker      Expires 8 September 2022                [Page 6]
Internet-Draft        Registration Data Dictionary            March 2022

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].

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.

Flanagan & Crocker      Expires 8 September 2022                [Page 7]
Internet-Draft        Registration Data Dictionary            March 2022

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.

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.

Flanagan & Crocker      Expires 8 September 2022                [Page 8]
Internet-Draft        Registration Data Dictionary            March 2022

   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
   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.

Flanagan & Crocker      Expires 8 September 2022                [Page 9]
Internet-Draft        Registration Data Dictionary            March 2022

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

   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.

Flanagan & Crocker      Expires 8 September 2022               [Page 10]
Internet-Draft        Registration Data Dictionary            March 2022

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.

   Registrant:

   IESG, iesg@ietf.org

   Status:

   Active

   --- END FORM ---

   --- BEGIN FORM ---

   Name of data element:

   ............

   Reference:

Flanagan & Crocker      Expires 8 September 2022               [Page 11]
Internet-Draft        Registration Data Dictionary            March 2022

   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.

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.  Draft Change Log

   -01: Updated abstract to clarify that this draft does not intend to
   set policy.

Flanagan & Crocker      Expires 8 September 2022               [Page 12]
Internet-Draft        Registration Data Dictionary            March 2022

   -01: Updated definitions in 2.1, 2.4, 2.5, 2.6, 2.7 to remove
   normative reference to the EPP spec.

   -01: Updated 2.  Data Element specification to note local
   interpretation expected for any legal definitions.

   -01: Added TBD to policy-related items, all data-related elements wrt
   format.

   -01: Moved several items from informative to normative references.

8.  Acknowledgements

   With many thanks to James Galvin and Rod Rasmussen for their advice
   and feedback on this data dictionary.

9.  References

9.1.  Informative References

   [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>.

   [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>.

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

9.2.  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.

Flanagan & Crocker      Expires 8 September 2022               [Page 13]
Internet-Draft        Registration Data Dictionary            March 2022

   [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>.

   [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>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [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>.

Authors' Addresses

   Heather Flanagan (editor)
   Edgemoor Research Institute
   Email: hlf@sphericalcowconsulting.com

   Steve Crocker
   Edgemoor Research Institute
   Email: steve@shinkuro.com

Flanagan & Crocker      Expires 8 September 2022               [Page 14]