Re: [gnso-whois-study] Documents for tomorrow's call

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Patrick,

Some background. Dave Crocker (Steve Crocker's brother) and I put 
together the whois-fix bof at IETF-51. I was at NeuStar/NeuLevel at the 
time. There were a bunch of ideas floating around at the time, from 
getting whois:43 to speak XML or something structured at one end of the 
functional model, to declaring it dead, as domain names and the 
associated email addresses were no longer free and limited to the 
communities of military operational (MILNET) and military contractor and 
military allied academic (ARPANET) institutional commands and authorized 
users.
Of course a vast issue at the time was the registry model -- thick or 
thin. If thick, than the registry knows everything, independent of the 
policy of data collection (manditory for MILNET and ARPANET use prior to 
the NSF's and eventual DOC's NIC contract management periods) and 
independent of the policy of data disclosure (unpolicied) and 
independent of any retention or bulk copy or 3rd-party use policies 
(forbidden), and the technical problem of a unified consistent data 
model is pretty simple. If thin, and the registry just knows enough to 
publish a zonefile entry, than the other data -- the "social data" -- is 
held by two or more entities, and again, independent of all of the data 
collection, data publication, and data retention, data copy, and data 
repurposing policies, the technical problem of a unified consistent data 
model is not pretty simple.
Andy Newton than, and still at Versign, had UWHO, Universal WHOis, but 
with a wicked catchy title. The Verisign "consultations" of the period 
were a lot of fun, with some junior woodchuck from the FBI detailed to 
scowl and drone on about how whois:43 was wicked important to catching 
terrorists, and someone from Marks doing the familiar Marks routine and 
no one allowed to talk about how the Address Registries were solving the 
same problem -- by separating the operational data from the contact 
data, and actually policing the contact data with a policy of 
non-disclosure as the default.
Andy recast UWHO as CRISP by IETF-53, and as a wise contributor once 
told me when I tried to get a data collection disclosure mechanism for 
the HTTP state management mechanism into the HTTP spec, the IETF exists 
in part to limit the liability of employers for collusion, Verisign's 
UWHO moved on in a new costume.
Kitchen Sink Resource Record
Abstract

  Periodically people desire to put proprietary, complex, and/or
  obscure data into the Domain Name System (DNS).  This draft defines a
  kitchen sink Resource Record that will satisfy this desire for the
  storage of miscellaneous structured information.



At its bottom, Leslie Daigle's and Andy Newton's SRV hack (RFC 3958) 
isn't as ugly as putting the proverbial kitchen sink into the DNS (yes, 
there really was such a thing, Don Eastlake wrote an Internet Draft for 
a Kitchen Sink Resource Record that went to WG last call in the DNSIND 
WG in 1997, see above), but it does the same thing. It creates a 
technical mechanism to allow a unified lookup, retaining the central 
property of a "thick registry", the means within the registry data model 
of knowing everything. And that is what CRISP/ISIS is, the thick 
registry model, through pointers in the DNS SRV resource record.
Steve Crocker and Dave Piscatello and whoever else is involved with 
ssac027 are enamored with Verisign's unsurprisingly 
core-business-preserving technology. Fine. But tech isn't our problem. 
Policy is. The policy model we have is really a business model for two 
very primitive (in the unflattering non-technical sense) types of string 
uniqueness and nominal personal identification enterprises -- the 
trademarks lobby and the cops-n-robbers lobby -- who have rejected every 
offer of a "whois like" system that would meet their needs better than 
954. The free ride they're getting is being paid for by everyone who 
gets spam, whether they buy a domain name or not. Worse, the policy 
logjam over this issue has wasted the professional collaborative 
worktime of quite a few people for quite a few years.
So, if one wants to prolong the whois process, without altering the 
policy, a technical distraction is a good idea and we can schedule work 
through the end of the decade matching up chains of pointers to legacy 
and new gTLDs and real registrars and shell registrars and registrars 
who own registries and so on.
I on the other hand, would like to simply get the policy model changed 
from sleep-walking as if DARPA still paid my bills, and affirm some 
basic choice -- either give all the data unconditionally to the two 
"legal" exploitive enterprises I mentioned above, and anyone else 
looking to make money off of personally identifying data, or don't, and 
be responsible for the outcome.
And I do appreciate that the subject matter is complex, and my writing 
leaves a great deal to be desired.
Eric

