of the GNSO Council's
6 February 2003
Click here to comment on this report.
Click here to read archived comments.
Comments on this report can be submitted until 17 February 2003.
Report of the Names Council's WHOIS Task Force
(published by the Task Force on 30 November 2002)
of the GNSO Council's WHOIS Implementation Committee
(published by the Implementation Committee on 31 January 2003)
The WHOIS Task Force has
presented several reports which have contributed to the understanding of
uses of WHOIS. In December, 2002, the Task Force published its Policy
Report, proposing both consensus policies and enhancements in
ICANN’s enforcement of existing obligations in two areas: Accuracy and
Bulk Access. Further work was recommended on both of these areas, and on
searchability and consistency of data elements across all TLDs. That report
was discussed by the DNSO's Names Council at its Amsterdam meeting, and
reopened for further comment by constituencies and the Internet community.
In addition, the Council established a WHOIS Implementation Committee, whose
work was to be completed by January 31, 2003.
The present report is
the result of the WHOIS Task Force's further outreach, and presents policy
recommendations and recommended changes in ICANN enforcement on the topics
of WHOIS Data Accuracy and Bulk Access.
The other issues discussed by the Task Force will be presented in separate “issues reports” that will form the basis for further policy-development -- either by the present WHOIS Task Force, or by a different appropriate body appointed by the Council. The Issues Reports will be published for discussion at the ICANN meetings in Rio de Janeiro, in March 2003.
The recommendations in the present report are
based on those made in the Task Force's Policy
Report, on the comments received in response to that report (see
chapter 3), and
on the work of the GNSO Council's WHOIS
For the most part, detailed discussion of the individual recommendations can be found in the Policy Report, and is not repeated in this report. The present document gives detailed discussions only in those areas in which the Task Force has changed or amended its earlier recommendations in response to the comments, and in response to the Implementation Committee's recommendations.
Respectfully submitted on behalf of the WHOIS
policies match the alternative wording proposed in the Implementation
Committee's report, sections 1 and 2, which was accepted by the WHOIS
Task Force. Further comments and
additions are marked by underlining.
A. At least annually, a registrar must present
to the Registrant the current WHOIS information, and remind the registrant
that provision of false WHOIS information can be grounds for cancellation
of their domain name registration. Registrants must review their
WHOIS data, and make any corrections.
B. When registrations are deleted on the basis of
submission of false contact data or non-response to registrar inquiries, the
redemption grace period -- once implemented -- should be applied. However,
the redeemed domain name should be placed in registrar hold status
until the registrant has provided updated WHOIS information to the
Task Force observes that the purpose of this policy is to make sure that
the redemption process cannot be used as a tool to bypass registrar's contact
There are no substantial changes to to the policies contained in section 3.2 of the Policy Report. However, the extensive discussion presented in that report has been removed in this document. Additionally, some technical changes proposed by ICANN's General Counsel have been incorporated.
A. Use of bulk access WHOIS data for marketing should
not be permitted. The Task Force therefore recommends that the obligations
contained in the relevant provisions of the RAA be modified to eliminate
the use of bulk access WHOIS data for marketing purposes. The obligation currently
expressed in section 22.214.171.124
the RAA could, for instance, be changed to read as follows (changed language
"Registrar's access agreement shall require
the third party to agree not to use the data
to allow, enable, or otherwise support any marketing activities, regardless
of the medium used. Such media include but are not limited
to e-mail, telephone, facsimile, postal mail, SMS, and wireless
The bulk-access provision contained in 126.96.36.199
of the RAA would then become inapplicable.
B. Section 188.8.131.52
of the Registrar Accreditation Agreement currently describes an
optional clause of registrars' bulk access agreements, which disallows
further resale or redistribution of bulk WHOIS data by data users. The
use of this clause shall be made mandatory.
The recommendations below are based on chapter 3.1.I of the Policy Report.
ICANN should ask registrars to identify, by a date certain, a reliable contact point to receive and act upon reports of false WHOIS data. ICANN should encourage registrars to (i) provide training for these contact points in the handling of such reports, and (ii) require re-sellers of registration services to identify and train similar contacts.
ICANN should continue to maintain a standardized complaint form on this issue in the internic.net site. Registrars, registries and re-sellers should be encouraged to provide a link to this site. In order to better ensure follow up, the complaint form should supply a "ticket number" for the complaint and should be designed so ICANN receives a copy of the registrars' response to the complaint (i.e., the form should incorporate a simple, automated mechanism for the registrar to report back to ICANN on the outcome of complaints).
Upon receiving a complaint about WHOIS accuracy, a registrar may seek evidence or justification from the complainant.
If the complaint appears justified, then a registrar should at a minimum send an email to all contact points available in the WHOIS (including registrant, admin, technical, and billing contacts) for that domain name with:
When the registrant responds, a registrar should take commercially reasonable steps (e.g. apply some heuristic automated data validation techniques (possibly via an automated tool centrally provided by ICANN) to check that the new WHOIS information is plausible. If the data is found to be not plausible, the registrant should be required to provide further justification (which may be documentary evidence) before the data will be accepted.
If no response is received or no data acceptable in step 3 above has been provided after a time limit (to be agreed) a registrar should place a name in REGISTRAR-HOLD (or equivalent) status, until the registrant has updated the WHOIS information.
For a name to be removed from REGISTRAR-HOLD status to active status, the registrant should be required to contact the registrar with updated WHOIS information (as per (3) above), and the registrar should confirm that the registrant is contactable via this new information.
By following the procedures recommended above,
registrars can improve the accuracy of contact details in Whois. These
procedures do not address all situations that may arise requiring registrar
action to address inaccurate or unreliable Whois data, and are not intended
to replace registrars' obligations in their accreditation agreements to
investigate and correct inaccuracies.
is based on part 3 of the WHOIS Implementation Committee's work.)
C. Input received both from the Implementation Committee
and in public comments indicates a strong desire in parts of the community
to extend the 15 day period currently specified in section 184.108.40.206
of the RAA. The concerns expressed were based on the interpretation that
the 15 day period was mandatory.
received from ICANN's General Counsel indicates that the "current
contractual structure of requiring the registrar to retain the right to
cancel if the customer fails to respond in 15 days, but not requiring the
registrar to exercise this right is intended to give the registrar the
flexibility to use good judgment to determine what action should be taken
upon a customer's failure to respond to an inquiry about a Whois inaccuracy."
This interpretation of the contractual language seems to address the concerns
Given the flexibility provided, the Task Force
is not making a policy recommendation on this issue.
D. ICANN should modify and supplement its May 10, 2002 registrar advisory as follows:
ICANN should remind registrars that "willful provision of inaccurate or unreliable information" is a material breach of the registration agreement, without regard to any failure to respond to a registrar inquiry. A functional definition -- based on the actual usability of contact details -- should be used for “inaccurate or unreliable”.
clearly state to registrars that "accepting unverified
'corrected' data from a registrant that has already
deliberately provided incorrect data generally is not [not "may not be," as
the advisory now states] appropriate."
(Much of the text which was contained in the policy report's version of this recommendation has been replaced by Recommendation B above.)
ICANN should encourage registrars to take steps to remind registrants of their obligations to submit and maintain complete and accurate contact data at appropriate points, including but not limited to the time of renewal of a registration.
Registrars should be encouraged to develop, in consultation with other interested parties, “best practices” concerning the “reasonable efforts” which should be undertaken to investigate reported inaccuracies in contact data (RAA Section 3.7.8).
(This is a
new recommendation, based on the Implementation Committees' suggestions
and the Task Force's consultation with the General Counsel.)
The WHOIS Task Force recommends that the implementation and adoption of the recommendations made in this report be monitored by the ICANN staff with appropriate reports to the GNSO Council, consistent with the PDP.
In considering the task force’s Policy Report on Accuracy and Bulk Access at its meeting on December 14, 2002, the Names Council adopted a resolution providing in part as follows:
That the Names Council creates an implementation/cost analysis committee, that would look at the cost of implementing the recommendations as they are written and as they may change during the next 30 day period.
That the implementation Cost analysis committee produces a report by 30 January 2003 prior to the Council meeting on February 20 which can be incorporated into the main report.
The structure of the implementation analysis committee would be identical to that of the Transfers implementation analysis committee and would consist of Registries, Registrars and user representation from the WHOIS task force.
See http://www.dnso.org/dnso/notes/20021214.NCteleconf-minutes.html for full text of the resolution.
The committee created by this resolution (hereafter referred to as the Whois Implementation Committee) subsequently convened and ultimately adopted a final report which is incorporated into this document by reference. The following are the comments of the Task Force on the report of the Whois Implementation Committee.
The Whois Implementation Committee took a narrow
approach to its mission and only offered views on four of the recommendations
contained in the Task Force’s Policy Report. In general, it responded
to the recommendations that appeared to it to require action by registrars
or registries, and not to those that were primarily or initially directed
to ICANN staff or others.
1. The Implementation Committee offered its views on the Recommendation contained Section 3.1 (III)(A) of the Policy Report:
“Registrants should be required to review and validate all WHOIS data upon renewal of a registration. The specifics of required validation remain to be determined by this Task Force or another appropriate body.”
The Implementation Committee concluded that this recommendation was implementable. It suggested that, in order to improve the feasibility of implementation, the text of the recommendation be changed to the following:
“At least annually, a registrar must present to the Registrant the current WHOIS information, and remind the registrant that provision of false WHOIS information can be grounds for cancellation of their domain name registration. Registrants must review their WHOIS data, and make any corrections.”
The Task Force believes that this change to its earlier recommendation should be ACCEPTED. It is certainly consistent with the intent of the recommendation contained in the Policy Report and provides registrars with clearer direction about the actions they should take. This recommendation is based on the input of the Implementation Committee whch included several registrars.
2. The Implementation Committee offered its views on Recommendation 3.1 (III) (B) of the Policy Report:
When registrations are deleted on the basis of submission of false contact data or non-response to registrar inquiries, the redemption grace period -- once implemented -- should be applied. However, the redeemed domain name should not be included in the zone file until accurate and verified contact information is available. The details of this procedure are under investigation in the Names Council's deletes task force.
The Implementation Committee deemed this recommendation to be implementable. It suggested that, in order to improve the feasibility of implementation, the text of the recommendation be changed to the following:
registrations are deleted on the basis of submission of false contact data
or non-response to registrar inquiries, the redemption grace period --
once implemented -- should be applied. However, the redeemed domain name
should be placed in Registrar Hold status until the registrant has provided
updated and accurate WHOIS information to the registrar-of-record.
Task Force can accept this change to its earlier recommendation subject
to the concern stated in the Task Force Final Report that this implementation
(which drops the words “accurate and verified”) must not allow the redemption
process to be used as a tool to bypass the registrar’s contact correction
process. This is particularly important with respect to registrations
in this category, which have already been ordered deleted due to provision
of inaccurate contact data or failure to respond to a query. Overall, this
implementation is consistent with the intent of the recommendation in the
Policy Report and more clearly specifies what has to happen before a redeemed
domain name is placed back in the zone file once it has been removed from
3. The Implementation Committee offered its views on part of Recommendation 3.1 (I)(B)(2) of the Policy Report:
ICANN should clearly state to registrars that "accepting unverified 'corrected' data from a registrant that has already deliberately provided incorrect data is not [not "may not be," as the advisory now states] appropriate." Accordingly, where registrars send inquiries to registrants in this situation, they should require not only that registrants respond to inquiries within 15 days but that the response be accompanied by documentary proof of the accuracy of the "corrected" data submitted, and that a response lacking such documentation may be treated as a failure to respond. The specifics of acceptable documentation in this situation should be the subject of further discussions.
The Implementation Committee did not offer any views on the first sentence of this recommendation, presumably because it was directed to ICANN, not to registrars directly. It did, however, comment on the remainder of the recommendation, apparently treating it as directed to registrars. It concluded that this part of the recommendation was “NOT implementable in its current form.” However, it did suggest replacement text,which is presented as “implementable”.. The suggested replacement text is as follows:
“(a) Upon receiving a complaint about WHOIS accuracy, a registrar may seek evidence or justification from the complainant.
(b) If the complaint appears justified, then a registrar must at a minimum send an email to all contact points available in the WHOIS (including registrant, admin, technical and billing) for that domain name with:
(c) When the registrant responds, a registrar
must take commercially reasonable steps (e.g apply some heuristic automated
data validation techniques (possibly via an automated tool centrally provided
by ICANN)) to check that the new WHOIS information is plausible. If the
data is found to be not plausible, the registrant must provide further
justification (which may be documentary evidence) before the data will
(d) If no response is received or no acceptable data has been provided after a time limit (to be agreed) a Registrar must place a name in REGISTRAR-HOLD (or equivalent) status, until the registrant has updated the WHOIS information.
(e) For a name to be removed from REGISTRAR-HOLD
status to active status, the registrant must contact the registrar with
updated WHOIS information (as per (c) above), and the registrar must confirm
that the registrant is contactable via this new information (for example
by requiring that the registrant respond to an email sent to a new email
The Task Force believes that this change to its earlier recommendation should be ACCEPTED in large part. Specifically:
Paragraph (a) should be ACCEPTED. The Task Force notes that the uniform complaint form which it recommends continue to be provided by ICANN (see Recommendation 3.1 (I)(A)(4)) should include a field in which the complainant is asked to provide a brief justification for or evidence in support of the complaint. This would make it unnecessary in many cases for registrars to exercise the option to “seek evidence or justification from the complainant.” (The Task Force interprets the word “justification” to mean “reasons why the complainant believes the Whois data is inaccurate,” and use it in that way.)
Paragraph (b) should be ACCEPTED. The Task Force notes that it has recommended that “registrars should be encouraged to develop, in consultation with other interested parties, “best practices” concerning the “reasonable efforts” which should be undertaken to investigate reported inaccuracies in contact data (RAA Section 3.7.8).” The “minimum” suggested by the Implementation Committee could be supplemented by these best practices.
Paragraph (c) should be ACCEPTED. The use of an ‘automated tool centrally provided by ICANN” should be optional if another commercially reasonable validation technique is available. The responsibility of the registrar is to take commercially reasonable steps to check the plausibility of “corrected” data submitted by a registrant, which could be use of an automated data validation technique. If the submitted data fails this test, then a further inquiry should be made, and some degree of human evaluation of the acceptability of the re-submitted data must be made to determine whether acceptance of the data is warranted. This human evaluation requirement is appropriate because in this instance, the initial complaint was deemed justified and the initially submitted data failed the plausibility test.
Paragraph (d) should be ACCEPTED. The time limit in the case of second requests (after implausible data has been submitted the first time) should be quite brief since the registrar has already established contact with the registrant.
Paragraph (e) should BE ACCEPTED WITH A MODIFICATION,
by deleting the parenthetical. This item only comes into play after the
registration has been placed in "registrar hold" due to failure to provide
accurate contact data, so there may already be reason to question the veracity
of the registrant. For the registration to be restored to the zone file,
the registrant should need to do more than to send in "plausible" data (which
passes what could be a minimal automated test) and to get a disposable email
account to which he responds to one e-mail from the registrar. Some greater
assurance of the accuracy of all the contact details (and thus of compliance
with the registrant's obligation under the RAA) should be established at
this point, before restoration to the zone file. Confirmation of the accuracy
of all newly provided contact points is not necessarily required to fulfill
this step, although that ordinarily would be the best practice.
4. The Implementation Committee provided its views on Recommendation 3.2 (II)(1) of the Policy Report:
There is consensus that use of bulk access WHOIS data for marketing should not be permitted. The Task Force therefore recommends that the relevant provisions of the RAA be modified or deleted to eliminate the use of bulk access WHOIS data for marketing purposes.
The Implementation Committee construed this as a recommendation that “registrars modify their bulk WHOIS access agreements to eliminate the use of data for marketing purposes.” In fact, the Task Force’s recommendation is that registrars be REQUIRED to make this change in their bulk access agreements. The Implementation Committee did not recommend any changes to the revisions to the RAA in this regard that were suggested by the Task Force in its Policy Report.
The Implementation Committee concluded that
“there is a need to clarify the definition of “marketing purposes”. This
may require a small working group to define, possibly just in the form
of examples (but not limited to) of marketing activities covered.” The
Task Force agrees with this observation.
The Task Force withholds comment on other aspects of the Implementation Committee’s report that do not go directly to implementation of the Task Force’s recommendations.
Report was open for comments between December 1 until December
8, 2002. Following ICANN's Amsterdam meetings and the Names Council
conference held at these meetings, there was another opportunity for
public comment from December 23, 2002, until January 10, 2003. The
present section summarizes the comments received during these time
[comments-whois] WHOIS task force comments George Kirikos
[comments-whois] Comments on Accuracy and Bulk Access Report Alexander Svensson
[comments-whois] Whois and Transfer Task Force Reports Neuman, Jeff
RE: WHOIS and Transfer Task Force Reports Cade,Marilyn S -
[comments-whois] Comments on November 30, 2002 report Bill Weinman
[comments-whois] comments on whois-report (mostly rejections) Siegfried Langenbach
[comments-whois] WHOIS policy report comments der Mouse
[comments-whois] Accuracy and Marketing use of WHOIS data Stephen A. Mattin
[comments-whois] RE: WHOIS and Transfer Task Force Reports Cade,Marilyn S - LGA
[comments-whois] WhoIs William C (Bill) Jones
[comments-whois] potential for abuse of the WHOIS complaints procedure Joop Teernstra
[comments-whois] Real lives at risk; personal privacy needs immediate attention KathrynKL
[comments-whois] Reopening of Whois comments list. DNSO Secretariat
[comments-whois] Comments Vittorio Bertola
[comments-whois] WHOIS report comments Robert Baskerville
[comments-whois] WHOIS accuracy, and name deletions George Kirikos
Current System Not Working John Berryhill
[comments-whois] No Subject RBHauptman
[comments-whois] Missing archives sent to Missing posts to firstname.lastname@example.org for WHois Taskforce from Oct.. Jeff Williams
[comments-whois] Bulk Whois and abuse of Public Whois Elana Broitman
[comments-whois] Comment on 15 Day Response Requirement Bret Fausett
[comments-whois] Privacy concerns DannyYounger
Privacy issues with the WHOIS database Barbara Simons
[comments-whois] make bulk whois available for research and archival Aaron Swartz
[comments-whois] Comment on draft Karl Auerbach
[comments-whois] changes to WhoIs database Stanley Krute
WhoIs Task force comments Tews, Shane
[comments-whois] re: make bulk whois available for research and archival Ray Fassett
George Kirikos is concerned about the 15 day time period "as it might not allow sufficient time to investigate the alleged inaccuracies." Mr. Kirikos points to holidays, illness, and other letgitimate reasons why a domain name holder may not be able to respond to an accuracy inquiry in a timely manner. He suggests that there should be multiple attempts to contact a registrant. Also, Mr. Kirikos proposes to put domain names on hold for "at least a few months" before they are deleted due to inaccuracy of contact information. Verification processes could be outsourced.
As an additional means to mitigate the problems
he observes, Mr. Kirikos suggests that registrars should offer registrants
an opportunity to periodically verify the accuracy of their contact
data. Domain names associated with these verified and accurate data
would then be put onto a "white list", and would not be subject to
Alexander Svensson asks for further clarification
of the proposed "functional definition" of "inaccurate or unreliable
contact data", "e.g. whether a registrant must be reachable through
all means of contact all the time." Mr. Svensson "strongly supports"
the dissenting opinion of the GA representatives concerning the 15 day
period, and argues that the period "should not be the primary means
to stop overtly fraudulent websites, as this is a task which should be
left to law enforcement authorities." He favors an extension of the 15
day period, and suggests a hold period before the eventual deletion of
a domain name due to accuracy complaints.
Mr. Svensson also points the task force to statistics
of postal delivery failures gathered during the at-large elections
Mr. Svensson agrees with the recommendation
to "eliminate the use of bulk access WHOIS data for marketing purposes
and the consideration of an enforced restriction of bulk access to
a well-defined group of legitimate users, respecting applicable national
On behalf of the gTLD constituency, Jeff Neumann
formally requests that no action be taken at the Names Council meeting
on 14 December 2002, due to a lack of time to "receive adequate and
constructive feedback from the Internet community as a whole."
This comment was submitted by Bill Weinman,
the author of a WHOIS client (BWwhois).
Mr. Weinman reports that he had to remove his telephone number
from the public WHOIS directory in order to stop nightly telephone
calls, and demands that there be a "provision for individuals to keep
their personal phone numbers secret."
This comment was submitted by Siegfried Langenbach.
He observes that, from his experience, most allegations of false
data are "false or at least a kind of attack." His own registrar business
insists that allegations of false data are proven by a return letter
which shows that an address is indeed unusable. According to this comment,
"the standard form at internic is of no use if ICANN people just let
the messages be forwarded to the registrars without having a check."
Mr. Langenbach suggests that domain names with false data be put on
hold, and that their WHOIS reports be marked accordingly. In his conclusion,
Mr. Langenbach demands that "it should be imposed to those starting
the process to prove that the address is wrong, not the other way around."
Concerning bulk access, Mr. Langenbach points
to possible issues with applicable law outside the US.
These comments were submitted by "a longtime
net user" identifying himself as "der Mouse." The comment criticizes
the Task Force's report (in particular section 3.1.I.A.4) as being web-centric; a web-based
form is not considered an acceptable substitute for a port-43 server.
It is also suggested that the proposed web form
for submitting accuracy complaints should be replaced by an e-mail address.
A distinction is suggested between "honest mistakes"
and outdated data on the one hand, and "blatantly fraudulent data" on the
other hand. No need for a 15 day delay is seen in cases in which no valid
address information ("n/a") and an invalid telephone number are given. It
is suggested that registrars should be able to "effectively shut down such
domains during any delay period that is present."
The commenter supports the notion that registrant
data should only be available for marketing purposes on an opt-in
basis. Recommendation 3.2.II.B.2 (ineligibility for future bulk access
upon breach of license; this is a mid-term work item) is characterized
as a "most rudimentary" provision. The commenter sees no reason why ICANN
should impose any limit on fees for bulk access.
He sees no need for the bulk access agreement
provision currently mandated by RAA 220.127.116.11 (high-volume processes),
and suggests that "if the desire is to prevent interverence with oeprations,
the provision should prohibit interference with operations, regardless
of how caused."
The comment then goes on to address individual
arguments made in a number of comments received by the Task Force
in response to the interim report.
In this comment, Steve A. Mattin reports that
his WHOIS contact information has been "repeatedly screwed up in
the past, resulting in multiple accounts with inaccurate information."
He identifies database maintainers -- "for example NS MAKING UP contact
email addresses" -- and registrars as sources for these errors, and
criticizes the practice of assigning new NIC handles fo the same individual
as "multiplying my problems in maintaining accurate info."
While Mr. Nattin is willing to take responsibility
for data he enters into the system, he is unwilling to bear the
consequences of errors made by others. For this reason, he opposes
to automatic sanctions.
Mr. Nattin supports the free availability of
accurate WHOIS data for non-bulk users. For bulk access, he suggests
that data users should be charged "commercial rates" like $10 per
address. "The income generated from 'bulk' users should be used to
hire 'real people' to help fix/maintain the accuracy of the data (and
therefore, it's marketing value)," Mr. Nattin concludes.
This comment was submitted by William C Jones,
who identifies himself as the owner of the domain insecurity.org.
Mr. Jones writes that he "submitted the most complete factual information
that [he] could get away with while still trying to protect [his]
privacy", while making sure that he can still be contacted by telephone,
e-mail and regular postal mail. Mr. Jones expresses a strong feeling
that the WHOIS database "MUST be kept public and must be accurate."
He quotes "research" which indicates that "people who provide false
or misleading information for the WHOIS Registry should NOT be allowed
to keep their domains."
Joop Teernstra warns that "15 days without a
response is not a sufficient time period to establish a material breach of
a registration agreement in case of an WHOIS accuracy inquiry." He also observes
that "the accuracy complaint procedure can be abused ... to harrass bona
fide ... registrants", and may even be a tool for "robbing" a domain name.
He suggests a "postal response period" of 30 days, and suggests that at least
two warning e-mails should be sent to the registrant.
These elaborate comments were submitted by Kathryn
A. Kleiman "as an individual, small business owner, and political speaker."
Ms. Kleiman addresses the following points in great detail:
Ms. Kleiman also proposes that the Task Force's
recommendations on WHOIS accuracy should be tested in a "clearly
commercial gTLD" first, and that "special issues that apply to individuals
and political organizations in other gTLDs" should be considered later.
This comment was submitted by Vittorio Bertola.
He starts by observing that, while accuracy of data in the WHOIS
database may be desirable, some degree of inaccuracy is unavoidable
for a variety of reasons, including: burdensome procedures for updating
data; the use of "minor or major alterations of contact data" as a tool
to avoid spamming and personal harassment; special risks for political
speakers; "the usual complexity of the world." Mr. Bertola concludes
that "automatically connecting inaccurate data [...] with a fraudulent
intent or unlawful behaviour is not per se acceptable."
Mr. Bertola believes that the 15-day deadline
is too short, and suggests a number of steps registrars and registries
should take when receiving a complaint about the accuracy of contact
data associated with a certain domain name: First, attempts should
be made to contact the registrant by e-mail both to the last known addresses,
and to the domain's postmaster, hostmaster, and webmaster addresses
(and addresses readily available from a website possibly associated
to the domain name). If that fails, there should be several attempts
to reach the registrant by telephone. Finally, the postal service should
be used, allowing 30 calendar days "for the letter to be delivered and
Mr. Bertola also recommends that ICANN should:
establish a step-by-step contact verification process which should
include attempts to reach the registrant through a variety of communication
channels; foster the creation of simple instruments for registrants
to keep their contact details up to date; introduce measures by which
some or all information about registrants may be withheld from the
public WHOIS system.
Finally, he notes that "the WHOIS service as
currently implemented by most registries is clearly illegal in a
number of countries, including the European Union."
In this comment, Robert Baskerville agrees with
the need for accurate WHJOIS data; however, he believes that the 15 day time
limit is too short. He sees "little purpose" for the continuation of bulk
access to WHOIS data, and identifies it as a disincentive to accurate data.
He points to the European legislation on data protection which covers all
personal information and prohibits export of such data "to anywhere which
does not have similar legislative protection of personal data without
Mr. Baskerville is "happy for the data linking
myself to various .uk domains to be available for standard whois
queries", but does not want it to be available for any bulk purpose
Mr. Kirikos re-iterates his concern about the
15 day period, and once again suggests a whitelist mechanism to
be implemented by registrars. He also suggests to establish a "legal
contact", "for which legal notices can be sent, to augment the existing
In this comment, John Berryhill lists a number
of domain names whoise WHOIS records include the World Trade Center
in New York as the registrant's postal address. He writes: "I reported
the fictitious addresses in the following domain names a couple of
months ago, and Verisign has done nothing. As per the 15 day period
to correct registration data, these people have had plenty of time,
and I agree with the Task Force that their delay is inexcusable."
This comment was submitted by Elana Broitman
(register.com). Ms. Broitman points out that public, query-based
WHOIS services are abused in an equal or worse manner as bulk WHOIS.
She gives the DROA taking of Register.com's and other registrars' WHOIS
data as an example, and notes that the data was not obtained through a
bulk WHOIS license. Ms. Broitman appreciates the "good public policy
reasons for publicly available WHOIS," but believes that "we can find a
solution that meets these legitimate needs while protecting consumers...
from public disclosure that is subject to abuse." Finally, Ms. Broitman
notes that "until we address this gap, there is little use in changing bulk
WHOIS requirements ... as potential bulk WHOIS licensees move to abuse of
In this comment, Bret Fausett notes a personal
experience with the 15-day response policy in which he received
notice from his registrar that his contact data was inaccurate and
must be corrected within 7 (seven) days or run the risk that his domain
name would be deleted. The contact data in question were accurate;
the complaint was fraudulent. Mr. Fausett suggests that ICANN should
not accept anonymous complaints about WHOIS inaccuracies, that the
15-day deadline should be extended to 30 days, and that "the deletion
grace period should apply to domain names deleted because they allegedly
had inaccurate WHOIS data."
comment was subsequently corrected.
Danny Younger supports the earlier recommendation
of Michael Palage that the Task Force be dissolved as it has "failed
to properly and fully address community concerns regarding privacy."
Barbara Simons is concerned that the availability
of WHOIS contact data is a thread to privacy and security, through
identity theft which dcan in turn be used to create false identification
for criminals and terrorists. She supports the comments submitted
by Kathy Kleiman on 9 December 2002.
Aaron Swartz notes that the WHOIS database provides
invaluable information for the public, researchers, and archivists. He argues
that the current $ 10,000 bulk access fee "practically ensures that the data
will only be used for marketing purposes." He suggests that complete electronic
copies of the data be made available for purposes of research and archival
at cost, and suggests that 18.104.22.168 should have an exception for research
and archival purposes.
Karl Auerbach feels that the policy report "unfairly
characterizes [his] comments and failed to answer even a single one of [his]
questions." He re-attaches his early comments.
Mr. Auerbach disagrees with the interim report
in that it starts from "an irrebutable presumption, that whois data
must be published for the convenience of intellectual property owners
no matter how much social damage that may cause through destruction
of personal privacy."
Mr. Auerbach supports the comments made by Kathryn
Stanley Krute of Soda Mountain, Co., recounts
his own tracking of an individual who ran a fraudulent Internet
service in his community. With Google and WHOIS, Mr. Krute was able
to trace 3 years of faudulent activity amounting to several hundred
thousand dollars. He writes: "Without the whois database, my ability
to figure out a timeline of this guy's crimes would've been nearly zilch.
whois is a vital component of the web. It provides a minimal level
of accountability. Without an accurate whois directory, the web will
become a prime location for criminal activities."
Mr. Krute is not sure about bulk access "due to the existence of spammers." However, he suggests that there should be a web service (XML-RPC, SOAP) for automated WHOIS queries. He suggests that spammers may be deterred by "limiting the interface to one query at a time."
This comment was submitted by Shane Tews on
behalf of the Network Solutions Registrar. According to the comments,
the Task Force's report does not yet reflect a thorough vetting of
all the issues related to the future of WHOIS, nor a consensus of
the community on its conclusions. Network Solutions believes that bulk
WHOIS access is one of the causes of the current spam problem as well
as a cause of concern for privacy advocates. It should not be a precondition
for using the domain name system for a user to have to open herself
up to abuse through the misuse of contact data. Network Solutions believes
that suituations like the abuse of contact data are legitimate reasons
for limiting availability of contact information. Until consumer privacy
concerns are adequately addressed, progress in assuring accurate WHOIS
data will be difficult.
In response to Aaron Swartz's earlier comment. Ray Fassett suggests that "the application of Digital Rights Management technology could restrict certain uses of the database upon download, notably those favored by marketing objectives."
This chapter contains summaries of statements
received by the Task Force outside the usual comment process. Some of the
issues addressed in these comments are not covered by the present report,
but will be the topics of issues reports to be produced by the Task Force
in the immediate future.
The Security and Stability Advisory Committee provided recommendations in a December 1, 2002, report to the ICANN board, which the Task Force has reviewed. The report acknowledges the importance of WHOIS data for the security and stability of the Internet as the administrating and control of Internet resources is widely distributed. The Committee recommended validation of contact information for the party responsible for the Internet resource at the time of registration and on a regular basis thereafter. Non-validated records must be frozen or held until updated or removed. The committee supports the development of a standard format for WHOIS. The report also notes the importance of mechanisms to protect a registrant’s privacy. It also recommends that methods be developed to discourage harvesting or mining of WHOIS information. The report includes some interesting recommendations about requiring a “last verified date” for the WHOIS data. The Committee recommends that registrars, registries and all interested parties should support and participate in the activities of the CRISP and PROVREG working groups of the IETF.
The European Commission
provided a three
page contribution to ICANN in mid January, 2003, which the Task Force
has reviewed. The contribution provides comments on some of the earlier
reports of the Task Force and welcomes the opportunity to discuss the issues
in more detail. The contribution follows two earlier communications from
the Commission to ICANN, which are referenced. This communication acknowledges
that the survey undertaken by the Task Force is not a scientific study
and that its result are not representative of all users. The contribution
notes the importance of recognizing existing legal frameworks' legal requirements
and obligations. It further describes the purpose of the WHOIS database
as traditionally technical and operational in nature. The submission notes
that the Task Force report did not define what uses are legitimate and compatible
to the original purpose. The importance of limiting the amount of personal
data to be collected and processed, under the European Data Privacy Directive
is emphasized. The contribution contains supportive comments on the role
of Trusted Third Parties or similar solutions and on studying “differentiated”
access to provide WHOIS data but without having all data available to everybody.
There is support concerning accuracy of data and to limitation of bulk access,
and observes that "bulk access, for any purpose (not only for direct marketing),
is in principle unacceptable." The Interim Report's proposals concerning
uniformity and more searchable WHOIS facilities are not supported.
The International Working Group on Data Protection in Telecommunications has provided a comment (dated January 15, 2003) in response to the Task Force's Interim Report. The Working Group reaffirms its Common Position on Privacy and Data Protection aspects of the Registration of Domain Names on the Internet originally adopted in May 2000. The Working Group is "especially critical of proposals contained in the Interim Report ... to extend the search capabilities of WHOIS databases to searches for the registrant name."