Interim Report of the Names Council's WHOIS Task Force
October 14, 2002

Click here to submit a comment on this issue paper.
Comments must be received by 8 November 2002.

Table of Contents

  1. Executive Summary
  2. Terms of Reference
  3. Draft Conclusions
  4. Impact Analysis
  5. Constituency Impact Reviews
  6. Record of Outreach
  7. Minority Reports
  8. Supporting Arguments
  9. Risk/Cost Analysis
  10. Publication and Comment Period
  11. Final Conclusions/Recommendations
  12. Appendix I/Links

I. Executive Summary

The WHOIS Task Force presents its Interim Report on WHOIS, which includes recommendations regarding whether ICANN should seek to modify the WHOIS policy for comment to the DNSO Constituencies, the General Assembly, and the public at large.  The Interim Report is primarily focused on recommendations which were identified in our Final Report on the Survey, presented at the ICANN meeting, Bucharest, June 24-28,2002. The recommendations also ask several questions to the community regarding further kinds of work in WHOIS that the Task Force believes should be examined further.

 The Interim Report addresses the four key areas, which were identified in the survey:

·        Accuracy of the data contained in the WHOIS database

·        Uniformity of formats and elements across various TLDs and registrars, including ccTLDs

·        Better searchability

·        Better protection of data subjects from marketing use of the data contained in the WHOIS database

 

As noted above, the Interim Report identifies some specific policy recommendations as well as outlining ideas for undertaking further work on the WHOIS issues.  The final report will also include previous documents, which are available on the Task Force archive, including the survey instrument, the responses, a previous final report, which provides an analysis of the responses to the survey, and other outreach documentation, which has taken place under the direction of the Task Force.

A total of 3,035 survey responses were received. After extensive analysis to develop the Final Report on the Survey, the Task Force then developed further work in small groups; each of the working groups of the Task Force developed detailed DRAFT recommendations. Items one and four: Accuracy and Protection of data subjects respectively both have concrete suggestions for action in the near term by ICANN, as well as suggesting longer term work activities. Although the findings are very clear related to marketing uses of WHOIS data, and therefore the Task Force was able to make some recommendations, the Task Force also agrees that there are several questions, which have not yet been fully examined regarding access to WHOIS data.

 Items 2 and 3: Uniformity of elements and Better search ability both call for both mid term and longer term work items. Uniformity of formats and elements are reliant upon developments in the standards areas, as well as adoption by geld registrars and registries, and separately, development of an agreed to approach to address similar needs in colds, taking into account national law and local stakeholder perspectives.  In particular, Item 3, better searchability, notes the significant value of emerging standards.  Consideration will be needed to the pros and cons of increased searchability.

All of the suggestions for improvements will require some change in either practice or policy. Some changes affect registrars; other changes affect both registrars and registries, and some recommended changes will require participation by the ccTLD community.  In all cases, the Task Force expects the broad community to benefit from recommended changes.  The recommendations of the Task Force prioritize the importance of WHOIS in the gTLDs, however, the Task Force believes that there is merit for users, and we hope mutual benefit to the ccTLDs to participate in a process to agree to both uniformity and consistency of data elements, and to participate in development and adoption of industry standards, as they become available.

 

Background:

The Task Force was tasked by the ICANN Domain Name Supporting Organization (DNSO) Names Council to give advice on WHOIS Policy. The Task Force followed the work of a Names Council WHOIS Committee convened by ICANN staff to give advice on implementation of WHOIS for the .com/.net/.org domains as required under the Registrar agreement. This Committee addressed implementing questions related to WHOIS in these domains and concluded its work in April, 2001.  The implementation of the committee’s work included the establishment of a WHOIS Task Force on domain name system policy.  The Task Force was approved in the Names Council meeting of February 8, 2001.

 

In general, the purpose of the Task Force’s work is to consult with the community with regard to establishing whether a review of any questions related to ICANN’s WHOIS policy is due and is to recommend a mechanism for such a review. As the Task Force has worked, they have chosen to interpret their mandate broadly, and have shared that perspective with the Names Council on several occasions, as well as publishing this interpretation in the various public presentations that they have made.

The Task Force has undertaken significant efforts to develop mechanisms to seek consultation with the broad community, which have included conducting a survey; analyzing and publishing and presenting the findings of the survey; presenting preliminary recommendations for public comment and at ICANN meetings for discussion by the Names Council and the community, and finally, undertaking further dialogue with interested parties to take additional comments on the draft recommendations which the Task Force has developed.  T he Final Report of the Survey is recommended to all as a resource document.

 

II             Terms of Reference:

 

Link to TOR:

 

            From the beginning, to support their broad mission, the Task Force members have been committed to gaining an understanding of how WHOIS is used, how it affects both those who provide WHOIS services and its users, what concerns exists, as well as taking a forward look at how uses of WHOIS may be changing with the growth and extension of the Internet and issues which might need further examination and analysis.

 

Participation and Outreach:

            The WHOIS Task Force has had the benefit of broad, diverse, and strong participation of all constituencies and the General Assembly. At its creation, it was chaired by Paul Kane, Registrar Constituency; and had one representative from each of the seven constituencies and the General Assembly.  When Mr. Kane’s term on the Names Council ended, co-chairs were elected by the Names Council Task Force: Antonio Harris, ISPC Constituency and Marilyn Cade, Business Constituency. The Task Force was also then expanded and each constituency and the General Assembly added additional participants to the Task Force. The details of Task Force membership are provided in the Appendix.

 

The Task Force completed a web-based survey, which, while not statistically valid, provided a snapshot of the uses, issues, concerns, and perspectives of those who chose to respond. The survey was published in June, 2001, with one extension in time for responses. The survey closed in August, 2001, with 3035 responses received. The survey and an analysis of the survey’s responses  [IN APPENDIX] and an interim version of the findings were presented in Ghana, March, 2002, and the findings discussed in the Names Council. The presentation and the draft report were published for further comment on the initial findings.  All comments were taken into account, and a Draft Final Report of the Survey’s Findings was presented at Bucharest, June 24-28, and its findings discussed both in the General Assembly, and in the Names Council.  The Task Force announced that its intent was to undertake further examination of the initial final findings based on the survey and other inputs, and has spent the past four months undertaking discussions, and dialogue to undertake recommendations to support some policy changes, as well as recommendations for further work in the WHOIS area.   The Task  Force has recently also undertaken selective consultation by hosting open calls with a small group of interested individuals who have chosen to respond to an open conference call consultation. Those consultations were informational to the Task Force and are documented in Transcripts, which will also be linked to the Final Report, and are presently available on the Task Force archive.

 

PROCESS FOR COMMENT FROM THE COMMUNITY ON THE INTERIM FINAL REPORT:

Each stage of the Task Force’s work has included publication and presentations.  Comments have been received and taken into account as the next stage of work of the Task Force was developed.  Following the last round of publication for comment, a number of additional comments were received, and these are provided in a later section.

This document’s recommendations are now open for further comment for a time frame of approximately three weeks; this will continue through the Shanghai meeting in order to enable those traveling to the Shanghai meeting sufficient time to provide comments. 

Comments are sought through distribution to the |DNSO constituencies, the General Assembly, and by providing a web based comment forum through the ICANN web site, as well as an open session during the General Assembly in Shanghai. The recommendations will also be discussed at the Names Council meeting in Shanghai, based on a presentation, which will include Policy Recommendations and Possible further recommendations. 

The Task Force will take into account for its Shanghai discussions any comments received by October 22, 2002, and will then, upon completion of the ICANN meeting, take into account feedback from the public at the Shanghai meeting, from the Names Council, and on the web site, in order to finalize their recommendations to the Names Council.  The final report, with a resolution for voting will then be presented to the Names Council at the closing of the final report and forwarding of the final report in early December, 2002, for a decision and approval of recommendations and forwarding to the Board.

The Task Force expects to recommend some policy changes and to recommend some further work, with a recommendation to the Names Council on various approaches to undertake any further work that they approve.


 

III.              Draft Conclusions

This section begins with an excerpt from the Final Report on the Survey, Bucharest, and June 2002, which is provided merely for the reader’s convenience. This section is merely a reproduction of key elements from VIII: Request for Discussion: Possible WHOIS Recommendations.  (Non-related comments related to how to comment on that document are removed)

 

“VIII. Possible WHOIS Recommendations from Final Report on the Survey.

