| |
WHOIS TASK FORCE 3
IMPROVE THE ACCURACY OF DATA COLLECTED FROM GTLD REGISTRANTS
PRELIMINARY REPORT
.pdf
version
|
WHOIS TASK FORCE 3
IMPROVE THE ACCURACY OF DATA COLLECTED FROM GTLD REGISTRANTS
PRELIMINARY REPORT
Introduction
Summary of Work
Summary of Constituency Positions
At-Large
Advisory Committee
Business
Users Constituency
Intellectual
Property Constituency
Internet
Service and Connectivity Providers Constituency
Non-Commercial
Users Constituency
Registrar
Constituency
Registry
Constituency
Summary of ICANN's InterNIC WDPRS
Report
Key Findings
Background
and Overview of the WDPRS
Matters
Requiring Further Consideration and Proposed Best Practices
Comments
Provided in Submitting Vote or Position on Best Practices Section
Registrar Constituency Minority
Report
Appendix A – Position Statement of the At-Large Advisory
Committee
Appendix B - Position Statement of the Business Users Constituency
Appendix C - Position Statement of the Intellectual Property
Constituency
Appendix D - Position Statement of the Internet Service
and Connectivity Providers Constituency
Appendix E - Position Statement of the Non-commercial Users
Constituency
Appendix F - Position Statement of the Registrar Constituency
Appendix G - Position Statement of the Registry Constituency
Summary of Task Force 3 Public Comments
Introduction
The purpose of this task force is to develop mechanisms to improve the quality
of contact data that must be collected at the time of registration, in accordance
with the registrar accreditation agreement (in particular clauses 3.3.1 and
3.7.7.1), and the relevant registry agreement (e.g. Unsponsored TLD Agreement:
Appendix O (.biz)).
Summary of Work
The GNSO Council orally issued its request for Constituency Statements
on February 19 with the statements being due on March 19, 2003. The Task Force
is to issue its Preliminary Report, as recognized under the PDP, on April 9,
2004.
In the WHOIS Task Force 3 Description of Work, amended October 29, 2003, the
GNSO Council identified five Tasks/Milestones, the first two of which are addressed,
to the extent currently possible, in this Interim Report:
The "Tasks/Milestones" for Task Force 3 are as follows:
- Collect information on the current techniques that registrars use to verify that the data collected is correct. For example techniques to detect typing errors by registrants intending to provide correct information. Survey approaches used by ccTLDs to verify that the contact data collected is correct.
- Collect publicly available information on the techniques used by other online service providers (to verify that data collected is correct) as well as information on the price of services offered by the online service provider.
- Create a best practices document for improving data verification based on the information collected that can be applied on a global basis.
- Determine whether any changes are required in the contracts to specify what data verification is necessary at time of collection to improve accuracy.
- Determine what verification mechanisms can be used cost effectively to combat the deliberate provision of false information, and determine whether additional mechanisms are necessary to provide traceability of registrants, or provide more timely responses for misuse of domain names associated with deliberately false information.
In connection with Task 1, TF3 collected limited data from Registrars. TF3 also
has sought to survey, via CENTR, the Whois Data Accuracy practices of CENTR members,
and has circulated to the CCNSO through ICANN Staff, a survey of Whois Data Accuracy
practices by ccTLDs.
The Task Force has been informed through ICANN Staff that CENTR determined not
to include TF3’s survey questions in the CENTR survey. Similarly, the remaining
ccTLDs and ccTLD organizations have decided not to respond to the survey submitted
to them.
Task 2 required the Task Force to collect publicly available information on the
techniques used by other online service providers to verify that WHOIS data collected
is accurate as well as the price of services offered by the online service provider.
The Task Force also undertook a survey of online service providers but only received
one substantive response to its request.
As a result of the highly limited number of responses to its inquiries, the Task
Force is currently developing a proposed statement of best practices based on
the experience and observation of the Task Force and the represented constituencies.
If the Task Force is able to develop a statement that is supported by a super-majority
of the constituencies, it will be included in the final version of this report
as a recommendation of the Task Force. A recommendation of this nature will permit
the Task Force to continue its work on tasks 4 and 5.
Summary of Constituency Positions
Not all Constituencies have submitted Position Statements. If further
submissions are received prior to April 19, 2004, they will be summarized and
included in this draft report and the resultant Interim Report of the Task Force.
At-Large Advisory Committee
The position of the At-Large Advisory Committee is included as Appendix
A.
Summary:
The Committee position observes that:
- Attempting to procure accurate information from entities that do not wish
to provide it is wasted time and effort. A determined entity will always work
around, not within, any system of rules or processes.
- Implementation of any data verification schemes must be applied globally and not be applied to a gTLD on a discriminatory country-by-country basis.
- Known verifications schemes are unable to differentiate plausible data from accurate data.
- The feasibility of known verification schemes, given current requirements, is unproven.
- Registrar Accreditation Agreement provisions regarding data collection and display may not have force in many jurisdictions.
- Registrants should not directly or indirectly bear the costs of any data verification service primarily required by third-party data users.
The Committee position recommends that:
- That no further action should be taken to compel unwilling subjects to provide accurate data.
- That the Task Force should concentrate its efforts on ensuring that those entities that do wish to provide accurate data can easily do so through simple and cost-effective processes.
- A review and amendment of the relevant provisions of the Registrar Accreditation Agreement to ensure consistency with existing national privacy legislations.
- That ICANN require the exclusive use of a distributed coordinated Whois model instead of centralized implementations.
Business Users Constituency
The position of the BUC is included as Appendix B.
Intellectual Property
Constituency
The position of the IPC is included as Appendix C.
Summary:
The Constituency position makes no supporting observations.
The Constituency position recommends that:
- ICANN should work with all relevant parties to create a uniform, predictable and verifiable mechanism for ensuring compliance with Whois-related provisions of the present agreements and devote adequate resources to such a compliance program.
- ICANN should ask each registrar to present a plan for substantially improving the data it collects.
- The RAA and gTLD registry agreements should be modified to provide for graduated or intermediate sanctions for patterns of violations by a registrar of the Whois data accuracy obligations of those agreements.
- That the policy development process for this task force should mutate into an ongoing effort with the goals of researching and communicating information regarding practicable and cost-effective methods used to improve the quality of identifying and contact data submitted by customers in online transactions outside the realm of gTLD domain name registrations and development of best practices within the realm of gTLD domain name registration for improving the accuracy, currentness and reliability of contact data in the Whois database.
Internet
Service and Connectivity Providers Constituency
The position of the ISCPC is included as Appendix D.
Non-Commercial Users
Constituency
The position of the NCUC is included as Appendix E.
Summary:
The Constituency position observes that:
- Accuracy of Whois data is not unconditionally desirable.
- Whois data protections are necessary to protect registrants and other contacts contained in the gTLD Whois database from identity theft and to ensure freedom of speech.
- The purpose of the gTLD Whois system was originally to allow for technical coordination between domain holders.
- The original purpose of the gTLD Whois system was not to provide law enforcement or other self-policing interests with a means of circumventing normal due process requirements.
- Privacy is key to ensuring accuracy of the data in the gTLD Whois databases.
- The Task Force has not collected sufficient information to reach any conclusions regarding best practices for verifying data accuracy.
The Constituency position recommends that:
- Submission of personally identifiable contact data should be optional.
- ICANN recognize the data protection principle that the purpose of data and data collection processes must be well-defined before policies regarding its use and access can be established.
- Registrants be allowed to protect their personally identifiable information and that there should be no penalization for inaccurate data entry.
- The Task Force makes recommendations regarding revision of the procedures by which domain name holders update and/or correct domain name data.
Registrar Constituency
The position of the Registrar Constituency is included as Appendix F.
Summary:
The Constituency position observes that:
- The issue of a useful and sustainable model for access to registrant data
is an issue of primary concern to the Constituency.
- Registrars are the primary caretakers of Whois access and Whois data in
the gTLD namespaces.
- Registrars are a diverse group of companies employing a broad range of business
models in many different countries.
- The primary interest of Registrars regarding this issue is that of commercial
implementer, operator and caretaker.
- The current body of policy allows Registrars to uphold their obligations
in a responsible manner that does not impinge the contractual rights or obligations
of other parties to these agreements.
- ICANN's existing program of registrar/registry compliance and education
is a necessary element of ICANN's function and should receive the full support
of the community.
The Constituency position recommends that:
- ICANN continues to develop its ongoing compliance program to ensure that contracted parties are appropriately meeting their obligations under the various agreements.
- ICANN does not ratify any Whois related policy that substantially alters the rights and obligations found in current policy.
- The GNSO Council undertakes a specific examination of Registrar data collection and protection practices and reports on the policy implications of the various data protection regulations in effect around the world.
Registry Constituency
The position of the Registry Constituency is included as Appendix G.
Summary of ICANN's InterNIC
WDPRS Report
On March 31, 2004 ICANN published the first of its reports concerning the InterNIC
Whois Data Problem Reporting System. The entire report can be found at http://www.icann.org/whois/wdprs-report-final-31mar04.htm.
Key Findings
- Over the course of the eighteen-month reporting period (Sep-02 through Feb-04), the system received 24,148 confirmed Whois inaccuracy reports.
- 82% of the reports concerned domain registrations in .com, and .net and .org accounted for 13% and 5% of all reports respectively. An enhanced version of the system has recently been launched that will include not just the legacy gTLDs, but all gTLDs under contract to ICANN: .aero, .biz, .com, .coop, .info, .museum, .name, .net, .org, and .pro.
- 54.7% of the reports submitted included an indication that the registrant's mailing address was inaccurate.
- A total of 16,045 unique domains names were the subject of Whois Data Problem Reports meaning that roughly 1/3 of all submissions were duplicates. The most common reason for the submission of multiple reports for one domain name (thus creating the duplicates) were efforts to shut down domains that were alleged to be the source or subject of spam.
- More than 40% of all the reports (9,938 out of 24,148) were submitted by just 0.3% of reporters (20 individuals out of 5,755 reporters). Over 20% of the reports had text fields that included the word "spam".
- The number of complaints sent to each registrar was generally proportional to each registrar's relative market share.
- On average, registrars were each sent approximately 0.00048 Whois inaccuracy reports per active registration per year, which equates to an average of 4.8 reports per year for every 10,000 domains under management.
- ICANN received 19 complaints indicating that the submitter was dissatisfied with the way a registrar handled the problem report.
- Registrars' voluntary participation in the tracking system at ICANN's request facilitated the monitoring of trends and tracking of compliance.
- The WDPRS has had a role in the correction of a substantial number of Whois data inaccuracies. As many as 36% of all Whois inaccuracy reports resulted in the correction of data or a deletion of a domain name. Whois inaccuracies measuring in the thousands have been corrected since the system was implemented.
- Beginning on 31 October 2003, all ICANN-accredited registrars were obligated to comply with the new "Whois Data Reminder Policy." The WDRP is intended to be an additional step to improve Whois data accuracy. Experiences with the implementation of that new policy will be the subject of an ICANN report to be published by 30 November 2004.
- In ICANN's planning for Fiscal Year 2004-05, there is provision for additional dedicated staff resources to monitor the Whois Data Problem Report System, to obtain accurate and useful statistical data, and to monitor registrar and registry compliance with Whois service, privacy and accuracy obligations.
Background and Overview
of the WDPRS
ICANN's Memorandum of Understanding with the United States Department of Commerce
requires that ICANN publish an annual report that provides statistical and narrative
information concerning community experiences with the InterNIC Whois Data Problem
Reports System. This report will also include an evaluation of the impact of the
WDPRS on improved accuracy of Whois data.
Whois data for gTLDs includes information about the registrant, administrative
contact, technical contact and nameservers associated with each domain name. This
information is used for a variety of purposes including identifying and verifying
online merchants, investigations by consumer protection and other law enforcement
authorities, determining whether a domain name is available for registration,
identifying the source of spam e-mail, enforcement of intellectual property rights,
addressing cyber-attacks and other wise resolving technical network issues. Whois
services have been available on the internet since the early 1980s, and continue
to be broadly used.
ICANN implemented the WDPRS on September 3, 2002 in order to assist registrars
in complying with their contractual obligations. The goal of the WDRPS is to streamline
the process for receiving and tracking complaints about inaccurate data and incomplete
Whois data. Reports are submitted through the InterNIC website which is operated
by ICANN. The centerpiece of the WDPRS is a centralized online form, available
at http://wdprs.internic.net, for submitting reports about Whois data inaccuracies.
Reports received via the WDPRS are forwarded to the responsible registrar for
handling. ICANN's experience has been that accredited registrars do conscientiously
comply with their contractual obligations by acting promptly to correct incomplete
or inaccurate data that is brought to their attention.
Eighteen months of experience have brought to light several areas where the original
WDPRS could be improved. Specifically, the originally deployed system did not
include a gTLDs under contract with ICANN, included excessive manual processes,
imposed administrative burdens on registrars who chose to comply with the system,
did not capture adequate statistics and lacked integrated mechanisms for monitoring
and receiving feedback from persons who submitted reports. To correct these deficiencies
and improve the overall system, ICANN has recently launched an improved version
of the system.
The WDPRS has had a role in the correction of a substantial number of Whois data
inaccuracies. As many as 36% of all Whois inaccuracy reports resulted in the correction
of data or a deletion of a domain name. Whois inaccuracies measuring in the thousands
have been corrected since the system was implemented.
One additional step recently taken by ICANN to improve Whois data accuracy is
the implementation of the "Whois Data Reminder Policy". This new policy
is an ICANN Consensus Policy as defined in the "Registrar Accreditation Agreement"
and is therefore binding on all accredited registrars. Further details can be
found at http://www.icann.org/registrars/wdrp.htm.
Matters
Requiring Further Consideration and Proposed Best Practices
The surveys conducted by Task Force 3 provided limited input that could serve
as a basis for identifying and assessing best practices for improving data accuracy
and verification. Taking these limited inputs into account, the Task Force compiled
a preliminary list of matters requiring further consideration and proposed best
practices, which are set forth below. Also included is the vote of each constituency
on the particular statements and recommended best practices. The vote of the ALAC
was taken without prejudice as to whether or not that vote would be counted, in
light of the anticipated legal opinion from ICANN counsel on that issue.
Matters Requiring Further Consideration
- ICANN should work with all relevant parties to continue to create its ongoing
compliance program to ensure that contractual parties are meeting the WHOIS-related
provisions of the present agreements. ICANN should devote additional resources
to such a compliance program in order to provide adequate support. See http://gnso.icann.org/issues/whois-privacy/raa-whois-16dec03.shtml.
ICANN should work with and assist registrars in developing, in consultation
with other interested parties, and by a date certain, "best practices" concerning
the "reasonable efforts" which should be undertaken by registrars to investigate
reported inaccuracies in contact data (RAA Section 3.7.8). See http://www.dnso.org/dnso/notes/20030219.WhoisTF-accuracy-and-bulkaccess.html.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- In developing such a program, ICANN should consider:
- The resources assigned to manage this plan, including up front and careful
consideration of the costs associated with implementing various recommendations
for registrars and flexible options for registrars to implement the policies
in a compliant manner;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- The specific elements of compliance that the internet community is primarily
concerned with;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Measurement and reporting mechanisms that allow appropriate analysis
of the effectiveness of this ongoing program including existing compliance
assistance mechanisms such as ICANN's online Whois data inaccuracy reporting
tools;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Continued outreach to and education of affected stakeholders to ensure
that existing requirements and obligations are understood and met and
that new requirements are captured and appropriately dealt with. This
effort should ensure that ICANN advisories related to this issue are specifically
brought to the attention of newly accredited Registrars and that resources
be made available to the Registrar community to ensure that the impact
and scope of these obligations are apparent and understood;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Requiring that informational resources be provided to new Registrants
and brought to their attention via the registration agreement that all
Registrants must agree to prior to the activation and renewal of their
gTLD registration, based on a model version of materials, so that no registrar
gains a competitive advantage from differential treatment of this requirement;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Ongoing development and promotion of gTLD Registry, Registrar and Registrant
best practices that foster the accuracy of the Registrant data contained
in the Whois database.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Any Best Practices that are viewed as being mechanisms for improving data
verification on a global basis should be developed by or under the direction
of ICANN, soliciting the cooperation of responsible registrars, and disseminated
to accredited registrars and other relevant parties as part of ICANN's ongoing
educational and compliance initiatives. In such efforts, recognizing that
technology/software may play a role in developing this solution, ICANN should
rely on the competitive marketplace for the provision of relevant technology
and should mandate only the outcome, not how the Registrar accomplishes the
outcome. ICANN should consider retaining an independent third party which
could, on a confidential basis, gather the critical underlying data germane
to assessing current data verification practices in the registrar and other
relevant industries, as well as from selected ccTLDs. In addition, ICANN should
consider the work of the IETF, including its work on the IRIS protocol being
developed by the CRISP working group.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Specific examination of registrar data collection and protection practices
should be undertaken, including investigating all options for the identification
and viability of possible: A) automated and manual verification processes
that can be employed for identifying suspect domain name registrations containing
plainly false or inaccurate data and for communicating such information to
the domain name registrant; and b) readily available databases that could
be used for or to assist in data verification, taking into account the wide
variety of situations that exist from region to region. The GNSO Council or
other appropriate body should participate in specific examination of registrar
data collection and protection practices to ensure consideration of policy
implications, including various data protection regulations that may affect
certain jurisdictions in which registrars operate.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
Proposed Best Practices
- ICANN should also consider including the “last verified date"
and "method of verification" as Whois data elements, as recommended
by the Security and Stability Advisory Committee. See Whois Recommendation
of the Security and Stability Advisory Committee, available at http://www.icann.org/committees/security/sac003.htm.
(“Whois data must contain a "Last Verified Date" that reflects
the last point in time at which the information was known to contain valid
data. It must also contain a reference to the data verification process.”).
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- With input from the relevant contracted parties and other interested stakeholders,
ICANN should solicit direct input from each registrar relating to its current
level of compliance with existing agreements, and plans to improve the accuracy
of Whois data that it collects. The plans will be made publicly available
except to the extent that they include proprietary data, and registrars that
fail to submit plans by a date certain would be publicly identified. The plans
should state specific steps for improving WHOIS data accuracy, including:
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Identification and public disclosure of a designated contact point for
receiving and acting upon reports of false Whois data;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Plans to work with ICANN to train employees and agents regarding the
Whois data accuracy requirements;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Taking reasonable steps to screen submitted contact data for falsity,
including use of automated screening mechanisms, manual checking, spot-checking,
and other verification techniques for submitted data;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Steps to correct false data in all registrations that are substantially
identical to that in the initially false registration that has come to
the registrar's attention;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Steps to improve the accuracy of contact data submitted to it through
re-sellers or other agents;
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Measurements for improving performance of the quality of the registrar's
Whois data.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- ICANN should require domain name registrants to update and correct Whois
data on an annual basis including, for example, clear instructions to domain
name registrants of this obligation and special email addresses for expedited
and priority handling of such updates.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- ICANN should consider requiring Registrars to verify at least two of the
following three data elements provided by domain name registrants - phone,
facsimile and email - and ensure that these elements function and that the
Registrar receives a reply from these means of communication. Where none of
the three data elements works, then the domain name should immediately be
placed on hold. If only one of the means of communication works, then the
domain name shall be placed on hold for a period of 15 days in which the domain
name registrant shall correct all of the WHOIS data elements. If the domain
name registrant fails to correct all of the WHOIS data elements during that
time frame, the domain name registration shall be cancelled.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- Where a domain name registration is cancelled due to the non-functionality
of WHOIS data elements - phone, facsimile, and email - the domain name can
be reconnected for a fee to be set by the registrar. Upon reconnection of
any domain name in circumstances where the domain name had been placed on
hold or was immediately cancelled, the Registrar shall verify all data elements
before reconnecting the domain name. The Registrar should ensure that the
reconnection charge it imposes is sufficient to cover the costs of the heightened
verification it must perform in reconnecting a previously cancelled domain.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- When a domain name registration is cancelled (or suspended, etc.) for false
contact data, all other registrations with identical contact data should be
cancelled (or suspended, etc.) in like fashion.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- ICANN staff should undertake a review of the current registrar contractual
terms and determine whether they are adequate or need to be changed in order
to encompass improved data accuracy standards and verification practices as
a result of the current PDP.
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
- ICANN should develop and implement a graduated scale of sanctions that can
be applied against those who are not in compliance with their contractual
obligations or otherwise violating the contractual rights under these agreements
For |
Against |
Abstain |
| CBU
IPC
ISP
Registry |
ALAC
NonComm
Registrar |
|
Comments
Provided in Submitting Vote or Position on Best Practices Section
At Large Advisory Committee Position
I'm writing to you as ALAC's liaison to the GNSO Council; I understand
that Vittorio Bertola, ALAC's liaison to TF3, is traveling and can't reach you
by e-mail. Apologies for submitting the vote slightly late.
For purposes of tallying a vote, ALAC votes AGAINST all recommendations made in
the proposed TF3 report.
For purposes of giving advice, we respectfully suggest that the report, in its
current state, not be presented for public comment, but rather be substantially
revised.
The document put up for a vote on TF3 is not even suitable as a basis for public
comment or decision-making on the Council and Board levels: Such a document would
have to discuss the Task Force's inputs and deliberations, it would have to compare
the recommendations made to the baseline policy and practice effective today,
and it would also have to include discussion of the effects (and side effects)
of the recommendations made. Making the addressees and status (consensus policy?)
of individual recommendations transparent would also contribute to enabling an
informed discussion of the proposals made.
Specific to the area of WHOIS accuracy, it would also be helpful to compare any
recommendations made to the results of the DNSO Whois Task Force's and Implementation
Committees work from 2002/2003, and to make sure that the considerable body of
public comment and community discussion is taken into account that was generated
back then.
Thomas Roessler, May 27, 2004
Commercial and Business Users Constituency
The BC votes in support of the Best Practices section of the Preliminary Report
in the overall interest, at this late date, of moving a preliminary report forward
for public comment. This vote is cast, however, with some reservations, which
do not affect our general support to place the preliminary report for open, public
comment.
In particular, we are troubled by the level of detail in Item 8, which recommends
that a domain name be put on hold for a period of 15 days and requires that the
domain name be cancelled if the registrant fails to correct the registration within
that time frame. We question whether the report should be dictating any specific
time frames at this stage and
serious consideration must be given into whether the 15 day strict cancellation
policy can be reasonably implemented.
In item 10, requiring that a domain name registration be cancelled or suspended,
etc. for
false contact data, along with all other registrations with identical contact
data, needs additional clarification. This suggestion requires further study into
how it can be reasonably implemented without imposing strict monitoring obligations
on registrars or imposing undue costs on any stakeholder.
On behalf of the BC, I'd like to acknowledge everyone's hard work on these difficult
issues. We look forward to working with you all, as always, in a constructive
manner as we strive toward reaching consensus policy.
Sarah B. Deutsch, Representative, May 27, 2004
Intellectual Property Constitutency
Voted in favor of all aspects of the Best Practices Section of the "Preliminary
Report" without comment.
Brian Darville, Representative
ISP Constituency
Voted in favor of all aspects of the Best Practices Section of the Preliminary
Report "in the interest of moving ahead . . . ."
Greg Ruth, Representative, May 28, 2004
Non-Commercial Users Constituency
I marked a vote for each of the provisions of the document, though I'd like to
convey my vote is clearly against the entire Best Practices document as it currently
stands rather than against the specific provisions. I appreciate the work that
has gone into this and there are some provisions that I would actually support,
but not enough to accept them the way the current document is framed.
Frannie Wellings, Representative, May 27, 2004
Registrar's Constituency
I have taken counsel from members of the Registrar Constituency and other GNSO
participants and must respectfully vote "no" on all counts, with qualification,
on the proposals contained in this draft.
Those qualifications being:
- There are a limited number of highly onerous requirements that cause substantial
portions of the document to become unacceptable to registrar interests. For
instance, the requirement to admit liability and submit to a managed remediation
plan in the event that a registrar is non-compliant with some or all of their
Whois related obligations is an unworkable aspect of this document. However,
many of the subordinate terms would be acceptable to the members of the Registrar
constituency if they were not associated with the liability that comes with
the declarations.
- The proposal mixes active and passive verification techniques with seeming
disregard for the actual quality of the end result. It is the registrar position
that passive verification coupled with mandatory participation in the Whois
Data Problem Reporting System will create a substantial increase in the quality
of the data contained in the Whois database without undue impact on registrants
and registrars. Active verification at the time of registration, beyond simple
data characteristic checking, is an unproven and unexplored option that is
likely to impose significant cost and burden on registrants and registrars.
- The proposal does not adequately consider the true impact of existing programs
nor does it consider potential improvements to these programs in an effort
to achieve whois data accuracy. The proposal is silent on existing programs
like the WDPRS despite very strong data that it is a viable option that we
should seriously examine and potentially mandate as policy.
- The proposal does not sufficiently consider the inputs of the SSAC and other
historical GNSO proposals including the results of the prior Whois Task Force.
ICANN and the GNSO have developed a substantial number of recommendations
and considerations that were not considered for inclusion in this report.
The sum of many of these is likely to have a drastic impact on increasing
the Whois data quality.
Overall, there are a number of elements of this proposal that the registrar constituency
could support, but given the unintended - but likely - consequences, we must formally
oppose this particular version.
I sincerely appreciate the investment that has been made in this document by the
members of this task force and urge everyone to continue moving forward with this
difficult, but important process.
Ross Rader, Representative, May 27, 2004
Registries Constituency
Voted in support of items 1-7 & 12.. abstained on items 8,9, & 10.
Ken Stubbs, Representative, May 28, 2004
Registrar
Constituency Minority Report
Matters Requiring Further Consideration, Policy Recommendations and Proposed
Best Practices
The GNSO Registrar Constituency does not believe that the findings of Whois TF3 are well-suited to advance the goal of increasing the overall accuracy of the Whois database and in some cases may actually increase data inaccuracy. While we do not support the existing recommendations of the task force, we fully support the overall policy objectives of the GNSO and have therefore created an alternate set of recommendations that we believe can be implemented and achieve the goals of the task force as set out in the GNSO Council' terms of reference for TF3.
- Proposed Best Practices
- Registrars must identify and disclose a designated public contact point
responsible for receiving and acting upon complaints received via the
mandatory Whois Data Problem Reporting System (WDPRS) and related whois
record data accuracy issues.
- ICANN should amalgamate and publish this list on their website.
- Registrar should certify that this contact point has been trained
on Whois Data Accuracy policy requirements.
- Registrars should work together to create a clear, consistent process
in order to enable registrants wishing to update or correct their established
whois data to do so in a quick and simple manner to ensure compliance
with Section 3.2.2 of the Registrar Accreditation Agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm#3.2.2).
- Registrars should take reasonable steps to prevent Registrants from
supplying inaccurate data at the time of registration.
- Registrars should act upon complaints received via the WDPRS within one week of receipt.
- Registrars must resolve WDPRS complaints within 45 days of receipt.
- Acceptable resolution includes;
- correction of the report inaccuracy
- confirmation of the validity of the data
- cancellation of the registration in the event that the Registrant
does not provided corrected data in response to valid reported
inaccuracies.
- Policy Recommendations
- Participation in ICANN's Whois Data Problem Report System should be
a mandatory contractual requirement for registrars and registrants. The
WDPRS System should be the focal point in ICANN's efforts to promote Whois
data accuracy.
- Registrars must respond to complaints received via the WDPRS and
act upon them in a timely manner
- Registrars must close problem reports when the issue has been resolved
or the name has been canceled.
- Registrars must attempt to contact registrants regarding the reported
inaccuracy through all means available to them.
- It is recommended that Registrars first attempt to use automated
means such as an email sent to each of the domain name contacts
and if unsuccessful undertake a second attempt via telephone or
fax numbers and finally via post.
- If the Registrar is incapable of contacting the Registrant or an Agent of the Registrant via one of these means within the time permitted by this process, the Registrar should place the registration on hold for a period of 30 days. If within this period the data accuracy issues are not resolved, then the Registrar should cancel the registration permanently.
- The Registrar shall verify the corrected data prior to reactivating
the domain name or closing the WDPRS problem report. Registrars
may choose to perform this function on a for-fee basis.
- The identities of parties filing complaints must be made verifiable by the party accepting the accuracy complaint. The WDPRS system should require the payment of a reporting fee or other mechanisms to discourage frivolous complaints.
- Amend RAA to ensure that Registrants who willfully provide false contact
information or fail to respond to requests for data verification within
30 days will have their registration(s) cancelled.
- Note: This is currently an optional condition
- We propose that the task force endorses these additional recommendations and request that the GNSO Council consider them for further policy development work;
- The Task Force endorses the follow recommendations of the Security and Stability Advisory Council;
- Whois data must contain a "Last Verified Date" that reflects the last point in time at which the information was known to contain valid data. It must also contain a reference to the data verification process.
- A Whois service must discourage the harvesting and mining of its data.
- Whois services must provide mechanisms to protect the privacy of registrants.
- Whois records known to be false or inaccurate must be frozen or held until they can be updated or removed.
- Whois records that have information that can not be validated may be frozen or held until it can be verified.
- A standard format for Whois data must be developed.
- A publicly available list of publicly available Whois servers must be available using a widely known and available resource
- A Whois service that supports searching in the current architecture of distributed indices and separated registry and registrar services must be developed.
- The Task Force endorses the following additional recommendations received
throughout the consultative process;
- Registrars must verify Whois data in a timely fashion when specific data accuracy issues are brought to their attention.
- Registrars must be allowed to charge for these services.
- Potential implementations may include;
- problem reporting fee
- data inaccuracy correction fee
- domain name "reconnection fee"
- other?
- Such fees are only appropriate in instances where Registrants
have not tried to previously update their data prior to the
filing of the problem report but were unsuccessful because
of Registrar non-compliance with Section 3.2.2 of the Registrar
Accreditation Agreement (http://www.icann.org/registrars/ra-agreement-17may01.htm#3.2.2)
- Registrars should be permitted to charge for all data verification activities.
- The GNSO should undertake the development of a policy that provides a mechanism to forgive the Redemption fee in cases where the registrant can ultimately verify the accuracy but had just been unavailable previously. It may also be appropriate to develop this through the implementation analysis process if applicable.
- ICANN should work with all relevant parties to continue to create
its ongoing compliance program to ensure that contractual parties
are meeting the WHOIS-related provisions of the present agreements.
In developing such a program, ICANN should consider:
- The resources assigned to manage this plan, including up front and careful consideration of the costs associated with implementing various recommendations for registrars and flexible options for registrars to implement the policies in a compliant manner;
- The specific elements of compliance that the internet community is primarily concerned with;
- measurement and reporting mechanisms that allow appropriate analysis of the effectiveness of this ongoing program including existing compliance assistance mechanisms such as ICANN's online Whois data inaccuracy reporting tools;
- continued outreach to and education of affected stakeholders
to ensure that existing requirements and obligations are
understood and met and that new requirements are captured
and appropriately dealt with. This effort should ensure
that ICANN advisories related to this issue are specifically
brought to the attention of newly accredited Registrars
and that resources be made available to the Registrar
community to ensure that the impact and scope of these
obligations are apparent and understood.
- requiring that informational resources be provided to new Registrants and brought to their attention via the registration agreement that all Registrants must agree to prior to the activation and renewal of their gTLD registration, based on a model version of materials, so that no registrar gains a competitive advantage from differential treatment of this requirement;
- ongoing development and promotion of gTLD Registry,
Registrar and Registrant best practices that foster the
accuracy of the Registrant data contained in the Whois
database
Appendix A – Position
Statement of the At-Large Advisory Committee
At-Large Advisory Committee statement on Whois Task Force III
March 19, 2004
Summary and recommendations
The At-Large Advisory Committee would like to express appreciation for the difficult
and time-consuming work that the Task Force has been doing.
However, we stress that trying to get accurate information from people who are
not willing to provide it is a waste of time and effort. No automated verification
scheme is able to tell between true data and plausible data, and thus such schemes
would only have the effect of increasing the number of crimes such as identity
theft and make reliable identification of actual fraudsters even more difficult.
Generic TLDs are a global resource which should be impartially accessible to registrants
from all parts of the world. Verification schemes usually do not cover all parts
of the world with the same effectiveness, and often information which may seem
implausible to an American eye will be actually true; so these schemes must not
be used to unfairly discriminate access to gTLDs depending on the registrant's
country. Also, any communication with the registrant should happen in the registrant's
own language; and the registrant should not be asked to bear the cost of verification
activities, since they are not part of the service he is asking for, but rather
of services desired by some third-party data users.
The actual feasibility of a verification scheme that meets these requirements,
even after the data gathering activity made by the task force, is still unproven.
For these reasons, we recommend against taking any action in this field at this
stage.
We thus suggest that the focus of the work on Whois accuracy is shifted from how
to force unwilling people to provide their true information to how to effectively
allow registrants who want to provide true information to do so. There are a number
of practical hurdles for any registrant to keep his/her data up to date, and removing
these hurdles would prove much more beneficial to the overall accuracy of the
Whois databases than going after an impossible and worrying dream of a global
centralized control system over registrants' identities.
Finally, we note that the Registrar Accreditation Agreement provisions about data
collection, display and accuracy requirements and their enforcement are clearly
illegal, and thus void, in a number of jurisdictions.
Thus we recommend that ICANN suspends any enforcement of those provisions until
the RAA and the related policies are amended so to comply with existing laws;
as clearly and repeatedly exposed in writing and in person by a number of relevant
public authorities, any other choice is likely to bring ICANN and involved registrars
to litigation with registrants and with the Privacy Authorities in European and
other countries.
A deeper analysis on the problem of Whois accuracy
We think that, to be able to solve a problem, you should first investigate the
reasons why it happens. In this case, you could roughly divide the registrants
whose data are inaccurate into four categories:
- Those who purposely provide inaccurate data for fraudulent reasons.
- Those who purposely provide inaccurate data to protect their privacy.
- Those who mistakenly provide inaccurate data.
- Those who provide accurate data at registration, but then fail to keep them up to date so that the information becomes inaccurate.
Until now, the general discussion on accuracy has been almost completely focused
on the first category - and we think this is an error. The purpose of the Whois
system is not to provide bullet-proof identification for those who register domains
and operate services on top of them, but rather to provide quick contact information
for those domain holders who want to be contacted. Turning the Whois system into
a certified directory of domain name owners would go beyond its purpose and, as
practice shows, is practically incompatible with its spirit and architecture.
Also, at the present state of technology and of operational practices, costs of
very secure authentification of world-wide registrants for all domain name registrations
would be high and would possibly destroy the domain name market as we know it
today. We think it might be more cost-effective (and also more respectful of basic
civil rights of people) to seek after fraudulent registrants once they actually
commit a fraud, rather than to presume that all registrants are to commit frauds
and so should be carefully screened in advance.
Finally, we point out that there is no verification system, other than requiring
a person to physically show up and exhibit a secure proof of identity such as
a passport or national ID document, that could tell between true personal data
and plausible, but fake, personal data. If going down the path of imposing stricter
and stricter checks on data as they are submitted by the registrant during the
registration process, after spending lots of time and lots of money on them, we
might actually discover that no benefit has arisen in terms of fraud prevention,
but that the stricter checks have caused a huge increase in crimes like identity
theft, which by the way are made easier by the very existence of the public and
anonymously accessible Whois system.
Said this, we think that an increased accuracy in the Whois database, if limited
to those registrants who actually agree to provide their data, would be highly
desirable. This is why we think that future activities in the field of enhanced
accuracy should not focus on the first category of the above list, but rather
on the other three.
We will not discuss here the issue of privacy protection, which is the subject
of another task force; we just stress that the overwhelming majority of those
who purposely provide inaccurate data does so for privacy protection reasons,
rather than for fraudulent intentions. Just allowing these people not to disclose
their data to the public, but just to the registrar, would actually avoid most
cases of wilful inaccuracy.
The third category is, according to our experience, somewhat small – also
because this kind of error is clerical and can easily be fixed in case there is
actual need to contact the owner. Once the registrant's desire to publish their
data is ascertained, some simple automated verifications could be made by the
registrar's system, to warn the registrant about possible errors.
However, creating an automatical verification algorithm for all countries and
scripts of the world might prove very difficult and prone to errors for less common
countries; the current practical examples only come from TLDs and environments
with geographically limited registrants. On the other hand, systems which provide
automatical verification only for residents of some countries could be acceptable
only as long as they do not prevent or make it unreasonably harder for residents
of “unverifiable” countries to register domains. This is why we think
that the output of this automated verification algorithms should only be used
as a warning to the registrant, but should not prevent the registrant from submitting
data that might seem incorrect, as they could possibly be absolutely correct.
We also note that requiring Roman-script information for registrants of those
countries who do not use Roman characters would be unduly discriminating them
in access to gTLDs. All registrants should be asked to provide their data only
in their local language and script, and just as an option they could be asked
whether they want to provide Romanized data as well. Requiring the ability to
type in Roman script to register domains in global generic TLDs is unacceptable.
Finally, we think that much could be done to improve the situation of the fourth
category – those registrants who would be happy to provide accurate information,
but who fail to keep it up to date. In fact, experience shows that updating Whois
data is a long and difficult process for registrants. In many cases, the registrant
has to send faxes, make phone calls, and suffer other costs while devoting a significant
amount of time; in other cases, the authentication mechanism used by registries
or registrars is based on the e-mail address (or on a username/password couple
which, if forgot, will be resent to the current e-mail address), so that a change
in the e-mail address of the registrant will make him/her unable to manage the
information, and will make these domains orphan. If you add this to the fact that
keeping personal data up to date in a public Whois registry certainly cannot be
the first worry of a registrant when he's changing address, phone number or e-mail
address, you realize that this is possibly the easiest cause of inaccuracy in
Whois databases.
Also, in many cases the registrant is only the last link in a long chain of interactions
that starts with a registry, then goes through an ICANN-accredited registrar,
a domain name reseller, a web hosting company, or even an “Internet-savvy”
friend who does the job for the registrant. We think that this is an unavoidable
consequence of the average registrant turning from a skilled engineer in a small
Internet, as it was when Whois was designed, to a non-technical average person
in a mass Internet. It is very difficult to create the awareness of the existence
and purpose of the Whois database for non-technical persons on a mass scale, and
we think this is another reason why we should never expect the Whois to be a terribly
accurate list of all registrants.
However, for this category the problem possibly lies in the lack of simple online
systems for the registrant to edit his/her data in the database at no cost. Thus
we think that one of the two following solutions should be tried:
- Requiring registries to directly deal with registrants' update requests, by supplying them a virtual certificate or account at registration, plus offline procedures to recover access if such account is lost;
- Changing the architecture of the Whois database from centralized to distributed.
Since the first option would raise many concerns in terms of business models,
customer ownership, and cost recovery, the second could possibly be more interesting.
After all, the very reason for which the DNS system was created, replacing the
old centralized hosts table, was the impossibility of keeping this centralized
table up to date. We should simply apply the same principle and move the data
at the edge of the network, by embedding Whois servers into DNS server implementations.
Whois queries could then be sent directly to the authoritative name servers for
the domain, and only if no reply is received, the registry could be used as a
fall-back. This way, registrants would be able to keep their Whois information
up to date as easily as they keep their zone files up to date, and even if this
would not completely solve the problem, it would possibly cause a dramatic increase
in the number of Whois records that are actually kept updated.
We thus recommend a shift in the focus of accuracy-related discussions, so to
deal with those types of inaccuracy that can and should actually be solved, rather
than dealing with world-wide verification and law enforcement systems that are
not practically conceivable at the present social and political state of our planet,
and that would anyway have to be discussed at other political levels.
Appendix B - Position Statement
of the Business Users Constituency
Input to the GNSO Council task forces on WHOIS - April 2004
In order to provide input to all three Task Forces (TF) and provide a broader
statement from the Commercial and Business User Constituency (hereafter Business
Constituency or BC), we have consolidated our input into a single document.
Members of the Business Constituency use the Internet to conduct business. The
Business Constituency is a constituency representing customers of providers of
connectivity, domain names, IP addresses, protocols and other services related
to electronic commerce in its broad sense. The BC membership includes corporations,
entrepreneurs, and associations.
The BC recognizes that the Internet is changing and evolving into a more commercial
and widely used communication mechanism, and that the characteristics of the Internet
users are also changing over time. It is generally agreed that more and more users
are registering domain names for a wider and wider variety of purposes. As the
user characteristics are changing and the Internet is growing, it is important
to keep in mind the key issues of Internet stability. The BC believes that accurate
WHOIS data is an essential element to that core value. In examining the possibility
of changes in the WHOIS, the BC believes that better mechanisms are needed to
ensure accurate WHOIS data, while balancing the needs of the full set of stakeholders
and affected parties.
Principles for the use of WHOIS
Striking a balance among concerns and needs of the different stakeholders related
to accuracy, reliability, access and privacy issues is the goal. This is consistent
with the OECD Guidelines on the Protection of Privacy and Trans-border Data Flows
of Personal Data, the international consensus, that works to strike a balance
between effective privacy protection and the free flow of information.
Purposes of Business User access to WHOIS:
Business users access the WHOIS database to obtain registrant contact information for the following reasons:
- to verify the availability of a name they might wish to register
- to thwart security attacks of their networks and servers
- to validate the legitimacy of a website for transactions
- to identity consumer fraud and cyber-scam incidents
- to undertake routine reviews to protect their brands
- to support UDRP and other infringement proceedings
- to combat spam.
The BC's guiding principles related to WHOIS are:
- Accuracy and access. Accuracy and access to accurate data are the top priorities. Enforcement of accuracy requirements is essential.
- Use of data. It is key to find a balance between data use for legitimate purposes and avoiding unwelcome or illegal use.
- Balance of Stakeholder needs. Any changes in access to WHOIS must be balanced
across the needs of all stakeholders and take into account the costs to the
registries/registrars to maintain more complex systems, as well as the burden
on the legitimate users of WHOIS.
- Marketing. WHOIS data should never be used for marketing purposes. This includes precluding the use of WHOIS data for marketing by the registry or registrar other than for services that are directly applicable to registration or other purposes that are not inconsistent with the original purpose [see OECD Guidelines] or for which the registrant has explicitly opted-in.
- Scope. The focus for now should be ensuring a consistent system of WHOIS
across generic top-level domain names. Any discussion of WHOIS policies that
might affect WHOIS within country-code domain names should be addressed later
and through the new Country Code Names Supporting Organization.
Task Force 3: Mechanisms to improve quality of contact data
The BC notes:
- Accuracy because WHOIS is public communication. A domain
name registration in a TLD is a public form of communication, and as such,
requires accurate data for the WHOIS registry.
- Accuracy because users need accurate data. The average
Internet user, whether business, government, NGO or individual, has an expectation
of accurate WHOIS information, which they then use to address legitimate issues:
verifying the legitimacy of a web site, pursuing a network problem, addressing
IP infringement concerns, calling for assistance from law enforcement, etc.
- Accuracy is important for individuals and organizations. The
same concerns about the need for accurate data are independent of the nature
of the registrant. A non-statistical survey of BC members regarding the situations
they have experienced with trademark infringements, consumer fraud, and network
issues indicates that there are problems with individuals and with organizations.
However, none of the consumer fraud incidents encountered by the well-known
brand holders involved organizations. The five situations examined all involved
individuals who provided false information. Discussions with law enforcement
have and continue to evidence similar problems with individuals.
- Some examples of data authentication exist in other industries, including financial services and in some of the ccTLDs.
The BC therefore proposes:
- Best Practices are available from other sources: The BC
recommends further examination of best practices in authentication in other
industries and from selected ccTLDs.
- Changes to the contracts are needed to ensure there is enforcement.
The requirement to provide accurate data is a part of the Registrar contract,
yet it appears that few registrars fulfill this requirement. The BC believes
that this must be enforced by ICANN while allowing flexibility in the way
registrars carry out this obligation. The previous WHOIS TF discussed the
development of graduated sanctions. They also heard from several ccTLDs with
successful data verification practices. The BC calls for the development of
policy to evaluate a system of graduated sanctions.
Recommendation: more research is needed, and standards may offer solutions
to development of modifications to WHOIS. Discussion of WHOIS is limited
by a lack of research which would allow fact based policy. The ccTLD registries
also have significant experiences which could be the better understood and provide
useful "understanding" to guide gTLD policy development. The BC encourages the
GNSO Council to seek current information on both the CRISP project (on WHOIS standards
undertaken by the Internet Engineering Task Force) and any other relevant standards
process, to examine the role of these potential standards in providing a solution.
The BC recognizes that the cost of implementing changes in WHOIS must be analyzed
and understood as changes are considered. Changes in WHOIS should not become an
"unfunded mandate" upon registrars.
Appendix C - Position Statement
of the Intellectual Property Constituency
IPC Constituency Statement
Whois Task Force 3
March 24, 2004
This statement responds to the issue identified in the purpose statement of the
terms of reference for Task Force 3: see http://gnso.icann.org/issues/whois-privacy/tor3.shtml.
The purpose of this task force is to develop mechanisms to improve the quality
of contact data that must be collected at the time of registration, in accordance
with the registrar accreditation agreement (in particular clauses 3.3.1 and 3.7.7.1),
and the relevant registry agreement (e.g. Unsponsored TLD Agreement: Appendix
O (.biz)).
IPC’s recommendations for improvement of data quality include the following:
– ICANN should work with all relevant parties to create a uniform, predictable, and verifiable mechanism for ensuring compliance with the WHOIS-related provisions of the present agreements, and should devote adequate resources to such a compliance program. The Registrar Accreditation Agreement makes the requirements clear. See http://gnso.icann.org/issues/whois-privacy/raa-whois-16dec03.shtml. However, this agreement is only as good as the level of compliance with it, and recent decisions by US courts indicate that only ICANN can enforce these agreements. See Register.com v. Verio, Inc., 356 F.3d 393 (2d Cir. 2004).
– ICANN should ask each registrar to present a plan, by a date certain, for substantially improving the accuracy of Whois data that it collects. The plans will be made publicly available except to the extent that they include proprietary data. The plans should include at least the following features:
– identification and public disclosure of a contact point for receiving and acting upon reports of false Whois data;
- how the registrar will train employees and agents regarding the Whois data accuracy requirements;
- how the registrar will take reasonable steps to screen submitted contact
data for falsity, which steps may include use of automated screening mechanisms,
manual checking, including spot-checking, and verification of submitted
data;
- when false data comes to the registrar's attention, whether through a third-party complaint or otherwise, how the registrar will treat other registrations in which the contact data submitted is substantially identical to that in the registration that has come to the registrar's attention;
- how the registrar monitors the extent to which contact data submitted to it through re-sellers or other agents is false or significantly incomplete, and what the consequences are for re-sellers or agents whose performance is unacceptable;
- how the registrar evaluates compliance by its current registrants with the obligation to provide accurate and current contact data;
– how the registrar measures performance in improving the quality of the
Whois data it manages
– The RAA and gTLD registry agreements should be modified to provide for
a regime of graduated or intermediate sanctions for patterns of violations by
a registrar of the Whois data accuracy obligations of those agreements. (This
recommendation is without prejudice to the possibility that such a regime would
also be appropriate for encouraging compliance with other provisions of these
agreements.)
– The PDP with regard to the issues addressed by TF3 should mutate into an ongoing effort with the following goals:
- Research and dissemination of information on practicable and cost-effective methods used to improve the quality of identifying and contact data submitted by customers in online transactions outside the realm of gTLD domain name registration
- Development of best practices within the realm of gTLD domain name registration for improving the accuracy, currentness, and reliability of contact data in the Whois database
Appendix D - Position Statement of the Internet
Service and Connectivity Providers Constituency
ISPCP CONSTITUENCY WHOIS STATEMENT
April 2004
Introduction
The ISPCP Constituency herein provides input to the three Whois Task
Forces as required by ICANN by-laws. The ISPCP stresses the need for balanced
policy that takes into consideration the interests of all stakeholders, and allows
for the effective enforcement of civil and criminal laws while protecting registrant
information from marketing or other illegitimate/illegal uses. This goal is the
underlying theme running throughout the comments below. It is also consistent
with commonly accepted tenets of privacy protections and laws throughout the world.
ISPCP Uses of Whois Data
- to research and verify domain registrants that could vicariously cause liability for ISPs because of illegal, deceptive or infringing content.
- to prevent or detect sources of security attacks of their networks and servers
- to identify sources of consumer fraud, spam and denial of service attacks and incidents
- to effectuate UDRP proceedings
- to support technical operations of ISPs or network administrators
Terms of Reference for Whois Task Forces
WHOIS Task Force 3
– Focused on developing mechanisms to improve the quality of
contact data that must be collected at the time of registration in accordance
with the registrar accreditation agreement and the relevant registry agreement
– Related issues:
- Verification of data at time of registration
- Ongoing maintenance of data during registration period
- Protecting against deliberate submission of false information
ISPCP Position
Task Force 3 - Improving Accuracy of Collected Data
Finally, the ISPCP Constituency is quite concerned about the abundance of inaccurate
and incomplete data. Such deficiencies significantly hinder ISPs' ability to identify
and contact registrants. Thus, ISPs support ready access to accurate Whois data
to facilitate resolution of network problems, sourcing of spam. Further, ready
access to accurate data is necessary for securing our networks and enforcing our
acceptable use policies.
Because of the heavy reliance by ISPs on registrants’ data to facilitate
future contact with the registrant for business issues, security and stability
issues, intellectual property infringement and a myriad of other legal issues,
accuracy is of the utmost importance.
While automated verification software does exist, its accuracy and therefore its
reliability on a global scale is suspect. Registrars should take multiple steps
to ensure that the data they receive is accurate, and there should be some enforcement
mechanism to ensure registrars’ compliance. In addition, it would be useful
for registrars to have a list of best practices that further help verify data
and produce an accurate database.
The ISPCP Constituency proposes:
- The creation of a best practices document aimed to improve data verification, with the prospect of a global application.
- Registrars take increased and more uniform measures to verify accurate data. The ISPCP does not advocate removing all flexibility from current or future registrar practices, but some uniformity and compliance with best practices will net a more accurate database.
- ICANN staff should undertake a review of the current registrar contractual terms and determine whether they are adequate or need to be changed in order to encompass improved data accuracy standards and verification practices.
Appendix E - Position Statement
of the Non-commercial Users Constituency
NCUC STATEMENT FOR WHOIS TASK FORCE 3
WHOIS Task Force 3 (TF3) deals with the accuracy of WHOIS data, established to
determine the best mechanisms to improve the quality of the data. The Non-Commercial
Users Constituency (NCUC) approach to Task Force 3 is guided by the following
principles:
– First, the NCUC does not believe that accuracy of WHOIS data is unconditionally desirable. These task forces were established with the assumption for task force 3 that accuracy is desirable in all cases and regardless of the extent of the WHOIS data elements. The NCUC recognizes the need to protect such extensive and public data from identity theft and spam and to protect freedom of speech. Submission of personally identifiable contact data should be a choice, not a requirement. Many people are indeed forced to enter incorrect data in order to protect themselves.
– Second, the NCUC thinks it imperative that ICANN recognize the well-established data protection principle that the purpose of data and data collection processes must be well-defined before policies regarding its use and access can be established. The purpose of WHOIS originally was identification of domain owners for purposes of solving technical problems. The purpose was _not_ to provide law enforcement or other self-policing interests with a means of circumventing normal due process requirements for access to contact information. None of the current WHOIS Task Forces are mandated to revise the purpose. Therefore, the original purpose must be assumed until and unless ICANN initiates a new policy development process to change it.
– Third, registrants should be allowed to protect their personally identifiable information, a protection recognized by the European Data Protection Directive, Article 29 Working Party, by the OECD Privacy Guidelines and by data protection legislation across the world. As George Papapavlou and Giovanni Buttarrelli pointed out, it is possible that WHOIS data accuracy requirements may indeed be breaking many of these laws. The NCUC submits that accuracy is desirable solely to the extent necessary to serve the purpose of the data collection and the interest of the data subject; accordingly, technical information should be accurate. However, there should be no penalization for inaccurate data entry given that the extent and the accessibility of the data currently required goes well beyond the purpose of data collection. As Papapavlou discussed, when there are various options to achieve a purpose, priority must be given to the least privacy-intrusive option.
– Fourth, while this task force was established with privacy defined as out of scope, privacy is key to accuracy of data entry. Data protection principles have to be implemented and enforced as a whole. The best way to improve the accuracy is to provide privacy and security. Show registrants that their data will be safeguarded, that their e-mail accounts will be protected from spam and that they themselves will be protected from stalkers and other criminals, and they will be more likely to enter accurate data. Users will continue to feel the need to protect their privacy by their own means, to defend themselves, if the policies of WHOIS data do not.
– Finally, if there is a way to facilitate accuracy of data for those who wish to submit accurate data, in other words opt-in, the NCUC would be supportive. We are against, however, calls to require accurate data entry and penalize or even criminalize those who choose not to. This task force has reached out to various companies in order to collect data on verification procedures, but has found this process difficult (ironically, because companies are concerned with the privacy of their policies and procedures). The responses submitted to the TF3 questionnaire are sparse. We do not have enough data to allow Task Force 3 to reach any conclusion of best practices for verifying accuracy. However, this Task Force has received testimony that domain name holders in numerous cases are having a very difficult time updating, revising and changing their own data. This is currently the most important issue facing the task force: that the data subjects themselves cannot update their domain name information. Further, it is a violation of the EU Privacy Directive. Accordingly, this TF must first take on clear proposals for revisions of the procedures by which registrars, thick registries, and resellers handle instructions from domain name holders to update and/or correct domain name data. These procedures must include: clear instructions to domain name holders on how to update their information; special email addresses for expedited and priority handling of such updates; and TF3-proposed revisions to the Registrars Accreditation Agreement to insure that the EU Privacy Directive rules on the ability of domain name holders to update and policy the accuracy of their own data is ensured and followed.
Appendix F - Position Statement
of the Registrar Constituency
GNSO Registrar Constituency Draft Submission
Whois Task Force 3: Whois Data Accuracy
March 24, 2003
Prepared by: Ross Wm. Rader, (ross@tucows.com)
on behalf of The GNSO Registrar Constituency
Overview
This document responds to the call for submissions from the GNSO Names Council
Whois Task Force 3: Whois Data Accuracy and the issues identified within the terms
of reference for this task force.
This task force has been specifically requested to:
- collect information on the current techniques that registrars use to verify
that the data collected is correct. For example techniques to detect typing
errors by registrants intending to provide correct information. Survey approaches
used by ccTLDs to verify that the contact data collected is correct.
- collect publicly available information on the techniques used by other online
service providers (to verify that data collected is correct) as well as information
on the price of services offered by the online service provider.
- create a best practices document for improving data verification based on
the information collected that can be applied on a global basis
- determine whether any changes are required in the contracts to specify what
data verification is necessary at time of collection to improve accuracy
- determine what verification mechanisms can be used cost effectively to combat
the deliberate provision of false information, and determine whether additional
mechanisms are necessary to provide traceability of registrants, or provide
for more timely responses for misuse of domain names associated with deliberately
false information.
Response
The issue of a useful and sustainable model for appropriate access to registrant
data via publicly accessible means continues to be a primary concern for the ICANN
GNSO Registrar Constituency. Registrar Constituency membership are the primary
caretakers of Whois access and Whois data in the gTLD namespace and have a vested
interest in ensuring that it is responsibly administered within the bounds of
appropriate public policy as established by ICANN.
The Registrar Constituency started formulating its position on Whois during its
formative year in 1999 with a request to the ICANN Board of Directors to ensure
that the public Whois service located at http://rs.internic.net remained accessible
to all members of the public and did not become a specialized marketing vehicle
for specific corporate interests. The Constituency position continues to grow
in conjunction with its examination and discussion of the issues with the DNSO/GNSO
and larger internet community.
This dialogue will continue to be important as long the internet community requires
access to registrant data via publicly accessible means. The Constituency views
this dialogue as an imperative component in its ongoing decisions of how to best
operate this important resource in a manner that balances the interests of stakeholders
in accordance with established ICANN policy. In this regard, the primary interest
of Registrars is that of commercial implementer, operator and caretaker.
Balancing the interests of those who require access to accurate data and those
obligated to maintain accurate data is neither an easy nor a forgiving task. On
one hand, we have to satisfy those actors who legitimately require immediate access
to accurate registrant data to protect the rights or assets of public and private
interests from infringement or misappropriation by third parties. On the other,
Registrars must be concerned with the contractual rights and obligations of those
parties responsible for maintaining the accuracy of the registrant data and also
those of the registrants.
The current body of policy allows Registrars to uphold their obligations in a
responsible manner that does not impinge the contractual rights or obligations
of other parties to these agreements. This capability is clouded by the lack of
available data regarding some of the more recently enacted elements of the policy,
notably the Whois Data Reminder Policy. Further, it is unclear whether or not
the appropriate measurements are being taken or what reporting mechanisms exist.
Timely measurement and reporting is a prerequisite to the ICANN community gauging
the effectiveness and scalability of the policy it enacts.
The Registrar Constituency is a broad and diverse group of commercial providers.
Registrar firms come from all parts of the world , operate in many different languages
and cater to their chosen markets with every imaginable business model. Not only
are Accredited Registrars required to abide by the terms of their contracts with
ICANN, but also by the laws that they operate under. Resolving the conflicts between
law and contracts, language, culture and differing business models is a daunting
task. The Constituency recognizes that more work is required to ensure that all
Registrars are equitably applying existing policy while ensuring that the competitive
diversity of its Membership is fostered and promoted. ICANN's ongoing program
of compliance and education is one such example of positive efforts in this direction.
These programs are a necessary element of ICANN's function and its efforts should
receive the full support of the community.
To these ends, the Registrar Constituency makes the following submissions to the
ICANN GNSO Names Council Whois Task #3, Whois Data Accuracy.
Submission
- The Constituency recommends that ICANN continues to develop its ongoing
compliance plan to ensure that contracted parties are appropriately meeting
their obligations under the various agreements.
Specific attention must be paid to;
- the resources assigned to managing this plan;
- the specific elements of compliance that the internet community is primarily concerned with;
- development and implementation of a graduated scale of sanctions that can be applied against those who are not in compliance with their obligations or otherwise infringing the contracted rights under these agreements;
- Measurement and reporting mechanisms that allow appropriate analysis
of the effectiveness of this ongoing program with specific attention paid
initially to existing compliance assistance mechanisms such as ICANN's
online Whois data inaccuracy reporting tools;
- Continued outreach to and education of affected stakeholders to ensure that existing requirements and obligations are understood and met and that new requirements are captured and appropriately dealt with. This effort should ensure that ICANN advisories related to this issue are specifically brought to the attention of newly accredited Registrars and that resources be made available to the Registrar community to ensure that the impact and scope of these obligations are apparent and understood. Similar resources should be made available to new Registrants and brought to their attention via the registration agreement that all Registrants must agree to prior to the activation of their gTLD registration;
- Ongoing development and promotion of gTLD Registry, Registrar and Registrant best practices that foster the accuracy of the Registrant data contained in the Whois database
- The Constituency further recommends that ICANN does not ratify any policy related to Whois data accuracy that alters the balance of rights and obligations found in current policy.
- Finally, the Constituency recommends that a specific examination of Registrar data collection and protection practices be undertaken by the GNSO Council (or another appropriate body) in order that the GNSO community has sufficient and appropriate appreciation of the policy implications of the various data protection regulations in effect in the various jurisdictions that Registrars operate.
Appendix G - Position Statement
of the Registry Constituency
GTLD CONSTITUENCY POSITION FOR TF 3
Below is the Registry Constituency response to the call for submissions from the
GNSO Names Council Whois Task Force 3: Whois Data Accuracy and the issues identified
within the terms of reference for this task force.
This task force has been specifically requested to:
- Collect information on the current techniques that registrars use to verify
that the data collected is correct. For example techniques to detect typing
errors by registrants intending to provide correct information. Survey approaches
used by ccTLDs to verify that the contact data collected is correct.
- Collect publicly available information on the techniques used by other online
service providers (to verify that data collected is correct) as well as information
on the price of services offered by the online service provider.
- Create a best practices document for improving data verification based on
the information collected that can be applied on a global basis
- Determine whether any changes are required in the contracts to specify what
data verification is necessary at time of collection to improve accuracy
- Determine what verification mechanisms can be used cost effectively to combat
the deliberate provision of false information, and determine whether additional
mechanisms are necessary to provide traceability of registrants, or provide
for more timely responses for misuse of domain names associated with deliberately
false information.
The gTLD Registry Constituency arrived at the positions described in this statement
primarily through email discussions occurring from February through April 2004
supplemented to a small degree by discussions occurring as part of agendas for
the in-person constituency meeting in Rome on 2 March 2004 and regular constituency
teleconference meetings during March and April 2004. All constituency registry
members were included in email discussions on the constituency list.
Financial Impact
Financial impact to registries of changes to Whois requirements would vary depending
on what the nature of the changes are, what implementation time frames are required,
etc. Until specific requirements are defined, it is not possible to quantify financial
impact.
Implementation Timeframe Estimates
Because so many applications rely on Whois information, advance notice
must be provided to the community at large to allow sufficient time for such applications
to be modified to accommodate changes. Because of the widespread global use of
Whois information, it is not unreasonable to expect that at least six months notice
should be given to the Internet community for any significant changes.
Constituency Comments
We recommend that, with respect to Registrant contact data, any verification mechanisms
which may be implemented in the future should be implemented at the registrar
level. This enhances effective communication with the registrant and allows for
a more efficient methodology for correction of any inaccurate information by the
registrant.
Implementation of any data verification schemes should to be done on a “global
basis” and not be applied to any gTLD on a country-by-country basis.
We concur with previous recommendations that an in-depth examination of Registrar
data collection and protection practices be undertaken by the GNSO Council (or
another appropriate body) in order that the GNSO community can accurately discern
policy implications of the various data protection regulations in effect in various
registrant jurisdictions.
We recognize that until the concerns of privacy are adequately dealt with on a
regional and international basis, it will be very difficult to resolve the Whois
data accuracy problem. In this regard, the gTLD Registry Constituency strongly
recommends that this fact be recognized and that a concerted effort be made to
address it. Until that is done, regardless of what mechanisms are put in place
to improve accuracy, individuals concerned about privacy and registrars and registries
operating in jurisdictions with strict privacy regulations will find ways to protect
privacy, which may work against steps to improve accuracy.
One way to implement, from a technical perspective, the policy objectives of achieving
accurate WHOIS information, while at the same time balancing the appropriate privacy
interests, may be through the nearly completed IRIS protocol being developed by
the CRISP working group. Once finalized, we recommend that ICANN comprehensively
evaluate such protocol.
Summary
of Task Force 3 Public Comments