Network Working Group                                   H. Flanagan, Ed.
Internet-Draft                                                S. Crocker
Intended status: Standards Track             Edgemoor Research Institute
Expires: 6 January 2023                                      5 July 2022


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

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 6 January 2023.

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 6 January 2023                 [Page 1]


Internet-Draft        Registration Data Dictionary             July 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 . . . . . . . . . . . . . .   5
     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  . . . . . . . . . . . . . .   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 . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Report Specification  . . . . . . . . . . . . . . . . . .   7
       3.1.1.  Designated Expert Evaluation Criteria . . . . . . . .   8
       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  . . . . . . . . . . . . . . . . . . .  11



Flanagan & Crocker       Expires 6 January 2023                 [Page 2]


Internet-Draft        Registration Data Dictionary             July 2022


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

1.  Introduction

   The Registration Data Dictionary provides a common set of names and
   definitions for data elements which may be used in any registration
   protocol, including the DNS.  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 metadata regarding the registration, the
   detailed status of a registration, details for each of the contacts,
   and the account details and payment history.  The proposed IANA
   registry lists standard data elements and is each element will be
   versioned in the registry.

   We expect the Registration Data Dictionary to evolve to meet the
   needs of various applications.  With the exception of correction of
   errors, we expect the changes to the Registration 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 6 January 2023                 [Page 3]


Internet-Draft        Registration Data Dictionary             July 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 name of the object being registered, e.g., the domain
   name.[RFC5890]

   See also " name" in [RFC8499].

2.2.  Element name: Registry

   The name of the registry.

   See also "Registry" in [RFC8499].

2.3.  Element name: NS

   The authoritative name server for the registration.[RFC1034]

   See also "Authoritative server" in [RFC8499]






Flanagan & Crocker       Expires 6 January 2023                 [Page 4]


Internet-Draft        Registration Data Dictionary             July 2022


2.4.  Element name: Registration Creation Date

   The the date and time of the object's creation.

2.5.  Element name: Registration Expiration Date

   The date and time identifying the end of the registration period.

2.6.  Element name: Registration Updated Date

   The date and time of the most recent modification of the registration
   data.

2.7.  Element name: Registration Transfer Date

   The date and time of the most recent successful registration
   transfer.

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 object and the
   protocol actions that can (or cannot) be performed on the registered
   object.  A registered object MAY be associated with multiple status
   values.  Other managed objects, including name server and contact
   objects, can also have status and lock values.

2.13.  Element name: Source & Method

   Definition is TBD.




Flanagan & Crocker       Expires 6 January 2023                 [Page 5]


Internet-Draft        Registration Data Dictionary             July 2022


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.

2.19.  Element name: Org

   Organization name is represented using character strings.

2.20.  Element name: Street

   Postal street address.

2.21.  Element name: City

   Postal city address.

2.22.  Element name: State/Province

   Postal state or province address.

2.23.  Element name: Postal code

   Postal code.

2.24.  Element name: Country

   Country code identifier.







Flanagan & Crocker       Expires 6 January 2023                 [Page 6]


Internet-Draft        Registration Data Dictionary             July 2022


2.25.  Element name: Phone

   Telephone number.

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.

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.

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.

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.




Flanagan & Crocker       Expires 6 January 2023                 [Page 7]


Internet-Draft        Registration Data Dictionary             July 2022


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







Flanagan & Crocker       Expires 6 January 2023                 [Page 8]


Internet-Draft        Registration Data Dictionary             July 2022


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

   Status

   MUST be one of active, inactive, or unknown











Flanagan & Crocker       Expires 6 January 2023                 [Page 9]


Internet-Draft        Registration Data Dictionary             July 2022


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:

   Name

   Reference:

   This RFC Section 2.1.

   Registrant:

   IESG, iesg@ietf.org



Flanagan & Crocker       Expires 6 January 2023                [Page 10]


Internet-Draft        Registration Data Dictionary             July 2022


   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.

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



Flanagan & Crocker       Expires 6 January 2023                [Page 11]


Internet-Draft        Registration Data Dictionary             July 2022


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

   -02: Removed all format syntax guidance.

   -02: Removed specific references to domain names and DNS where
   possible.

   -02: Revised the Introduction.

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

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





Flanagan & Crocker       Expires 6 January 2023                [Page 12]


Internet-Draft        Registration Data Dictionary             July 2022


   [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

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

   [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 6 January 2023                [Page 13]