The present report identifies four areas for policy consideration:

 

1.      Accuracy of the data contained in the WHOIS database.

2.      Uniformity of data formats and elements across various TLDs and registrars, including ccTLDs.

3.      Better searchability.

4.      Better protection of data subjects from marketing use of the data contained in the WHOIS database.

 

A generally high level of satisfaction was found with respect to current data elements and non-marketing uses of WHOIS in the gTLD environment. These results reflect the existing community consensus, and we have not detected any changes in this consensus.  However, the evolution of the community’s consensus with respect to the WHOIS database must be closely monitored, in particular with regard to the impact of the rollout of new gTLDs (not present at the time the survey was conducted) and evolving national law.

 

This chapter tries to explore possible approaches to address the issues identified as concerns, and to identify the interests affected by them. 

 

The Task Force solicits your comments on these possible recommendations. 

 

·         Accuracy of data contained in the WHOIS database

 

The current Registrar Accreditation Agreement[1] (RAA), section 3.7.7.1, requires registered name holders to provide to their registrars "accurate and reliable contact details."  According to 3.7.2, the "willful provision of inaccurate or unreliable information" or the failure to respond to inquiries on the accuracy in a timely manner  "shall constitute a material breach of the [...] contract and be a basis for cancellation of the Registered Name registration."  ICANN has recently called registrars’ attention to these provisions, by issuing an advisory[2] concerning WHOIS data accuracy.

The Task Force believes that the approach of actually enforcing the existing contractual provisions is the essential first step toward improving  WHOIS data accuracy in the gTLD environment. .

The WHOIS Task Force is aware that although existing contracts allow for enforcement of applicable contractual provisions, in many cases, the only allowed penalty for a breach of the contract is revocation of the ability to register names by the registrar. This all-or-nothing system may actually impede enforcement.  In addition, registrars have not established  clear enforcement mechanisms to ensure their customers (resellers, ISPs or end-users) provide accurate data.

The Task Force believes that a method of graduated sanctions or enforcements against parties who breach the requirement to provide accurate information and to maintain an accurate WHOIS database,  potentially as a combination of policy and financial penalties, should be considered, in order to facilitate the actual enforcement of the current policy with respect to WHOIS data accuracy.

 

If enforcement of current contractual provisions  does not lead to an improvement of WHOIS data accuracy, then more substantial changes to the RAA itself or the establishment of consensus policies (as necessary) should be considered. 

For example, mandatory periodic re-validation of WHOIS data has been identified as one important technique for improving data quality, which may require a change in ICANN policy, to the extent that registrars do not voluntarily adopt it.

·        Uniformity of data formats and elements across various TLDs and registrars, including ccTLDs.

 

 Currently, whois data elements are, in general, uniform across gTLDs. They are not uniform across country-code top-level domains, some of which do not even provide a WHOIS or equivalent service.  There is currently no uniform format for the responses provided by WHOIS services.

The Task Force believes that the questions of uniform data formats and uniformity of data elements need to be discussed and handled separately. 

 

As far as data formats are concerned, an open technical standardization process building on the work of ICANN’s earlier .com/.net/.org WHOIS Committee[3] and the ietf-whois mailing list[4] should be undertaken. The committee recommended in early 2001 that a standard WHOIS format should be phased in as expeditiously as possible that does not rely on TCP port 43, such as the XML-based format, which is described in detail in the Internet draft ‘WHOIS Export and Exchange Format’ of January 26, 2001.

The present Task Force believes that the use of such a uniform data format across gTLD and ccTLD environments should be evaluated. 

The survey data evaluated by the Task Force seem to indicate that there is considerable support for such uniformity among the respondents to the questionnaire.[5]

 

The Task Force believes that WHOIS data elements should be uniform across all gTLDs.

 

Uniformity of data elements across gTLDs and ccTLDs, while found desirable by an extremely strong majority of respondents to the Task Force’s survey[6], can be expected to lead to conflicting views caused by national or regional cultural and legal differences with respect to a number of issues, including registrants’ privacy rights, and divergent views regarding the relationship of ccTLDs to ICANN consensus policies.  

The Task Force believes that this topic should be the subject of separate deliberations.  These deliberations should take into account specific aspects of  the TLD environments, as well as the value of  accountability and transparency across the domain name system.    Public interest concerns should be taken into account in an appropriate manner. The  objective should be to identify the best way to make progress toward the goal of the uniformity that all  users of the system clearly desire. 

 

·        Better searchability of WHOIS databases. 

 

The Task Force’s Survey covered three kinds of improved searchability of WHOIS databases:  (1) Centralized public access to WHOIS databases on a per-TLD level[7], (2) the use of data elements different from the domain name as query keys[8], and (3) the provision of still more advanced database query capabilities, and centralized search services across TLDs.[9] The Task Force’s Survey. indicates that, among respondents, there is demand and support for each of these services. The first two of these aspects (centralized access on a per-TLD basis, and the use of other data elements as search keys) mostly amount to a restoration of the InterNIC WHOIS status quo ante[10], and may be considered part of the current policy environment[11],  but they are not being enforced.

 

The more advanced services described under (3) do presently not exist in the .com/.net/.org environment.  However, centralized access to one or more cross-TLD WHOIS services is specifically provided for in the existing gTLD registry agreements.[12]  One registry also has taken on an obligation to conduct research and development activities toward a universal WHOIS service.[13]   Furthermore, enhanced searchability is to be offered by at least some of the new gTLD registries in accordance with their accreditation agreements.[14]  

 

As far as the gTLD environment is concerned, all these services can be implemented either by registrars/registries or as third party services, based on Bulk Access to WHOIS data.[15] The survey revealed that many of those who demand such services believe that the services should be free for users, and should be paid for as part of registration fees. 

To facilitate the restoration of full searchability of WHOIS databases [see (1) and (2) above], ICANN should explore both enforcing the mandate to registrars and registries to provide (or to cooperate in the provision of) such complete WHOIS search service, and a market-based approach based on bulk access to WHOIS data.

With respect to the more advanced services described in (3) above, the Task Force does not recommend any policy changes. The Task Force suggests that ICANN explore how best to swiftly develop and implement a plan for cross-registry WHOIS services, including through third party services, based on bulk access to WHOIS data.

·        Marketing use of WHOIS data; bulk access provisions.

 

The survey undertaken by the Task Force strongly suggests[16] that respondents generally do not accept the use of their personal information contained in the WHOIS database for unsolicited marketing activities. Respondents also generally preferred opt-in approaches to such marketing use over opt-out approaches (like the one envisioned by section 3.3.6.6 of the current RAA).

Based on these results, the Task Force recommends a review of the current bulk access provisions of the Registrar Accreditation Agreement.

 

Such review should explore the option to reduce registrars’ discretion in the design of their respective bulk access agreements, in favor of stronger privacy protection for registrants,  stronger restrictions on marketing use of WHOIS data, and facilitation of bulk access for value-added non-marketing services, as originally contemplated in the RAA.    In particular, the following possible changes  should be examined more closely:

·        The policy could attempt to ensure that protection mechanisms can’t be circumvented by third parties selling indirect access to bulk data.  This could, for instance, be accomplished by changing “may require” in section 3.3.6.5 to “shall require.”  It could also be accomplished by requiring bulk access  users to impose conditions on the use of their products and services, which are similar to the ones in ICANN’s policy.

·        Sections 3.3.6.3 (prohibition of use of bulk access data for marketing purposes) and 3.3.6.6 (opt-out provision) could be simplified,  unified, and extended to include contact data of organizational entities. Marketing use of registrants’ data outside existing business relationships could depend on the registrant’s prior agreement (“opt-in”).

 

 

Interim Recommendations

In order to further develop the work of the Task Force, four small working groups were formed, and chaired by members of the Task Force. The chairs, and membership of each Working Group are included in an appendix {to be provided in final report}. 

 

After drafting recommendations, these were shared with the other Task Force members, and were the subject of discussion among Task Force members and some preliminary outreach to concerned and interested parties who were invited to provide initial input.   This outreach is included in the Outreach section {to be further documented in Final Report and through the inclusion of the minutes and transcripts}. 

 

These Interim Recommendations are provided below for comment by the community.  Please follow the format provided in the document by providing your comments as much as possible by noting the heading or number of the section. This will help the Task Force in its review of comments.  Some explanatory comments from the Task Force are also provided and are in CAPITAL LETTERS

 

Interim 1.0 :  Accuracy of WHOIS Data commendations

 

The Task Force recommends

  1. Enforcement of existing contractual obligations (in the Registrar Accreditation Agreement and in the ICANN agreements with the new gTLD registries) regarding accuracy of WHOIS data

 

THE TASK FORCE DOES NOT BELIEVE THE FOLLOWING WILL INCUR SIGNIFICANT ADDITIONAL COSTS, AND ARE IN FACT REQURIED BY EXISTING CONTRACTS AND ACCREDITATION AGREEMENTS.  

 

In the following, references to registrars also include the "thick" gTLD registries, unless otherwise indicated.

 

1)      ICANN should ask registrars to identify, by a date certain, a reliable contact point for reports of false WHOIS data and for requests for registration cancellations [OR TEMPORARY SUSPENSION] based thereon.

2)      ICANN should post those contact points on its web site (perhaps on the list of accredited registrars)

 

3)      ICANN should add an [optional/STANDARIZED] complaint form on this issue to the internic.net site.   In order to better ensure follow up, the complaint form [would/could] supply a "ticket number" for the complaint and [would/could] be designed for ICANN to be copied on the registrars' response to the complaint.    

SOME OF THE TASK FORCE MEMBERS BELIEVE THAT SOME OTHER AREAS WHICH CAN IMPROVE DATA ACCURACY MAY ALSO HAVE ADDITIONAL COSTS ASSOCIATED WITH THEM, BUT SHOULD BE EXAMINED FOR IMPACT AND FEASIBILITY OF IMPROVING THE ACCURACY OF DATA.  SOME OF THESE ARE PRESENTED FOR COMMENT AND FEEDBACK. 

 

(4)  ICANN should supplement its May 10, 2002 registrar advisory as follows:

(a)        ICANN should instruct registrars to use commonly available
automated mechanisms to screen out obviously incorrect contact data (e.g., ZIP code/postcode matching software [at least for North American registrants], rejecting incomplete fields in contact data, etc.).

 


(b)        ICANN should remind registrars that "willful provision of
inaccurate or unreliable information" is a material breach of the
registration agreement that should lead to cancellation of the registration unless there are extenuating circumstances, and that this breach can be detected on the face of the data submitted if it is blatantly false. (It is extremely unlikely that someone would submit such contact data other than willfully.) 

 

 

 In these circumstances there is no need to attempt to contact
the registrant before cancellation, and no need to wait 15 days.  Once this willful conduct is brought to the attention of registrars, the registration should be subject to cancellation. 

 

 

(c)                ICANN should clearly state that "accepting unverified
'corrected' data from a registrant that has already deliberately provided incorrect data IS NOT [not "may not be," as the advisory states]
appropriate."  Accordingly, registrars should require that registrants not
only respond 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 can be treated as a failure to
respond and thus grounds for cancellation of the domain name registration.

 


(d)        ICANN should tell registrars to treat a complaint about false
WHOIS data as to one registration as a complaint about false WHOIS data as
to all registrations that contain identical contact data, and all such
registrations should be made the subject of an inquiry, corrected, or
cancelled, as the case may be, en bloc.

 

 

(e)        Registrations to be cancelled on the basis of submission of false contact data should be subject to a Redemption Grace Period similar to that being implemented for other deletes in .com/.net/.org, but requiring submission of verified contact data for redemption.   

 

 

ADDITIONAL QUESTIONS ON WHICH COMMENT IS SOUGHT:

 

1.      Will implementation of the proposed steps listed above be likely to improve the accuracy of WHOIS data?

2.       What additional or alternative steps within the framework of the current agreements should be considered?  

3.      Under 2 above, should Registrars and affected Registries also be [required/asked] to post such contact information in a visible location on their web site and keep it current?

4.      What kind of communications with registrants regarding accuracy requirements would be most effective: notice in registration agreement, period email reminder to update contact information, or other means?

5.      What other suggestions do you have?

 

 

(B)    Regarding the possibility of graduated sanctions for violations of existing contractual agreements, the Task Force recommends the following:

 

(1) In renegotiation of the RAA, ICANN should consider a series of graduated sanctions whose aim is to improve the compliance of registrars to the terms of the RAA with regard to the accuracy of WHOIS data.

 

(2) In addition, it should be re-emphasized that registrars are responsible for the compliance of their agents  (i.e. Resellers, and other intermediaries) with WHOIS accuracy directives.

 

(3) ICANN should modify the contracts of Registry and Registrar operators who are under contractual obligation with ICANN in the following manner:

 

(4) Graduated Sanctions – “3 Strikes Policy”

 

(a) Definitions:

For the sake of uniformity, the word “Registrars” below shall include ICANN authorized registrars, as well as any intermediaries and agents of such registrars who engage in the sales and service of Internet domain names through such ICANN authorized registrars, directly or indirectly.  “Documented inaccuracies in WHOIS data” does not refer to individual cases, which are the subject of complaints, but to recurring patterns or practices of non-compliance identified by ICANN. 

 

(b) Who do the sanctions apply to:

The “3 Strikes Policy” shall apply to Registrars, as defined above, and thick registries.

 

( c) What are the sanctions:

 

(c-1.) Strike One:

The Registrar shall be provided thirty calendar days to take necessary action to correct documented inaccuracies in WHOIS data.  If, at the expiration of the thirty-day period, the information in the WHOIS database has not been corrected, and the Registrar does not submit to ICANN evidence of having taken vigorous steps to correct such inaccuracies, the Registrar shall be:

a)      Provided a notice of non-compliance with ICANN contract regarding WHOIS accuracy

b)      Levied a fine of $250 for each instance of non-compliance.  The fine would be collected from funds deposited by registrars with registries (ICANN agreements with registries would also have to be revised to authorize this collection).  (A collection mechanism would also need to be provided with respect to thick registries.) 

c)      Asked to provide a plan to ensure correction of accuracy of the WHOIS data

d)      Given a further thirty days to take action to correct documented inaccuracies in WHOIS data, with penalties for non-compliance as below

 

(c-2) Strike Two:

The Registrar shall be provided a further thirty calendar days to take necessary action to correct documented inaccuracies in WHOIS data.  This time period shall commence at the conclusion of the first thirty-day period automatically.  If, at the expiration of the thirty-day period, the information in the WHOIS database has not been corrected, and the Registrar does not submit to ICANN evidence of having taken vigorous steps to correct such inaccuracies, the Registrar shall be:

a)      Provided a second notice of non-compliance with ICANN contract regarding WHOIS accuracy

b)      Levied a fine of $500 for each instance of non-compliance. 

c)      Asked to provide a plan to ensure correction of accuracy of the WHOIS data

d)      Informed that they have one more opportunity to take steps to correct WHOIS data before more serious action is taken against them for material breach of contract

e)      Given a final thirty days to take action to correct documented inaccuracies in WHOIS data, with penalties for non-compliance as below

 

(c-3) Strike Three:

The Registrar shall be provided a further thirty calendar days to take necessary action to correct documented inaccuracies in WHOIS data.  This time period shall commence at the conclusion of the first thirty-day period automatically.  If, at the expiration of the thirty-day period, the information in the WHOIS database has not been corrected, and the Registrar does not submit to ICANN evidence of having taken vigorous steps to correct such inaccuracies, the Registrar shall be:

a)      Provided a third notice of non-compliance with ICANN contract regarding WHOIS accuracy

b)      Levied a fine of $1,000 for each instance of non-compliance.

c)      The Registrar’s name shall be placed on a public non-compliance list, prominently displayed on ICANN and other public Internet sites.

d)      Asked to provide a plan to ensure correction of accuracy of the WHOIS data

e)      Informed that under the terms of their RAA, they are in danger of incurring further serious penalties, including, should it be so decided, a suspension of Registrar accreditation.

f)        Given a final thirty days to take action to correct documented inaccuracies in WHOIS data, with penalties for non-compliance as below

 

(c-4) Next Step:

Suspension of accreditation and rights to register new names for 5 days.

 

 

(c-5) Final Step:

Removal of accreditation.

 

 

(d.) How are the sanctions imposed:

Upon discovery of inaccurate WHOIS information in the authoritative database (the Registrar’s database in the case of thin-registries, and the Registry’s database in the case of thick-registries), the discovering party shall be provided a mechanism to submit a complaint.  Such a complaint shall receive a tracking number to ensure accountability.  [NOTE:  this refers to individual instances, not documented problems that could give rise to the sanctions steps above.  The ICANN September 3, 2002 announcement appears to provide a mechanism similar to this.] 

 

