[nc-whois] [fwd] Fw: Register.com comments on the whois task force recommendations (from: kstubbs@digitel.net)

[Thomas Roessler <roessler@does-not-exist.org>]

For the record.  (Ken originally distributed this directly to most
of the task force members.)
-- 
Thomas Roessler                        <roessler@does-not-exist.org>





----- Forwarded message from Ken Stubbs <kstubbs@digitel.net> -----



From: Ken Stubbs <kstubbs@digitel.net>
Date: Tue, 19 Nov 2002 19:08:56 -0500
Subject: Fw: Register.com comments on the whois task force recommendations

additional registrar input


----- Original Message -----
From: "Elana Broitman" <ebroitman@register.com>
To: <kstubbs@digitel.net>
Sent: Tuesday, November 19, 2002 6:40 PM
Subject: FW: Register.com comments on the whois task force recommendations


> Ken - could you possibly post these for me?  I can't seem to get into this
> email list.
>
> thanks
>
> >  -----Original Message-----
> > From: Elana Broitman
> > Sent: Tuesday, November 19, 2002 6:37 PM
> > To: 'comments-whois@dnso.org'
> > Subject: Register.com comments on the whois task force
> > recommendations
> >
> >
> > While we want to commend the task force for their work, we must raise
> > several issues with the task force recommendations.
> >
> > I. Data Validation
> >
> > * The Task Force's recommendation to require
> > registrars to use "automated mechanisms" (filters) to screen data are not
> > supported by data to demonstrate the viability or effectiveness of these
> > "automated mechanisms."
> >
> > * The Task Force further suggests manual methods of
> > validation, many of which might be cost prohibitive and unrealistic given
> > current technology, business processes, and the interest of registrars and
> > users in providing efficient services.
> >
> > * The Task Force recommends that registrars should
> > require that registrants whose names are challenged respond with
> > "documentary proof of the accuracy of the "corrected" data submitted, and
> > that a response lacking such documentation can be treated as grounds for
> > cancellation of the domain name registration."  It is unclear what
> > "documentary proof" would entail, but it may be a costly and technically
> > difficult requirement to implement.  Therefore, not only would smaller
> > registrars be disadvantaged, but registrants from certain areas of the
> > world or those working with registrars outside their countries would
> > likewise find it challenging to submit evidence if such requirements went
> > beyond current business practices.
> >
> > * The Task Force suggests rigid enforcement of the
> > deletion of names whose data is not "fixed" within 15 days.  The reality
> > of a global Internet where registrars in one country interact with many
> > different types of users (individuals, businesses, etc.) in many different
> > geographies and jurisdictions make it difficult for some domain name
> > registrants to interact with certain registrars.  Therefore, rigid
> > enforcement of such rules would have dire and unintended consequences on
> > honest domain name registrants. The more prudent approach is removing the
> > domain from the zone file for a finite period of time.  This serves the
> > same goal as a deleting the name, but with a safety net to protect
> > consumers and businesses.
> >
> > II. Sanctions
> >
> > * The Whois Task Force's proposed fines are substantial
> > ($250/$500/$1,000 per incident).  Even if the idea of a graduated approach
> > to policing compliance with ICANN contracts were acceptable, the levels of
> > fines there is no basis for the amounts.  The fines may well be too low to
> > count; or too high to allow competition, particularly by small registrars
> > from countries with low GNPs.
> >
> > * Furthermore, the sanctions are based on certain terms and
> > evidentiary requirements that are either unrealistic or not explained.
> >
> > o First, what is "willful" provision of inaccurate
> > data?  That term must be defined before a sanctions regime can be
> > implemented.
> > o Second, what is meant by re-verification and
> > verification of data provided when a Whois account is challenged?
> > o Third, is re-verification of a challenged record to
> > be accompanied by "documentary proof?"  Just the effort of getting certain
> > types of evidence could be cost prohibitive.
> > o Fourth, what happens to re-verification if an
> > anniversary date is changed upon registrar transfer? If it is required
> > every time, may discourage registrar transfers.
> >
> > III. Data Mining
> >
> > * The Task Force missed a critical opportunity to study the problem of
> > Whois Data mining, despite the concerns of the Registrar Constituency. In
> > fact, addressing this problem would help registrars increase Whois access
> > because they would be more confident that their data would not be used for
> > spam or other disallowed purposes.  Privacy concerns may be addressed
> > through limits on public accessibility of Whois and proxy information.
> > The trade off should be to allow IP and law enforcement to search
> > full/accurate information. The mining issue is particularly problematic in
> > that there have been two litigations filed involving registrars on this
> > very matter.
> >
> > Register.com v. Verio. This litigation addresses the very important
> > precedent of the no-third party beneficiary clause contained in the ICANN
> > Registrar Registry Agreement.  See
> > <http://www.icann.org/registrars/register.com-verio/order-08dec00.htm>
> >
> > GoDaddy v. VeriSign. Although the parties in this litigation
> > recently reached a settlement agreement, in GoDaddy's Fifth Claim for
> > Relief it alleged that VeriSign improperly and illegally obtained a copy
> > of GoDaddy's Customer Contact Data.
> >
> > * The Task Force commendably addresses the abuses of bulk whois for
> > spma marketing.  The report does not, however, address the abuses of Port
> > 43 and public Whois services, which are often used clandestinely to steal
> > customer information, and therefore represent a more serious concern than
> > bulk.
> >
> > IV. Privacy
> >
> > * Despite several comments from participants regarding privacy rights
> > it appears that the Whois Task Force did not provide a very detailed
> > analysis of the European Data Privacy Directive, or other national laws.
> > Any potential ICANN policy that is implemented must take into account
> > national law and local stakeholder perspectives, particularly when an
> > ICANN contracting party is subject to the jurisdiction of these laws. We
> > commend the Task Force for deciding to consult with the GAC on these and
> > other relevant national issues.
> >
> > V. Costs
> >
> > * Similarly, the Task Force should consult with the most directly
> > affected constituencies - the registrars and registries -to determine the
> > costs of instituting its recommendations.  The question of costs was
> > clearly not address by the Task Force, yet it is a key factor to reaching
> > balanced conclusions.  We are all concerned with accurate data, but must
> > also consider the ICANN goal of competition, which is impacted by cost
> > issues.
> >
> > VI. Process and ICANN Rules and Agreements
> >
> > * Some of the Whois Task Force's recommendations rely on changes to
> > the ICANN Registrar Accreditation Agreement (RAA). Per Louis Touton's
> > briefing of October 20, 2002, ICANN lacks the contractual authority to
> > unilaterally renegotiate this or other agreements without consensus.  As
> > you can see from registrars' reaction, as well as the concerns raised by
> > the registries, such consensus is highly unlikely.
> >
> > * The Whois Task Force recommendations requiring "thick" registries to
> > screen and filter data and to contact registrants potentially interferes
> > with the relationships between registrars and their customers - a step
> > that ICANN had scrupulously avoided in negotiating registry agreements.
> > There is no documented evidence to support the technical nor commercial
> > viability of this solution or what makes it better.  Moreover, imposing
> > this policy requirement on the thick registries may allow them to raise
> > their fees.
> >
> > VII. Standardization
> >
> > * Although the Whois Task Force acknowledges that certain standard
> > efforts involving Whois data such as the new Cross Registry Information
> > Service Protocol (CRISP) may improve or replace existing port 43 access to
> > Whois, the Task Force would get ahead of the technical development and
> > impose policy recommendations upon standards development in contradiction
> > of ICANN's technical coordinating mandate to have policy supercede the
> > standards development. The Task Force should also note competitive
> > concerns in looking at universal systems - issues of data ownership and
> > operation of such services by companies in competition with registrars.
> >
> > * Similarly, standardization would hardly exist without the
> > participation of all relevant parties.  The Task Force should consult with
> > ccTLDs to determine how to bring them into uniformity or consistency with
> > ICANN standards.
> >
> >
> >
> > Elana Broitman
> > Register.com
> > 575 Eighth Avenue
> > New York, NY 10018
> > Phone (212) 798-9215
> > Fax   (212) 244-9589
> > ebroitman@register.com
> >
>


----- End forwarded message -----