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