(e.) When do the sanctions apply:

[see above]

 

(f.) What is the relief from sanctions:

Correction of data [or cancellation of DN registration].

Documented steps to correct data and proof of action and reasons (if any) for delay.

 

            QUESTIONS ON WHICH COMMENT IS SOUGHT:

 

1.      Is there a need for graduated sanctions to improve enforcement of the existing contractual obligations regarding WHOIS data accuracy?

2.      If so, is the system outlined above appropriate? 

3.      What quantity of complaints should be received before sanctions are applied?

4.      If a registrar has reoccurring documented complaints that they fail to respond to when notified by ICANN staff, should there be a shorter time period before c-4 and c-5 are undertaken?

 

 

(C)   The Task Force recommends that ICANN consider the following

additional steps in renegotiation of the RAA:

 

1)      Registrants should be required to review and validate all WHOIS data upon renewal of a registration. 

 

2)      Registrars should be required to spot-check a sample of registrations in order to validate the accuracy of contact information submitted. 

 

3)      Besides the use of automated methods to screen out obviously false contact data (see item 4(a) under section (A) above), semi-automated methods such as e-mail pinging, automated dialing to validate telephone numbers, etc., may be used to the greatest extent feasible.

 

            QUESTIONS ON WHICH COMMENT IS SOUGHT:

 

1.      How effective will these new requirements be in improving the accuracy of WHOIS data?

2.      What costs will they cause registrars/registries to incur, and how will this affect the cost of domain name registration and competition in this market?  What other changes to the existing agreements ought to be considered?        

INTERIM 2.0:   Uniformity and Consistency Recommendations

 

            The Task Force survey results strongly indicate that uniformity of data elements and formats across as many TLDs as possible would be in the best interests of Internet users.  The Task Force agrees. 

 

To the extent possible, a WHOIS query regarding a registration in any TLD should return the same data elements, presented in the same format. However, for practical reasons, it is worth considering the situation of gTLDs and ccTLDs separately.

 

            In the gTLD environment, registrars and registries are already required by contracts with ICANN to provide similar (although not identical) data elements across gTLDs.  However, this does not always occur in practice. 

 

The Task Force Recommends:

 

(A)   Efforts should be undertaken to ensure that to the extent possible, WHOIS queries regarding registration in gTLDs should return the same data elements.

(B)   Discussions should be developed with the ccTLD community to establish how best to move toward a standards based approach for data elements and formats.

(C)   The Task Force recommends that ICANN should take action against gTLD registrars that omit WHOIS data elements or present WHOIS data in irregular formats. 

 

COMMENT FROM THE TASK FORCE: There are existing obligations within the gTLD community that should receive  more vigorous enforcement –thus helping to resolve the problems.

 

The Task Force believes that it is possible that uniformity/consistency problems are less serious in gTLD registries using a “thick registry” model.

 

(D)   ICANN could encourage registries not now using this model to migrate toward it. OR

(E)    Further work could be undertaken to agree on a standard set of data elements, which are then agreed to in the accreditation agreement, or via some other agreed to mechanism.

 

 

In consideration of a separate working effort to involve ccTLDs, a few registries have signed agreements with ICANN obligating themselves to carry out future ICANN-adopted policies regarding WHOIS.[17]   The Task Force believes that some large ccTLD registries that have not yet entered into contractual agreements have indicated a willingness to participate in a “voluntary program” with ICANN regarding WHOIS.[18]  ICANN should consider instituting such a program, using as an initial model the WHOIS provisions of the WIPO ccTLD Best Practices.[19]           

 

 

(F) As ICANN continues to work with the ccTLD community, ICANN has several options to address uniformity and consistency of data elements in the ccTLDS, taking into account that there is great diversity of the number of registrations of various ccTLDs, and differing national laws:

 

1)      ICANN should continue to encourage ccTLDs to enter into such agreements and should take the steps necessary to incorporate WHOIS policies into the obligations assumed by ccTLDs upon entry into such agreements.  OR

 

2)      ICANN could establish a cross-ccTLD working effort to identify barriers to uniformity, and ask the ccTLDs to undertake recommending policies regarding WHOIS which are consistent with uniformity and consistency, taking into account applicable mandatory provisions of local privacy/other applicable law.  

 

3)      Since it may take some time for all ccTLDs to enter into contractual agreements with ICANN, ICANN could develop, based on ccTLD advice and involvement, a separate “code of conduct” voluntary approach for certain policies, such as WHOIS.

 

 

 

(G) The possible role of emerging standards as a forthcoming solution:

 

The Task Force also draws attention to the IETF (Internet Engineering Task Force) Working Group on a proposed new protocol underlying the WHOIS service, called CRISP (Cross Registry Information Service Protocol).  The charter[20] of this Working Group is to define a standard mechanism that can be used for finding authoritative information associated with a label, a protocol to transport queries and responses for accessing that information, and a first profile (schema & queries) to support commonly-required queries for domain registration information. 

 

One limitation, which should be noted, however, is that this proposed new protocol does not concern itself with backwards compatibility with the current WHOIS protocol.  This IETF group already has participation from several gTLD registrar and registry representatives. Participation in the CRISP Working Group is open and free as is usual with IETF working groups.

 

(1)   The Task Force recommends appropriate and interested parties, such as Task Force members, ccTLD representatives, and others may wish to join[21] this group, or at a minimum, follow its work.  [Policy implications of such standards need to be considered before deployment.]

(2)   The Task Force also recommends that a more thorough examination of the role of standards both for WHOIS, and for other approaches to directory services [which WHOIS is now sometimes substituted for] could become a topic of a future ICANN Public Forum to better educate the broad ICANN community.

 

 

 

INTERIM 3.  Searchability of WHOIS Databases

 

The Task-Force Survey examined three kinds of improved searchability:

 

(A) Centralized public access to WHOIS databases across each gTLD

 

(B) The use of data elements different from the domain name as query keys, and,

 

(C) The provision of still more advanced database query capabilities and centralized search services across Top Level Domains, including Country Code TLDs.

 

Our Survey indicates that, among respondents, there is demand and support for all of these services.  In addition, the Task Force identified from the survey respondents, some expressions of concern about privacy issues related to WHOIS searchabilty.  The Working Group based its work in further development of recommendations upon these elements.

 

A.     Centralized Public Access:

 

The existing gTLD registry agreements provide for access to each registrar’s database via a so-called WHOIS service and specifically contemplate the possibility of a distributed cross-registrar WHOIS service.

 

The relevant provisions of the agreement are as follows:

 

“  II. TERMS AND CONDITIONS OF AGREEMENT

F. Public Access to Data on SLD Registrations. During the term of this Agreement:

1. At its expense, Registrar shall provide an interactive web page and a port 43 WHOIS service providing free public query-based access to up-to-date (i.e. updated at least daily) data concerning all active SLD registrations sponsored by Registrar in the registry for the .com, .net, and .org TLDs. The data accessible shall consist of elements that are designated from time to time according to an ICANN-adopted policy. Until ICANN otherwise specifies by means of an ICANN-adopted policy, this data shall consist of the following elements as contained in Registrar's database:

a. The name of the SLD being registered and the TLD for which registration is being requested;

b. The IP addresses of the primary nameserver and secondary nameserver(s) for the SLD;

c. The corresponding names of those nameservers;

d. The identity of Registrar (which may be provided through Registrar's website);

e. The original creation date of the registration;

f. The expiration date of the registration;

g. The name and postal address of the SLD holder;

h. The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the SLD; and

i.                     The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the SLD.

 

Sub 2 & 3 are not “informative” here and therefore omitted.

 

4.Registrar shall abide by any ICANN-adopted Policy that requires registrars to cooperatively implement a distributed capability that provides query-based WHOIS search functionality across all registrars. If the WHOIS service implemented by registrars does not in a reasonable time provide reasonably robust, reliable, and convenient access to accurate and up-to-date data, the Registrar shall abide by any ICANN-adopted Policy requiring Registrar, if reasonably determined by ICANN to be necessary (considering such possibilities as remedial action by specific registrars), to supply data from Registrar's database to facilitate the development of a centralized WHOIS database for the purpose of providing comprehensive Registrar WHOIS search capability.

 

5. In providing query-based public access to registration data as required by Sections II.F.1 and II.F.4, Registrar shall not impose terms and conditions on use of the data provided except as permitted by an ICANN-adopted policy. Unless and until ICANN adopts a different policy, Registrar shall permit use of data it provides in response to queries for any lawful purposes except to: (a) allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam); or (b) enable high volume, automated, electronic processes that apply to Registrar (or its systems).

 

