Re: [DNSOP] Proposal: Whois over DNS

[John Bambenek <[e-mail]>]

I generally agree with this and have no problem deferring to an effort
to create a dictionary of registration data elements and agreed upon
definitions.

I gave serious thought to just making the current proposal have one
contact class, I kept several more for consistency with the legacy
system, but I'm not married to that.

On 7/9/19 11:26 AM, Steve Crocker wrote:
> 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
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop