draft-ietf-regext-datadictionary.xml

<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5731 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5731.xml">
<!ENTITY RFC5890 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8499 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml">
<!ENTITY RFC9083 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9083.xml">
]>

<rfc ipr="trust200902" docName="draft-ietf-regext-datadictionary-03" category="std">

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

  <front>
    <title>Registration Data Dictionary</title>

    <author initials="H." surname="Flanagan" fullname="Heather Flanagan" role="editor">
      <organization>Edgemoor Research Institute</organization>
      <address>
        <postal>
          <street></street>
          <city></city>

          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <facsimile></facsimile>
        <email>hlf@sphericalcowconsulting.com</email>

      </address>
    </author>

    <author initials="S." surname="Crocker" fullname="Steve Crocker">
      <organization>Edgemoor Research Institute</organization>
      <address>
        <postal>
          <street></street>
          <city></city>

          <code></code>
          <country></country>
        </postal>
        <phone></phone>
        <facsimile></facsimile>
        <email>steve@shinkuro.com</email>

      </address>
    </author>

    <date year="2022" month="October" day="21"/>

    <area>Applications</area>
    <workgroup></workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>

<t>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 compiles 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.
</t>

    </abstract>
   </front>

   <middle>


<section anchor="introduction" title="Introduction">

<t>The Registration Data Dictionary provides a common set of names and definitions for
  data element that 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.</t>

<t>The data elements in this dictionary 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;
  each element will be versioned in the registry.</t>

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

<t>[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. <eref target="https://www.rfc-editor.org/pipermail/rfc-interest/2015-May/008869.html"/>]</t>

<section anchor="requirements-language" title="Requirements Language">

<t>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 <xref target="RFC2119"/>
  <xref target="RFC8174"/> when, and only when, they appear in all capitals, as
  shown here.</t>

</section>
</section>
<section anchor="data-element-specification" title="Data Element Specification">

<t>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 the syntax of each data element is
specified.</t>

<t>Each data element is assigned to an element type to organize the
taxonomy of the data dictionary.</t>

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

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

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


<section anchor="element-name-domain-name" title="Element name: Domain Name">

<t>This is the name of the object being registered, e.g., the domain name.<xref target="RFC5890"/></t>

<t>See also "domain name" in <xref target="RFC8499"/>.</t>

</section>
<section anchor="element-name-registry" title="Element name: Registry">

<t>The name of the registry.</t>

<t>See also "Registry" in <xref target="RFC8499"/>.</t>

</section>

<section anchor="element-name-ns" title="Element name: NS">
  <t>The authoritative name server for the registration.<xref target="RFC1034"/></t>
  <t>See also "Authoritative server" in <xref target="RFC8499"/></t>
</section>

<section anchor="element-name-reg-creation-date" title="Element name: Registration Creation Date">
  <t>The date and time of the object's creation.</t>
</section>

<section anchor="element-name-reg-expiration-date" title="Element name: Registration Expiration Date">
  <t>The date and time identifying the end of the registration period.</t>
</section>

<section anchor="element-name-reg-updated-date" title="Element name: Registration Updated Date">
  <t>The date and time of the most recent modification of the registration data.</t>

</section>

<section anchor="element-name-reg-transfer-date" title="Element name: Registration Transfer Date">
  <t>The date and time of the most recent successful registration transfer.</t>
</section>

<section anchor="element-name-protection" title="Element name: Protection">
  <t>A description of the rulesets used to offer different levels of protection
  to the registrant. This attribute indicates whether the registration requires
  extra versus normal protection.  In the case of domain name registration, this
  attribute can be used flag the need for additional protection for celebrities,
  politicians, at risk NGOs, etc.</t>
</section>

<section anchor="element-name-nexus" title="Element name: Nexus">

<t>Describes whether the registration is from someone in the correct group,
region, or other qualification required for the registration.</t>

</section>
<section anchor="element-name-person" title="Element name: Person">

<t>Record of whether this registration is for a legal or a natural person.</t>

</section>
<section anchor="element-name-personal" title="Element name: Personal">
  <t>Record of whether this registration may contains personally identifiable
  information, based on the interpretation of applicable laws by the registrar
  or registration authority.</t>

</section>
<section anchor="element-name-status-locks" title="Element name: Status &amp; Locks">

