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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