Patrick Jones wrote:
> Eric,
>
> Thanks for correcting me. I had jumped ahead by reading recommendation 
> #3 in the SSAC document as calling for looking at the IDN implications 
> of WHOIS. The section does state that “SSAC encourages the ICANN 
> community to study the standards developed by the IETF's Cross 
> Registry Information Service Protocol (CRISP) Working Group. In 
> particular, SSAC urges the GNSO to consider the
> requirements for CRISP identified in RFC 3707 and the set of RFCs 
> associated with the Internet Registry Information Service (IRIS) (RFCs 
> 3981 - 3983) which appear to provide sufficient features and services 
> to meet the needs of the domain registration community.”
> I would be interested to know more about these developments and 
> support for IDNs.
> For the benefit of the group, here is the link to the 18 Sept 2003 
> announcement: 
> http://www.icann.org/announcements/announcement-18sep03.htm. I believe 
> this was a precursor to the work of the previous Whois Task Force 
> which came to an end in the LA meeting in October 2007. I am not aware 
> of the IDN issues identified in the Carthage Meeting Whois Workshop 
> being addressed in a subsequent ICANN document, but I might be wrong 
> (see http://www.icann.org/carthage/whois-workshop-agenda.htm). 
> <http://www.icann.org/carthage/whois-workshop-agenda.htm%29.>
> Patrick
>
> On 5/12/08 10:49 PM, "Eric Brunner-Williams" 
> <ebw@xxxxxxxxxxxxxxxxxxxx> wrote:
>     Patrick,
>
>     First, there is nothing in sac027 that relates to IDNs. Second, I've
>     been trying to fix-or-kill whois since ... IETF-49 and IETF-51, so
>     "earlier" is the correct answer. Third, the intersection between Steve
>     and Dave's memo and ASCII strings that begin in "xn--" is ... zero.
>
>     Turning to CRISP and ISIS, there's the ICANN announcement of September
>     18th, 2003 on the subject, so even if it were an "advance" (and we
>     don't
>     call each other's protocols "advanced" or "retarded" in the IETF,
>     although "brain dead" is used with some relish), its been around long
>     enough to have been discussed at least once previously. Mercifully, at
>     some Verisign product event and not this study group.
>
>     Cheers,
>     Eric
>
>     Patrick Jones wrote:
>     > In reviewing the WHOIS Study priority tally, there is an area that
>     > this group is overlooking: IDN implications of the current WHOIS.
>     This
>     > is not a new issue. Recently, SSAC called attention to this in
>     SSAC 27
>     > (http://www.icann.org/committees/security/sac027.pdf),
>     <http://www.icann.org/committees/security/sac027.pdf%29,>
>     > <http://www.icann.org/committees/security/sac027.pdf%29,> but
>     IETF and
>     > others have been working on it going back to at least 2004, if not
>     > earlier. This group might want to discuss protocol advances such as
>     > CRISP and IRIS and how these advances provide a way for
>     > internationalization of registration data.
>     >
>     > Category #7 (WHOIS Accuracy) in its current form does not capture the
>     > issue. Internationalization of registration data might be its own
>     > study category.
>     >
>     > Patrick
>     > --
>     > Patrick L. Jones
>     > Registry Liaison Manager &
>     > Coordinator, ICANN Nominating Committee
>     > Internet Corporation for Assigned Names & Numbers
>     > 4676 Admiralty Way, Suite 330
>     > Marina del Rey, CA 90292
>     > Tel: +1 310 301 3861
>     > Fax: +1 310 823 8649
>     > patrick.jones@xxxxxxxxx