<t>Examples include the EPP (Section 2.3 of <xref target="RFC5731"/>) and RDAP (Section 10.2.2
  of <xref target="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.</t>

</section>
<section anchor="element-name-source-method" title="Element name: Source &amp; Method">

<t>The back pointer from registry to registrant. When registration information
is supplied from another source, this field names that source.</t>

</section>

<section anchor="element-name-user-account-id" title="Element name: User Account ID">

<t>This is a customer ID at the registrar, reseller, or privacy/proxy provider, respectively.</t>

</section>

<section anchor="element-name-name" title="Element name: Name">

<t>Individual name.</t>

</section>
<section anchor="element-name-org" title="Element name: Org">

<t>Organization name.</t>

</section>
<section anchor="element-name-street" title="Element name: Street">

<t>Physical street address.</t>

</section>
<section anchor="element-name-city" title="Element name: City">

<t>Postal city address.</t>

</section>
<section anchor="element-name-stateprovince" title="Element name: State/Province">

<t>Postal state or province address.</t>

</section>
<section anchor="element-name-postal-code" title="Element name: Postal code">

<t>Postal code.</t>

</section>
<section anchor="element-name-country" title="Element name: Country">

<t>Country code identifier.</t>

</section>
<section anchor="element-name-phone" title="Element name: Phone">

<t>Telephone number.</t>

</section>
<section anchor="element-name-phone-ext" title="Element name: Phone ext">

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

</section>
<section anchor="element-name-fax" title="Element name: Fax">

<t>Fax telephone number.</t>

</section>
<section anchor="element-name-fax-ext" title="Element name: Fax ext">

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

</section>
<section anchor="element-name-email" title="Element name: Email">
  <t>Email address.</t>
</section>

<section anchor="element-name-emailorphone" title="Element name: Email_or_phone">
  <t>There is a requirement that either the phone or email element have been
    confirmed reachable, which this field is intended to represent.</t>
</section>

<section anchor="element-name-uniqueid" title="Element name: Registry UniqueID">
  <t>This field represents server-unique identifiers assigned to entities, such
    as clients and contacts.</t>
</section>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

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

<section anchor="report-specification" title="Report Specification">

<t>This registry uses the “Specification Required” policy described in
   <xref target="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.</t>

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

<section anchor="designated-expert-evaluation-criteria" title="Designated Expert
  Evaluation Criteria">

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

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

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

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

</section>
<section anchor="registration-procedure" title="Registration Procedure">

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

<section anchor="required-information" title="Required Information">

<t>The required information must be formatted consistently using the following
  registration form. Form field names and values may appear on the same line.</t>

<section anchor="data-element-definition" title="Data Element Definition">

<t>Name of data element type</t>

<t>
    MUST be unique within the registry, enforced to be unique, and MUST be
    processed as case insensitive
</t>

<t>Name of data element</t>

<t>
    MUST be unique within the registry, enforced to be unique, and MUST be
    processed as case insensitive
</t>

<t>Reference document</t>

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

<t>Registrant</t>

<t>
    Will be IESG for initial entries and all Standards Track specifications;
    otherwise as specified by the registran
</t>

<t>Status</t>

<t>
    MUST be one of active, inactive, or unknown
</t>

</section>
</section>
<section anchor="registration-processing" title="Registration Processing">

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

</section>
<section anchor="updating-report-definition-registry-entries" title="Updating
  Report Definition Registry Entries">

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

</section>
</section>
</section>
<section anchor="initial-assignments" title="Initial assignments">

<section anchor="data-element-definition-in-iana-registry" title="Data Element
  Definition in IANA Registry">

<t>—- BEGIN FORM —-</t>

<t>Name of data element:</t>

<t> Name</t>

<t>Reference:</t>

<t>This RFC Section 2.1.</t>

<t>Registrant:</t>

<t>IESG, iesg@ietf.org</t>

<t>Status:</t>

<t>Active</t>

<t>—- END FORM —-</t>

<t>—- BEGIN FORM —-</t>

<t>Name of data element:</t>

<t>…………</t>

<t>Reference:</t>

<t>This RFC Section $2.n</t>

<t>Registrant:</t>

<t>IESG, iesg@ietf.org</t>

<t>Status:</t>

<t>Active</t>

<t>—- END FORM —-</t>

</section>
</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

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

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

</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

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

</section>
<section anchor="internationalization-considerations" title="Internationalization Considerations">

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

</section>

<section anchor="change-log" title="Draft Change Log">
    <t>-03: Editorial updates to abstract, introduction</t>
    <t>-03: Added definitions to Protection, Nexus, Person, Personal, Source and Method, User Account ID</t>
    <t>-03: Removed Payment History, Transaction History, and Reserved elements.</t>
    <t>-02: Removed all format syntax guidance.</t>
    <t>-02: Removed specific references to domain names and DNS where possible.</t>
    <t>-02: Revised the Introduction.</t>
    <t>-01: Updated abstract to clarify that this draft does not intend to set policy.</t>
    <t>-01: Updated definitions in 2.1, 2.4, 2.5, 2.6, 2.7 to remove normative reference to the EPP spec.</t>
    <t>-01: Updated 2. Data Element specification to note local interpretation expected for any legal definitions.</t>
    <t>-01: Added TBD to policy-related items, all data-related elements wrt format.</t>
    <t>-01: Moved several items from informative to normative references.</t>
</section>


<section anchor="acknowledgements" title="Acknowledgements">

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

</section>

</middle>

<back>
<references title="Informative References">
  &RFC5731;
  &RFC8499;
  &RFC9083;
</references>

<references title="Normative References">
&RFC1034;
&RFC2119;
&RFC5890;
&RFC8126;
&RFC8174;

</references>


</back>
</rfc>