[DNSOP] Proposal: Whois over DNS

[Steve Crocker <[e-mail]>]

Folks,

Let me share a somewhat broader perspective.  I was chair of the ICANN
board for several years.  During that period, I attempted, without success,
to reset the dialog related to whois.  After I stepped off the board in
late 2017, I decided to take another run at the problem.  I've been working
quietly with a small, excellent group to see if we can provide some useful
tools for assisting the community in thinking about the policy issues.  Our
first goal is to provide a policy framework for expressing the wide variety
of policies in this area, both existing and proposed.  We're not quite
ready to release this framework, but it's coming along and I hope to be
able to publish it shortly.  That said, I can share a few points.

   1.  "Whois" is a somewhat ill-fitting handle.  The policy problems
   extend beyond contact data to include quite few other types of data, some
   of which are inherently public such as the DNS records, some of which are
   inherently extremely sensitive such credit card numbers, and others which
   fall somewhere in between such as dates of registration and expiration.

   I'll also note that WHOIS arose in the days of the Arpanet, prior to the
   existence of the domain name system and prior to the Internet.  The admin
   and tech contacts referred to the people running the time-shared systems
   that were hosts on the Arpanet, and these contacts were published so they
   could reach each other.  Almost fifty years later and a millionfold
   expansion, it's not a surprise the original concepts are not a perfect fit.

   2. Of the various contacts that are usually published, only the
   registrant contact has any real meaning.  For most registrations, the admin
   and tech contacts have no agreed upon meaning.  By "an agreed upon meaning"
   I mean an explicit statement of the authority (what the contact may do) and
   responsibility (what the contact is supposed to do) so that both the
   contact and everyone who accesses the contact data would share the same
   understanding.

   One of the most important roles in the entire structure is the person
   who has the account with the registrar and therefore has direct, electronic
   control of all the data.  We use the term "account holder" for this role.
   It may or may not be the same as the registrant.

   Other contact data is occasionally published, e.g. billing contact,
   legal contact, etc.  While the meaning of these roles is alluded to in the
   name, there is usually nothing explicit about authority and responsibility.

   3. The policy issues related to all of this are quite tangled.  The
   registrar and the registrar are the primary parties involved.  The
   blazingly simple and obvious fact is that neither of these parties have any
   trouble with the accuracy or meaning of the data they share with
each other *that
   are related to the actual process of registration*.  The registrar is
   primarily concerned with getting paid and the registrant is primarily
   concerned with having his registration active.  The trouble comes from the
   many third parties who have developed practices and policies related to the
   registration data.  A full discussion of these multiple parties, their
   motivations and needs, and the wide variety of policy issues requires much
   more space and attention than is appropriate for this note and this thread,
   but a couple of specific points are relevant and worth emphasizing.

   4. It's important to separate (a) the definition of the data elements,
   (b) the policies governing who should have access to which data elements,
   and (c) the access mechanisms.  As I said in an earlier note, the proposal
   being discussed in this thread, viz to use DNS to publish contact data,
   speaks to only a small portion of the overall problem.  Because the
   proposed mechanism is DNS, the data will presumably be public and provided
   at the discretion of the registrant.   This is useful for some purposes,
   but it clearly does not address the larger policies issues of allowing
   different groups to have differing levels of access to various types of
   data.

   5. With respect to the role of the IETF, I agree the policy issues
   belong elsewhere.  That said, there is, I believe, a natural role for the
   IETF that matches one part of the current proposal.  All parties will
   benefit if there is a dictionary of the possible registration data
   elements.  As I suggested in point 1 above, the relevant data elements
   include more than just contact data.  And even with respect to contact
   data, a more precise definition of the various roles would be quite helpful.

   The distinction implied here is the separation of the definition of the
   data elements from the publication mechanism.

I would strongly support an effort within the IETF to create and maintain a
dictionary of registration data elements.  This would probably be in the
form of an IANA-maintained registry, with oversight from DNSOP.

Steve