[gnso-rds-pdp-wg] We should not build atop whois (was Re: Domain Name Certification )

David Cake dave at davecake.net
Wed Jan 10 17:40:29 UTC 2018


I thoroughly support Holly here. We should all use the SAC 51 terminology, because it removes confusion about protocol vs RDS. 

Sent from my iPad

> On 10 Jan 2018, at 8:42 pm, Paul Keating <Paul at law.es> wrote:
> 
> Andrew,
> 
> As I see it, your comments are addressing the technical underpinnings of
> WHOIS and not the DATA.  I believe that the others are addressing the data
> and the continuing need of other systems to continue to access the data.
> 
> Paul
> 
> 
> On 1/10/18, 12:29 AM, "gnso-rds-pdp-wg on behalf of Andrew Sullivan"
> <gnso-rds-pdp-wg-bounces at icann.org on behalf of ajs at anvilwalrusden.com>
> wrote:
> 
>>> On Tue, Jan 09, 2018 at 10:40:19PM +0000, benny at nordreg.se wrote:
>>> 
>>> My point is that the purpose for collecting data to RDS should not be
>>> build upon the needs for other systems build on top the present Whois
>> 
>> If that's what you think, then I believe we disagree very strongly.
>> Many of the problems with respect to the registration databases and
>> with respect to regisration data directory services can be traced
>> directly to the problems with whois.  It seems to me that this litany
>> has been recited before (more than once by me), so those who remember
>> it can stop reading; but to remind people what I'm talking about with
>> respect to these data and policy problems, here are a few:
>> 
>>   1.  WHOIS was designed in an era when the entire names registry
>>   was completely centralised, in the NIC.  So, it did not need to
>>   become a distributed system, and it wasn't designed for
>>   distributed operation.  (To be clear: the NICNAME specfication is
>>   in RFC 812, which is dated March 1982.  The first DNS
>>   specification is in RFC 882, from November of 1983.  NICNAME
>>   didn't have to deal with a distributed database _at all_: it was
>>   about the HOSTS.TXT file and the related metadata.  Obviously,
>>   people knew DNS was coming, but it wasn't a thing yet.)
>> 
>>   2.  Adding references to whois in order to make a distributed
>>   protocol -- rwhois, whois++, and some other flavours -- never
>>   really worked.  This meant that it was unreliable which
>>   (registrar) database you'd get some whois information from, which
>>   meant you often got stale data from the wrong registrar.  This,
>>   more than anything else, was the incentive behind "thick"
>>   registries, which is why registries ended up having information
>>   about registrants, with whom they do not strictly speaking have a
>>   direct contractual relationship.  (I observe that now we seem to
>>   be treating an awful lot of data that is collected by registrars
>>   and transmitted to registries as just "data that is collected",
>>   which was why I was trying to figure out the delimitation of the
>>   RDS some months ago.)
>> 
>>   3.  WHOIS was designed as a simple-minded human-consumable
>>   call-and-response protocol when internationalisation didn't work
>>   reliably on a single computer, never mind on the network.  So it
>>   knows nothing about different types of data and therefore cannot
>>   handle the data in different ways according to context.
>>   Therefore, the ICANN whois policies have all kinds of extraneous
>>   rules about formatting, how "fields" need to be handled, and so
>>   on.  None of this belongs in a policy, but it's there because the
>>   protocol was wrong.
>> 
>>   4.  WHOIS was designed and deployed for a network in which
>>   practically all the users were also developers of the network, and
>>   where the scope of the users of the network was controlled because
>>   of contractual arrangements permitting connection in the first
>>   place.  Therefore, it has no notion of "context" and cannot do
>>   anything to determine who is asking a query or to determine
>>   authorization.  Many of the debates about privacy turn out to be
>>   debates abount access, not whether the data should be collected in
>>   the first place.  We keep tripping over this now, even though
>>   we're supposed to be alert to it.
>> 
>>   5.  The fact of unfettered access has meant that people who want a
>>   domain name -- but who, quite reasonably, do not want to pay extra
>>   to prevent their cell phone number and home address from being
>>   published to 2 billion of their closest friends -- simply lie
>>   about their information in an effort to obscure it.  Others who
>>   are lying, of course, are hiding because they're doing something
>>   untoward.  There is today literally no way to distinguish these
>>   cases because the first class of people are sympathetic victims of
>>   WHOIS, a protocol created two years before the founder of Facebook
>>   was born.
>> 
>> We have got to get over the idea that the existing whois is _any_ kind
>> of model for what we ought to be trying to do.  Anyone with the
>> faintest technical background can look at the early specification of
>> WHOIS/NICNAME and recognise a protocol that was designed to be exactly
>> good enough for the purpose at hand.  Indeed, RFC 3912 (which
>> obsoleted the previous WHOIS protocol specifications in 2004) is quite
>> explicit that whois has some fundamental inadequacies that need to be
>> fixed.  Please stop claiming that "whois" -- either the protocol or
>> all the collections of policies that have been built on top of that
>> miserable hangover of a protocol -- is any guide for what we should
>> do.  It is not.
>> 
>> Best regards,
>> 
>> A
>> 
>> -- 
>> Andrew Sullivan
>> ajs at anvilwalrusden.com
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> 
> 
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg



More information about the gnso-rds-pdp-wg mailing list