6. In addition, Registrar shall provide third-party bulk access to the data subject to public access under Section II.F.1 under the following terms and conditions:

 

a. Registrar shall make a complete electronic copy of the data available at least one time per week for download by third parties who have entered into a bulk access agreement with Registrar.

b. Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

c. Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support the transmission of mass unsolicited, commercial advertising or solicitations via e-mail (spam).

d. Registrar's access agreement may require the third party to agree not to use the data to enable high-volume, automated, electronic processes that apply to Registrar (or its systems).

e. Registrar's access agreement may require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties.

 

f. Registrar may enable SLD holders who are individuals to elect not to have Personal Data concerning their registrations available for bulk access for marketing purposes based on Registrar's "Opt-Out" policy, and if Registrar has such a policy Registrar shall require the third party to abide by the terms of that Opt-Out policy; provided, however, that Registrar may not use such data subject to opt-out for marketing purposes in its own value-added product or service.

 

7. Registrar's obligations under Section II.F.6 shall remain in effect until the earlier of (a) replacement of this policy with a different ICANN-adopted policy governing bulk access to the data subject to public access under Section II.F.1, or (b) demonstration, to the satisfaction of the United States Department of Commerce, that no individual or entity is able to exercise market power with respect to registrations or with respect to registration data used for development of value-added products and services by third parties.

8. To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time adopt policies establishing limits on the Personal Data concerning SLD registrations that Registrar may make available to the public through a public-access service described in this Section II.F and on the manner in which Registrar may make them available. In the event ICANN adopts any such policy, Registrar shall abide by it.

 

 

 

After the initial institution of the WHOIS RFC (available at http://www.rfc.org.uk/cgi-bin/lookup.cgi?rfc=rfc0954), several plans were instituted to make whois a “better” tool.

This resulted in f.i. WHOIS++ and UWHO

 

The final (for now) rfc on WHOIS is available at http://www.rfc.org.uk/rfc/search.ietf.org/internet-drafts-back/draft-campbell-whois-00.txt

 

Additional relevant information related to WHOIS:

 

One registry has undertaken on an obligation to conduct research and development activities toward a universal WHOIS (uWho) service and is also working, with others, as part of an IETF Working Group to develop a new protocol (named CRISP).   There may be other standard projects that should be considered. In addition, the capabilities provided by searchable protocols may raise concerns with privacy and data profiling.

 

For example, the CRISP solution will enable the use of different levels of access to whois data by different types of users. For example, the Technical Contact level might permit access to information relevant to networking, while the Intellectual Property Contact level might permit access to information relevant to the needs of IP holders, and so on.

Such capabilities might lead to differentiated access, depending upon who the inquirer was. However, the process of authenticating the inquirer has other associated issues. 

 

In addition,  CRISP and other standards based solutions may take some time to develop, and to implement. For that reason, it is unlikely to be available as a short-term solution, but in the long run, may obviate many of the concerns of the Task Force Survey respondents.

 

Due to the nature of the WHOIS protocol and the express usage of port 43 current searches in the gTLDs will mostly give a “universal” result.  Even most cc-TLDs use a standardized format and address to search (port 43) for domain names: whois.nic.(cc-tld)

Output however varies greatly per TLD.

B.    Additional Query Keys

 

The first provision of Section II F. includes a mandate for registrars provision of “an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e. updated at least daily) data concerning all active SLD registrations sponsored by Registrar in the registry for the .com, .net, and .org TLDs.”  In addition this provision includes information about accessibility of many data elements[i].  We do not suggest that all elements be made into query keys.  Our recommendations for data elements for searches are provided below:

 

1. Data Elements Recommended for Searches:

 

(0) Domain Name

(1) Registrant Name

(2) Technical Contact Name or Handle

(3) Administrative Contact Name or Handle

(4) Primary Name Server or IP Address

(5) Secondary Name Server or IP Address

 

2. The result of combining centralized access on a per-TLD basis and the use of other data elements as search keys, would be a restoration of the InterNIC WHOIS status quo ante. As such it may be considered part of the current policy environment; however, provisions for this are not being enforced.

 

The Task Force recommends that these provisions be enforced.

 

Question: Should these provisions be enforced?

 

3. Enhanced searchability is currently being implemented by at least some of the new gTLD registries in accordance with their accreditation agreements (see, e.g., http://www.nic.info/whois_search/; http://www.whois.biz/).

 

The Task Force recommends an exploration of how to ensure these data elements are made available for searches across all gTLDs.  We do not suggest all data contained in the whois record be returned for each and every inquiry; we recommend only the necessary data be returned.

 

C.    Advanced Queries, Centralized Searches (all TLDs)

 

The more advanced services described under (3) do not exist currently on a broad scale.  Services offering advanced queries are provided for, however, in the new TLD environment. 

 

For example, the .biz registry agreement provides that it “will provide multiple responses to queries and allow sub-string and Boolean searches.”  Such functionality may be seen in its advanced Whois service, available at https://www.whobiz.biz/whobiz/whoZilla_Main.jsp?linksource. 

 

The .info registry agreement similarly provides that it will develop an enhanced Whois service that will include “An interface to the Whois database that will permit interested third parties to conduct enhanced Whois searches using Boolean and character string technologies.”

 

The .com registry agreement includes appendix W[22] which provides for the development of a universal WHOIS service (uWHO[23]). Verisign is working with others in an IETF Working Group to develop a new Cross Registry Information Service Protocol (a.k.a. CRISP[24]) to improve or replace port 43 access to WHOIS data.

 

This new CRISP protocol attempts to define methods by which the directory services of domain registries and the common base requirements for extending the use of these services for other types of Internet registries.  CRISP is one standards approach, and that must be kept in mind.  Upon adoption by registries and registrars, it appears it would enable Centralized Public Access by formalizing a uniform interface to the WHOIS data.

 

It appears that CRISP, upon adoption, may provide new ability for role-based access to WHOIS information (for example, the Technical Contact level might permit access to information relevant to networking, while the Billing Contact level might permit access to information relevant to the needs of finance, and so on).

 

CRISP may take many years to develop, implement and be universally adopted[ii], and is unlikely to be available as a short-term solution. In the long run, however, it may help to address many of the concerns with respect to a universally searchable Whois service. It should be noted, however, that some of the functionality provided by CRISP, and other similar standards protocols could also bring along additional policy questions, particularly in the privacy and profiling areas. Such policy areas would have to be addressed at the time of consideration of implementation.

 

The Task Force recommends to all interested parties to participate in the IETF process, in order to provide sufficient guidance to ensure that WHOIS in the future can be uniformly accessible and searchable.

 

We recommend the implementation of and demand for advanced Whois services be monitored in the new TLD environment.  We also suggest ICANN explore how best to develop and implement swiftly a plan for cross-registry Whois services, including third party search services, based on bulk access to WHOIS data.

 

The Task Force Recommends:

1. Centralized Public Access:

(A.) As a first step, further discussion should be undertaken regarding 4. above. Clearly, it is in the interests of the Registrars to provide the WHOIS service themselves. IF, after reasonable exploration of this approach, it appears that no progress will be forthcoming, THEN,

(B.) Consideration should be given to means to meet the stated desire for portal approach to offering centralized access to WHOIS data, across multiple TLDs. Such consideration would require a further work effort and should be based on non-proprietary standards based solutions.

2. The Use of elements other than domain names as query keys and

3. The provision of still more advanced database query capabilities and centralized search services across Top Level Domains, including Country Code TLDs.

 

(A.) The Task Force recommends that searchability is needed on additional elements beyond domain names; these are described in . 1. (0)-(5) above.

(B.) In II, G., 1,2, the Task Force has recommended further examination of the role of standards, including but not limited to CRISP and notes that this recommendation is also applicable to searchability and has recommended a Public Forum to address further the issues of more advanced database query capabilities.

(C.) Several services already exist that offer a form of centralized search service across some gTLDs and some ccTLDs.  Most of these are able to return  searches for the larger gTLDs and some  ccTLDs. Before undertaking further recommendations, the Task Force recommends that a brief examination to any barriers to further additions to these services be undertaken. 


 

INTERIM 4.0  Marketing use of WHOIS data; bulk access provisions 
 
The Task Force has provided both discussion and questions in this section. The format is slightly different but still asks for your input and comments.
 
 
The current bulk access provisions in the Registrar Accreditation Agreement (the “RAA”) contained in Section 3.3.6 allow for the sale of customer information contained in WHOIS databases to third parties under certain conditions, including but not limited to the following:
 
·        Registrar may charge an annual fee (not more than $10,000).
·        Registrar must enter into an agreement with the third party which requires the third party to agree not to use the data:
o       For mass, unsolicited marketing, other than to its own existing customers, and
o       To enable high-volume, automated, electronic processes that send queries or data to any registry or registrar, except to register or modify domain names.
·         The agreement may 
o       Require the third party to agree not to sell or redistribute the data, and
o       Enable registrants who are individuals to opt out of bulk access for marketing purposes and therefore require third party to abide by the terms of that opt out policy.
 
An overwhelming majority (89%) of respondents said that registrants should be asked to opt in for their information to be available for marketing purposes, or that there should be no use of the data for marketing at all, while a minority (11%) indicated that they did not object to use of the data for marketing generally or by virtue of an opt-out policy.  
 
Because these results suggest that respondents object to the use of their personal information contained in the WHOIS database for unsolicited marketing activities, it is clear that there must be a serious evaluation of the bulk access provisions in the RAA to determine how the policy can be changed, whether there are realistic limitations as to what the data can be used for, or whether it must simply be eliminated.
 
Without further research, we cannot say with certainty that the bulk access provisions should be eliminated, although such a possibility should not be dismissed.  In making that determination, the benefits of third party bulk access for should be weighed against the strength of the argument that registrant information should not be available in this form.   A pertinent question here is what legitimate purpose is furthered by the use of WHOIS data in bulk form by third parties?  Given that marketing is not a necessary feature of the DNS, is it sensible to make such data available for marketing purposes?  
 
We recognize that there may be legitimate uses being served by bulk access to WHOIS data (e.g., research, law/intellectual property enforcement, registrant inquiry, individual look up for various purposes, and the provision of value-added services); however, the responses of the survey participants merit an evaluation of these legitimate uses and whether they outweigh registrants’ interests.  To ensure utility of any WHOIS database, it is crucial that information contained therein is accurate.  It should be evaluated whether bulk access to registrant information impedes such accuracy, and whether, therefore, bulk access is deleterious to actual usage of WHOIS.
 
While this recommendation does not rule out elimination of the current bulk access provision, it focuses on modifications of the provision to enhance the protection of WHOIS data.  Specifically, we have parsed through the various components of subsection 3.3.6, highlighting the problem with the provision and making suggestions for an improved provision in light of enhancing protection of data.  Finally, we provide the full text of what we would perceive to be a more acceptable provision given the survey results (Appendix A).
 
Section 3.3.6 of the RAA is broken down into several components, as follows:

3.3.6.1 Registrar shall make a complete electronic copy of the data available at least one time per week for download by third parties who have entered into a bulk access agreement with Registrar.

 

This subsection 3.3.6.1 indicates that the registrar must make available its WHOIS data to “third parties who have entered into a bulk access agreement.”  There are no limitations as to the types of entities or individuals that can enter into this agreement, whether an unsolicited marketing agency, a legitimate third party WHOIS provider, or otherwise.  

 

 

The Task  Force asks your input on the following approach:

 

A. This subsection of the RAA could be modified with limitations on the types of third parties eligible to enter into a bulk access agreement, in particular those parties who are able to articulate a legitimate need for bulk access to WHOIS, and with limitations on the uses of the data that are permitted.

 

1.      The Task Force’s current thinking is that the approach of limiting bulk access to WHOIS data to certain “legitimate” purposes or data is both desirable and feasible.  We invite comments on this line of thinking.

 

2.      What uses of bulk access should be considered “legitimate” for the purposes of this policy? 

 

3.      What impact would these uses have on the privacy of registrants’ sensitive data? 

 

4.      What impact would they have on competition between registrars?

 

 

5.      Should an accreditation regime for bulk access data users or uses be installed? 

 

 

6.      If so, what criteria should be established to guide approval or rejection, and who should administer it?

 

7.      Should ICANN establish standard “terms” via the contract/accreditation agreements, and ask the respective registrars and/or registries to self certify that they are following these criteria in any bulk access sale?

 

8.      For data users and registrars:  The Task Force has been made aware of the use of bulk data for statistics, marketing and query-based services.  Are there any other uses of bulk WHOIS data that should be considered in the Task Force’s deliberations?

 

B. 3.3.6.2 Registrar may charge an annual fee, not to exceed US$10,000, for such bulk access to the data.

 

It would seem that this fee may provide some registrars with a financial incentive to provide bulk access to data would encourage such activity, while simultaneously deterring those third parties with a legitimate need from accessing the data in bulk. 

 

1.      Should a registrar be allowed only to charge a third party for its actual costs of providing electronic copies of the data on a regular basis to the third party. 

 

2.      Is the approach of restricting the fee for bulk data to registrar’s actual cost appropriate, assuming that access under this policy is only mandated for a limited set of purposes?

 

3.      Other comments?

 

 

C. 3.3.6.3 Registrar's access agreement shall require the third party to agree not to use the data to allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass, unsolicited, commercial advertising or solicitations to entities other than such third party's own existing customers.

 

This provision, by its own terms, allows registrars to sell rights to use their WHOIS databases for purposes of unsolicited, mass marketing .  In addition, while third parties may not authorize others to use the data for this purpose, they can themselves use the data to for unsolicited marketing purposes.  Other than limiting unsolicited marketing to the third party’s own customers, there are no limitations on the marketing use of the WHOIS data by the third party.   This subsection is probably acceptable, however, if registrars are required to allow registrants to opt out of these uses (see below).

 

Note:  If marketing uses are not deemed “appropriate” uses of bulk WHOIS data, this provision should be removed.

 

D. 3.3.6.4 Registrar's access agreement shall require the third party to agree not to use the data to enable high-volume, automated, electronic processes that send queries or data to the systems of any Registry Operator or ICANN-Accredited registrar, except as reasonably necessary to register domain names or modify existing registrations.

 

This requirement is important to ensure that its database does not generate dangerous high-volume process that could result from “appropriate” uses of the WHOIS data and unsolicited marketing practices.

 

1.      Should subsections 3.3.6.3 and 3.3.6.4 be maintained as additional safeguards,

even if a modified bulk access provision (1) is limited to ”appropriate” uses, and (2) the uses set forth in subsections 3.3.6.3 and 3.3.6.4 are not considered “appropriate”?

2.      Should ICANN develop a new requirement to impose additional restrictions on bulk access provided by registrars on a voluntary basis, possibly including safeguards similar to subsections 3.3.6.3 and 3.3.6.4? 

3.      How would this be implemented, if agreed to?

 

E. 3.3.6.5 Registrar's access agreement may require the third party to agree not to sell or redistribute the data except insofar as it has been incorporated by the third party into a value-added product or service that does not permit the extraction of a substantial portion of the bulk data from the value-added product or service for use by other parties.

 

Making the prohibition on sale or redistribution of data by the third party an option (“access agreement may require”) does not provide any protection of the WHOIS data.  To protect the integrity of the WHOIS database, the Task Force notes that this provision would have to be changed so that a third party is “required” not to sell or redistribute the data except as part of a value-added product or service.  Additionally, a provision could be added which explicitly forbids any use for purposes other than the ones stated in the bulk access agreement.

 

1.      Should this provision be changed?

2.      Should a provision, which explicitly forbids any use for purposes other than those stated in the bulk access agreement?

 

F. 3.3.6.6 Registrar may enable Registered Name Holders who are individuals to elect not to have Personal Data concerning their registrations available for bulk access for marketing purposes based on Registrar's "Opt-Out" policy, and if Registrar has such a policy, Registrar shall require the third party to abide by the terms of that Opt-Out policy; provided, however, that Registrar may not use such data subject to opt-out for marketing purposes in its own value-added product or service.

 

This provision currently allows a registrar to make its own determination of whether to implement an opt-out policy.  If it does not, a registrant’s information will be accessible via the bulk access procedure for any permissible use, including marketing.  While the results of the survey indicate that respondents have concerns about either an opt-out or no policy at all, the Task Force recommends that this provision be changed to, at a minimum, to “require” a registrar to implement an opt-out policy. 

 

We believe that the concept of opt-out may have been overlooked by respondents who reacted viscerally to the general lack of any option as to whether their information is included in bulk access.  In addition, we believe that immediately requiring the adoption of an opt-in policy may result in a significant deterioration of the information contained in the bulk access database, which would be detrimental to legitimate third parties making non-marketing uses.

 

If, after adoption and evaluation of a requirement for an opt-out policy, it is clear that improper marketing uses of bulk access data are continuing, then an opt-in policy for any marketing uses should be implemented.  It is crucial that opt-out policies implemented by registrars are simple and transparent and that the opt-out of the registrant is respected in practice.  If marketing use of bulk WHOIS data is not considered an “appropriate” use, then this provision could be eliminated entirely.

 

  1. For bulk access data users and registrars:  what experiences do you have with the current RAA policy to limit registrants’ opt-out options to marketing uses? 
  2. Is it feasible to have different policies and different sets of bulk data for marketing and non-marketing uses?
  3. If marketing is considered an “appropriate” use of bulk WHOIS data, should ICANN policy specifically mandate that registrants can opt out of marketing use of their data (without giving registrars the discretion to introduce opt-in policies), or should ICANN only specify minimum requirements (so registrars can establish an opt-in policy)? 
  1. Should there be an analogous provision for non-marketing bulk access? 
  2. What privacy concerns would be created by that kind of access?  What impact would such a provision have on legitimate non-marketing bulk uses, and why?
  3. Should ICANN policy impose a similar provision on bulk access to WHOIS data provided by registrars on a voluntary basis?  Would this be considered within ICANN’s mandate?

 

Closing Summary on recommendations and Request for Comment:

We believe that the modifications that we have recommended in this report will enhance the protection of registrants’ information in accordance with the desires expressed in the survey.  In addition, we believe that this enhanced protection could minimize conflicts between WHOIS policies relating to registrar bulk access with international privacy laws.

 

Clearly, further dialogue and consultation is needed on some areas, such as the relationship and issues of privacy in regard to access to individual contact information.  While there are questions about access to contact information about individuals who are registered in the WHOIS database, the Task Force believes that further examination and understanding is needed before recommending limiting access to the WHOIS database.

 

We also believe, from our limited examination of the ccTLDs, that there are innovative practices underway in some of the ccTLDs dealing with data accuracy and with access.  We propose that a workshop format could provide an excellent resource for the sharing of information both across ccTLDS and for others interested in WHOIS policy

 

Data accuracy, in our report, is treated separately from access to such data; our philosophy has been that if data is collected, it should be accurate, or should be corrected in a timely manner. Efforts should be made by the registrars, when notified, to obtain correct contact data. Failure to provide such correct data should result in the suspension, or revocation of the registration. Registrars should be supported in their “policing” of such inaccurate data, and there should be a clear understanding of penalties to the registrar who fails to take responsible action.

 

We have asked for substantial feedback from the community. Although we have spent extensive time in understanding and discussing, we seek substantive feedback on our Interim Report and draft recommendations before we finalize recommendations to the Names Council. 

 

IV.              Impact Analysis

 

This section of the report cannot be completed until further comments are received on the recommendations of the Task Force.

 

V.                 Constituency Impact Reviews

 

This section of the report will be completed upon receipt of constituency statements, expected in response to the posting of the Interim Report

 

VI.              Record of Outreach

The full outreach undertaken  will be completed and posted at the conclusion of the final outreach period, expected to last almost four weeks. The summary below captures those comments posted to the Public Comment web site provided by ICANN.

Summary of Comments on Whois Task Force Report –prepared 10/1/02

·        Jul. 18, 2002: Comments of Nainil Chheda

Wants a Whois query that shows only admin email, date of registration and expiry of domain.  Does not want any other details to be displayed.

 

·        Jul. 18, 2002: Comments of Tim Ruiz of Go Daddy Software, Inc.

Wants a specific definition of what “accuracy” of Whois data means, a specific definition of what reasonable effort on Registrar’s part is required to ensure that accuracy, and what steps Registrar may take, without repercussions, when inaccuracies are found.  Wants uniformity of data formats and elements across various TLDs and registrars, including ccTLDs.  Wants this to be pursued as part of recommendation for gTLDs, believes ccTLDs can wait for a separate deliberation.  Use of the Whois data for marketing purposes of any kind, should be prohibited, unless they have a verifiable EXISTING business relationship (perhaps within the last 12 months). By allowing a PRIOR business relationship, you give the largest Registrar, a prior monopoly, an unfair advantage. The registrant should not have to "opt-in" or "opt-out". The Whois data should never be viewed, used, or treated as a marketing list.

 

·        July 27, 2002: Comments of Danny Younger

Irritated with Task Force’s recommendation that there be a review of the current bulk access provisions of the Registrar Accreditation Agreement because the ICANN board already referred the matter to the Names Council (Jan. 22) and the Council voted to delegate to the Whois TF (Feb. 14).  Wants the decision to be made, irritated that it’s taking as long as it is.

 

·        August 7, 2002: Comments of Don Brown, Internet Concepts, Inc.

Disagrees with TF’s findings with respect to accuracy of Whois database.  First, cancellation of registration due to outdated information is too harsh.  Where a registrant has moved, for example, there is no reasonable way for a registrar to update this information.  Domain name shouldn’t be cancelled when registrar can’t contact registrant or registrant doesn’t reply.  Sees this situation as similar to the proposed redemption grace period situation, where the community seems to see the importance of saving registrant’s domain names even when expiration/deletion is caused by the registrant’s own negligence.  Secondly, wants to see definitions of what constitutes compliance and non-compliance with registrar’s requirements for accuracy.  What is the reasonable and commercially practical protocol for verifying new registrations and re-verifying old registrations?  Should the registrar telephone each new registrant?  What if there is no answer?  What if there is a typo in the telephone number field?  What if the registrant has moved? 

 

·        August 8, 2002: Comments of Gian A. Ameri

.Name domain names should be excluded from having to provide Whois data because the .name extensions are being used by individuals, not companies.  ICANN’s current policy applies to companies and organizations, not individuals. "[I]ndividuals" registering a .name domain, unlike any other legal entity, should continue to be allowed, in compliance with the E.U. and U.K. Data Protection Act, to opt-out from the publishing of their personal data in WHOIS searches or for that matter in any other way, shape, or form.

 

·         August 12, 2002: Comments of Glen Taylor

Would like to see limits placed on registrar’s use of Whois for marketing purpose, citing as an example, Register.com’s practice of inserting “make on offer on this domain” into every Whois query.

 

·        August 13, 2002: Comments of Marie-Laure Bonnaffous, UNICE

UNICE is an independent organization representing European businesses vis-à-vis the institutions of the EU.  Believes that the same requirements to provide accurate Whois data should be applied not only to accredited registrars but all ccTLD registrars as well.  Sanctions, such as the possibility to suspend or cancel an inaccurate domain name should also be in place.  Believes that data format for Whois information now applicable to gTLDs should be applied to ccTLDs.  Phone and fax numbers of the registrant should only be available on an opt-in basis, as they are not considered to be essential for the purposes of businesses and IP interests.  Believes a centralized database providing Whois for gTLDs and ccTLDs would be beneficial, but that it should not be ICANN’s responsibility to provide.  Believes users should be able to search by all data fields.  Suggests that while basic information should be available for free, a more detailed search could be paid for by users.  UNICE doesn’t support the use of personal data in Whois databases for marketing purposes. An opt-in accepting use rather than an opt-out clause and restrictions on access to bulk data would assist in reducing opportunities for misuse of the data.

 

·        August 13, 2002: Comments of Todd Glassey

Highly critical of ICANN and Whois policy in general.  Suggests major overhaul of Whois database, including “pruning” existing entries by determining whether or not they are valid.  Suggests ICANN make a determination about what to do with dead entries in Whois.

 

·        August 13, 2002: Comments of Elisabeth Porteneuve

Comments of a registrant.  Argues that updating her own information is too difficult to do.  Wishes it were as easy as it use to be under the NIC-Handle format, where she could update the NIC-Handle once and all associated domain names were updated.  Wants an easy and efficient way to update all registrant data.

 

·        August 14, 2002: Comments of Olivier Guillard, AFNIC

Concerned that “registrant” is being confused with the person who has rights to the domain name.  Suggests that a new field be added to Whois information, “holder” indicating the entity that holds the rights to the domain name.  Advocates searching by registrant name, allowing for limits on the number of results that may be pulled.

 

·        August 14, 2002: Comments of Lisa Benjamin, Nominet UK

Nominet requires a warranty by the registrant that the data provided is accurate and an indemnity should Nominet receive a claim based on inaccurate data.  Nominet reserves the right to cancel or suspend a domain name if there is independent verification that the information is “grossly inaccurate, unreliable, or false.”  Feels that it is the registrant’s responsibility to provide accurate data, and that expanded Whois should help the registrants identify whether the data is accurate or not.  Suggests it would be very costly, a cost eventually passed on to the registrant, to require the registrar to verify the accuracy of registrant data.  Believes that uniformity of formats between gTLDs and ccTLDs may be difficult due to national data protection laws.  This concern is also extended to the issue of better searchability for Whois databases that might include ccTLDs.  Nominet doesn’t support the use of the register for marketing purposes, and supports proposals to provide stronger privacy protection for registrants in this regard.

 

·        August 16, 2002: Comments of Michael Laudahn

Maintains a site that deals critically with adverse conditions in the world, worldimprover.net.  Advocates keeping personal registrant data “secret” in order to make it more difficult for people in high places to pursue their evil course.

 

·        August 20, 2002: Comments of John Wong

Identified embedded auto-redirect html script tags in the Whois data, both web and Port 43.  They are used to redirect browsers or html-aware telnet clients to some penny-per-click sites.  Suggests that sections A-Accuracy of Data in Whois Database, or B-Uniformity of Data formats and Elements, be expanded to discourage the use of executable script tags, or the placement of promotional data into inappropriate fields in the Whois contact database.  Also suggests as an alternative, creating new fields in the Whois contact database where this kind of promotional information can be entered. Suggests discouraging the use of html tags in Port 43 Whois data.

 

·        August 20, 2002: Comments of Reed Smith and Warner Cranston

Suggests that the proposed enforcement provisions related to data accuracy be    themselves enforceable in the key jurisdictions and apply evenly to registered domain holders in different jurisdictions across the Community.  Suggests that the Task Force consider the drafting of the model provisions in more detail and conduct a legal review of the enforceability of these measures in key jurisdictions.

 

·        August 27, 2002: Comments of Danny Younger

argues that if he can have an unlisted phone number, why not a domain name without Whois contact data?  Suggests that there be a domain name registration equivalent to an unlisted telephone number and that registrars should be allowed to charge for that service.

 

·        August 27, 2002: Comments of Keng

Advocates free and easy Whois accessibility.  Advocates Whois data uniformity across registrars.  Does not think marketing of Whois information is inappropriate.  Believes that the domain name owner should have the right to review the marketing materials before committing.  It should be the domain owner’s choice.

 

·        August 28, 2002: Comments of Vittorio Bertola

Could not access the comments.  The attached document was encrypted in Bin-Hex format which my computer was unable to decrypt. 

 

 

VII.           Minority Reports

 

This section is reserved for any minority reports which are put forward. None have been received to date.

 

 

VIII.        Supporting Arguments

 

At this point, the supporting arguments are embedded in the Recommendations Section since the Task Force believed that recommendations were clearer in the Interim Report when accompanied by explanatory text. In the final report, we expect to put forward the recommendations as a stand-alone section, with a resolution to the Names Council, and all supporting arguments will then be moved to this section.

 

 

IX.              Risk/Cost Analysis

 

 

 

X.                 Publication and Comment Period

 

 

XI.              Final Conclusions/Recommendations

 

This section will contain the final recommendation via resolution presented to the Names Council.

 

 

 

Appendix I/Links

 

Links:

Task Force Archive

Survey Questionnaire

Survey Results

Final Report on the Survey

Presentation in Ghana

Presentation in Bucharest

Comments via public forum - Final Report on the Survey

Transcripts from outreach

Comments from Public Forums - 10/14-11/8

 

Appendices

List of Task Force Members

"NonCom - Hakikur Rahman" 
"NonCom - Gilbert Estillore Lumantao" 
"gTLD Registries - Ram Mohan" 
"gTLD Registries - Karen Elizaga" 
"ISP - Tony Harris" 
"ccTLD - Oscar A. Robles Garay" 
"BC - Marilyn Cade" 
"BC - Bret Fausett" 
"BC - Troy Dow" 
"IP - Laurence Djolakian" 
"Registrars - Philipp Grabensee" 
"Registrars - Tim Denton" 
"GA chair - Thomas Roessler" 
"GA additional - Abel Wisman" 
"GA additional - Kristy McKee" 
"IPC. Steve Metalitz "
"Registrars - Ken Stubbs"
"Sarah Andrews" 
"NC Chair - Bruce Tonkin"

Other

 

 


[1]http://www.icann.org/registrars/ra-agreement-17may01.htm

[2]http://www.icann.org/announcements/advisory-10may02.htm

[3]http://www.icann.org/committees/whois/. 

[4]http://www.imc.org/ietf-whois/

[5]See the results of the evaluation of question 13 of the survey. From the evaluation of the free-form responses to the latter part of this question, the task force is concerned that this question may have been misunderstood by some of the respondents.

[6]See the results of the evaluation of question 12 of the survey.

[7]See the results of the evaluation of question 14 of the survey.

[8]See the results of the evaluation of question 10 of the survey.

[9]The first of these aspects was covered by question 10, the second one by the parts of question 14.

[10]Documented in RFC 1580/FYI 23 (Guide to Network Resource Tools), chapter 6.

[11]See http://www.icann.org/committees/whois/touton-letter-01dec00.htm; see also RAA sec. 3.3.4 (registrars to contribute data to cross-registrar WHOIS service).

[12]See, e.g., sec. 3.10.5.1 of the unsponsored TLD registry agreement, http://www.icann.org/tlds/agreements/unsponsored/registry-agmt-11may01; sec. II(11)(E)(i) of .com registry agreement, http://www.icann.org/tlds/agreements/verisign/com-index.htm.

[13]See http://www.icann.org/tlds/agreements/verisign/registry-agmt-appw-com-16apr01.htm

[14]See http://www.icann.org/tlds/agreements/info/registry-agmt-appo-11may01.htm; http://www.icann.org/tlds/agreements/biz/registry-agmt-appo-11may01.htm

[15]See RAA, 3.3.6.

[16]See the evaluation of questions 16, 17 of the survey.

[17] See, e.g., http://www.icann.org/cctlds/jp/sponsorship-agmt-27feb02.htm.

[18] See http://www.centr.org/news/CENTR-ICANN-statement.html.

[19] see http://ecommerce.wipo.int/domains/cctlds/bestpractices/bestpractices.pdf

[20] http://www.ietf.org/html.charters/crisp-charter.html

[21] To Subscribe: ietf-not43-request@lists.verisignlabs.com

[22] appendix W:  http://uwho.verisignlabs.com/com.html

[23] uWho:  http://uwho.verisignlabs.com/

[24] CRISP:  http://www.ietf.org/html.charters/crisp-charter.html


[i] II.F.1. At its expense, Registrar shall provide an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e. updated at least daily) data concerning all active SLD registrations sponsored by Registrar in the registry for the .com, .net, and .org TLDs.  The data accessible shall consist of elements that are designated from time to time according to an ICANN-adopted policy. Until ICANN otherwise specifies by means of an ICANN-adopted policy, this data shall consist of the following elements as contained in Registrar's database:

          a. The name of the SLD being registered and the TLD for which registration is                 being requested;

          b. The IP addresses of the primary nameserver and secondary nameserver(s)                  for the SLD;

          c. The corresponding names of those nameservers;

          d. The identity of Registrar (which may be provided through Registrar's                website);

          e. The original creation date of the registration;

          f. The expiration date of the registration;

          g. The name and postal address of the SLD holder;

          h. The name, postal address, e-mail address, voice telephone number, and                     (where available) fax number of the technical contact for the SLD; and

          i.  The name, postal address, e-mail address, voice telephone number, and                     (where available) fax number of the administrative contact for the SLD.

The Registrar Accreditation Agreement may be viewed in full at http://www.icann.org/nsi/icann-raa-04nov99.htm#IIF1#IIF1

 

[ii] see i. above.