Commercial and Business Constituency (BC) Comments on the Preliminary Task Force Report on WHOIS Services
BC Comments related to the Preliminary Task Force Report on WHOIS Services I. Purpose of this Contribution: The Commercial and Business Users Constituency (BC) provides its Constituency comments on the Preliminary Task Force Report on WHOIS Services. II. Improvements to the Final Report of the Task Force Recommendations to Improve the TF Final Report: A. A brief summary of the various processes and events undertaken by the TF, including participation in workshops, outreach via conference calls to external parties, etc. should be added to the Background section, under a suitable heading describing the work processes of the TF. B. Full wording of the GNSO Council resolutions should be added as appendices and links to the resolutions be inserted into the Background section of the Final Task Force Report. This will provide a fuller record when the Final report is considered by the GNSO Council, and eventually, the ICANN Board. The relevant resolutions are 20060720-02 and 20060720-03 and can be found at <http://www.gnso.icann.org/resolutions> www.gnso.icann.org/resolutions. III. BC Comments specific to the Preliminary Task Force Report The BC comments in general support Special Circumstances Proposal over OPOC, provide input and recommendations to improve the two proposals under consideration by the TF; propose additional steps, in lieu of either proposal, that will improve the WHOIS service, curtailing harvesting of emails and telephone numbers from publicly displayed WHOIS data, and limiting any marketing uses of WHOIS data. The BC also recommends a study by an independent third party of the characteristics of gTLD registrants in non sponsored gTLDs, as well as the uses and perceived misuses of WHOIS data. A. Comments of the BC related to the OPOC Proposal The BC highlights the following concerns and questions related to the OPOC proposal: 1. As presently drafted, the OPOC Proposal does not provide a clear definition of the roles and responsibilities of an OPOC. The only statement in the proposal related to the obligations of the OPOC is: "The purpose of the operational point of contact is to resolve, or to reliably pass on data to resolve, operational issues relating to a domain name. At a minimum, this must include the resolution of issues relating to the configuration of the records associated with the domain name within the DNS server."[1] Any other obligations are optional between the OPOC and the registered name holder. Recommendation: An agreed set of responsibilities should be included, and published as part of the registrant agreement, which should be reviewed and accepted as part of the registration process. 2. The OPOC eliminates the postal address of the registered name holder, but does not provide certainty of how such registered name holder will be contacted by the OPOC, in the event of problems, legal issues, etc. The BC opposes the elimination of the postal address of the registered name holder. Registered name holders are ultimately the parties responsible for registering a name, and any misuse, or use related to the name registration. 3. If there is a change that creates a new designation such as 'OPOC', there should be a range of options to the registered name holder in how that function is fulfilled including self provision of these functions. The tasks and purposes of the OPOC must therefore be defined, and at a minimum must include: a) Agreement to provide accurate and complete contact details for a 24/7 contactability, and to maintain published and accurate data b) Agreement to accept all kinds of contacts, ranging from technical, administrative, IP conflict, legal notices, contact from law enforcement, on behalf of the registered name holder c) The ability to address and resolve technical or operational issues or problems. d) Responsibility for forwarding, within an appropriate timeframe*, correspondence and requests to contact the registrant and/or the technical resource for the registrant. *The TF has discussed but not resolved what an appropriate time frame may be. Some issues that are encountered are urgent, such as network attacks, phishing, pharming incidents, etc. Recommendation: The BC recommends that the 'defined purpose and functional tasks to be performed by the OPOC' should be established by consensus policy. This should include a requirement that Registrars ensure that registrants read and accept or delegate to an identified third party or to the registrar, if acting as the OPOC, the responsibilities of the OPOC, at the time of registration/renewal. 4. As presently drafted, the OPOC proposal does not provide a standardized mechanism for access to non-public contact data for legitimate stakeholders, upon the implementation of an OPOC by a registered name holder. The proponents of the OPOC proposal acknowledged this deficiency during the Public Forum at the ICANN meeting in Sao Paulo. Recommendation: Any proposal to modify the existing WHOIS policy related to data displayed and access to data must include a process for access to non displayed data before changes in the existing practices are introduced. 5. The BC welcomes hearing from proponents of OPOC regarding recommendations for how to address access to non displayed data. 6. One approach that could merit study is the recognition that there are hundreds of accredited registrars, and that any approach needs to take into account the burden on legitimate users of WHOIS. It may be appropriate to examine the creation of a "white list" for legitimate stakeholders who need access to deal with "legitimate" purposes, such as network attacks; phishing; pharming attacks; trademark collisions, etc. This 'white list' should be developed and maintained by ICANN, based on criteria that are broadly agreed upon, and published for public comment. The cost to become 'accredited' should be borne by the applicant. ICANN should publish the 'white list' on the ICANN web site. Accredited ICANN Registrars /registries should be required to recognize the status of those on the 'white list'. A form of unique standard identification and sanctions by ICANN will be needed to prevent abuse of this status. 7. At present, the OPOC proposal does not address accuracy improvement. If OPOC were to be adopted and thus even less data were to be made publicly available the accuracy of the OPOC's contact data becomes even more important. Recommendation: The OPOC proposal should be elaborated to include a pre validation of the completeness and accuracy of contact details of the OPOC at the time of registration. The RAA should also provide for periodic checking of the OPOC details and a standardized notice to the registrant, to remind them to verify the accuracy of their OPOC details, and of consequences of providing inaccurate, or failing to correct such data, such as suspension/loss of registered name. 8. The issue of a 'system-wide' change of this nature, encompassing tens of millions of records for registered names needs to be examined for its implications. In addition, if such a change in envisioned, the TF should schedule a further discussion with relevant parties related to the role and implications of IRIS/CRISP and whether there is a consideration of a longer term evolution to a new protocol for WHOIS. A detailed discussion with ICANN Operational staff is needed to examine implementation issues. Conclusion: The BC does not support the OPOC Proposal as presently drafted, and remain doubtful that these issues will be satisfactorily resolved. B. THE SPECIAL CIRCUMSTANCES PROPOSAL (SCP) Although the Special Circumstances Proposal has areas of improvement needed, and the BC suggests that other mechanisms, such as are described in IV, are in need of further examination by the TF, in general the BC supports the Special Circumstances objectives. The Special Circumstances Proposal (SCP) addresses a specific need that has been identified by a number of ICANN stakeholders, and that the BC recognizes: that there are a limited number of registrants who are indeed acting purely as individuals in their use of a domain name, or who have a legitimate need for a private registration due to the nature of the services that they provide, such as a service for abused spouses or children. The SCP assumes that for the most part, those who register domain names are holding themselves out to communicate with the public, and that, given proper notice and choice of whether they use a domain name registered from an ICANN accredited registrar and build and maintain a unique web site, versus utilizing a web hosting service that can provide similar functions, hosting of information, etc. the registrant can make an informed choice of how to proceed. In the registration and use of domain names, the BC believes that the public at large has a right to know with whom they are interacting and communicating. The BC recognizes that there are instances where a registrant has a legitimate need for a private registration. While the BC believes that such registrations are limited, and should be validated, the BC can support the development of a model similar to that of the 'unlisted numbers' used in certain national telecommunications jurisdictions, including the US and certain countries in Europe. Therefore BC supports the concept of establishing a process whereby an individual, or appropriate non commercial service entity can apply for an opt-out for the inclusion of their contact data in a publicly accessible WHOIS if their safety and security cannot be protected otherwise, as provided by the Special Circumstances Proposal. The BC can support the Special Circumstances Proposal in principle, but has identified some improvements and questions yet to be addressed. B. 5. Improvements and enhancements that the BC would like to see elaborated on for the SCP are: 1. Purpose of the registered Name Holder: The BC notes that the present SCP does not provide a definition. 2. Purpose of the Technical Contact and Administrative Contact. Recommendation: The BC supports the definitions from Exhibit C of the Transfers Task Force and suggests that they be incorporated in the SCP. 3. Access to Data: Since the majority of registered names will have all data displayed, there is less demand for new procedures for access to non displayed data. The BC proposes other changes in how data is displayed, in Section IV. 4. However in the SCP area, for the registration contact data not displayed due to approval for SCP the BC suggests that there needs to be an improved procedure for access to data not displayed. The BC would like to see this area elaborated. 5. The SCP does not provide discussion of steps needed to improve accuracy of registrant, technical, and administrative contact data in registration and renewal of domain names. Recommendation: The SCP should be elaborated to include a pre validation of all contact details at the time of registration for any party determined to be eligible for SC. The third party who holds the data should be required to provide accurate data for themselves and to attest that they have verified and maintain accurate contact data for the registrant. The RAA should also provide for periodic checking of the SC registrant data and procedures to require updates, or corrections. 6. The BC agrees that the proposal needs to be examined for scalability to the gTLD non sponsored space. In general, the BC supports the concepts provided in the SCP to rely upon outsourcing of the special circumstances application process to independent third-party vendor(s), possibly on a regionalized basis, ensuring adequate funding and outlining a simple and clear process for the application, designation and appeal of "special circumstances" request(s). This will require support from the ICANN operational staff, and should be explored, keeping in mind the lessons learned from the .nl service. IV. Additional Recommendations on Other Steps that the Task Force should consider: Neither the special circumstances proposal nor the OPOC proposals address concerns related to the mining of WHOIS data for marketing purposes, a use that the BC has consistently opposed. The BC therefore endorses steps that can assist in limiting misuses or abuses of publicly accessible WHOIS data. The steps recommended by the BC are supplemental to, but consistent with the concerns and issues now being addressed by the TF; for instance, the recommendation to rely only on web based display of WHOIS data, with adequate IVC addresses the TOR's question about access to data; since the majority of registrant data would still be displayed, but with limits on any other uses of the data, e.g. for marketing. Recommendation A. Study related to Facts about gTLD Registrants; Uses of Domain Names, Misuses of WHOIS Data; Uses and Users of WHOIS Data It is time for a comprehensive study which should address the characteristics of registrants and of users of WHOIS data in the non sponsored gTLD registry space. This study should be undertaken by a neutral third party, retained and funded by ICANN, and study such issues as the characteristics of registrants; whether a domain name is actually in use [live DNS], uses and misuses/abuses of WHOIS data. Comments related to the development of the elements and scope of the study should be sought from the GNSO's Constituencies, the Advisory Committees, including At Large and GAC, and the SSAC. The BC calls for a study of non sponsored gTLDs and WHOIS, to encompass at least the following issues and questions: 1. Characteristics of registrants in the non sponsored/open gTLDS, e.g.: numbers of registrants who: 1) use the domain name for personal use; 2)for 'speculation/holding/resale; 3)for traffic aggregation; 4)for non commerce; and 5)for commerce online and 6) governmental or related purpose 7) other [to be identified] 2. Identify the percentage/number of sites that are registered, but do not have 'live DNS' versus those that are actually in use 3. Uses, misuses and abuses of WHOIS data, as publicly displayed 4. Identify the percentage of inaccurate data, and undertake a sample examination of why data is inaccurate - e.g. a) aged data; b) typo/registrant error c) purposeful provision of inaccurate data d) other [to be identified] Recommendation B. Steps to eliminate 'data mining' Over the history of GNSO work on WHOIS, concerns have been raised about 'data mining' of publicly available WHOIS data; and misuses of port 43 and bulk access to WHOIS data. Steps have been taken in the past to attempt to curtail marketing uses of bulk access data. However, the BC recommends further changes that can curtail, if not eliminate data mining and harvesting of email and telephone numbers and limit any misuses of bulk access data. In addition, the BC proposes strict limits to how bulk access and Port 43 access to WHOIS data is granted, and the creation of a 'white list' of authorized uses, and users. 1. All WHOIS access should be changed in all WHOIS publicly available services to web based access. Such web based services should include an Image Verification Check (IVC) of sufficient security strength so that the random letters generated are not easily machine readable. 2. All bulk access should be moved to ICANN developed contractual terms for access, with an accreditation process for parties allowed to have such contracts. ICANN should develop standard terms and conditions and enforcement them when they are violated. These standard terms and conditions should be applied to all gTLDs; and a standardized range of cost recovery fees can be established. In general, parties who need bulk access for legitimate purposes are trademark and other firms that provide trademark defense or portfolio management services, or services utilized by law enforcement authorities. 3. This approach does need further exploration with law enforcement and consumer protection authorities to ensure how best to address their need for port 43 access or bulk access. Summary: In summary, the BC does not believe that the recommendations presented by the WHOIS Task Force are yet complete, nor do they represent full consideration of the full range of issues and implications with system wide changes, nor do they address balanced consideration of the full range of public policy implications. The Task Force has not yet given sufficient consideration to options for addressing changes in the display of data, nor in how to deal with the non display of data, if changes are made in the public display of data elements. In the OPOC, the issues of a system wide change that will implicated tens of millions of registrations has to be considered, and examined for how it might cause registrant confusion or even add extreme burdens of customer complaints during an implementation. Discussions of phased implementation, with changes occurring at the time of renewal have to be undertaken, while recognition of multiple year registrations and the need for co-existence of dual systems has not been a topic of discussion. In the SCP, there is a need for further examination of how to implement the recommendation, including the development of criteria for the 'special circumstances' status. However, in this instance, some historical success of country codes who have undertaken similar approaches can be studied and drawn upon. The BC again notes that in general, they can support the Special circumstances over the OPOC proposal. The BC's additional recommendations should be explored and implemented as first steps to limit some of the areas of concern that are often expressed by parties who object to public display of data because of abuse of bulk access, or data mining. V. Process followed: According to the ICANN bylaws (Annex A, paragraph 7.d.1) the Task Force Reports must include constituency statements. The BC has provided earlier Constituency Statements related to the "Purpose of WHOIS and of the WHOIS Contacts". The earlier constituency statement was requested before the level of detailed recommendations presented in this Preliminary Report. The BC's comments are provided in detail in the previous sections. Relevant section from ICANN bylaws: Annex A, Paragraph 7.d. 1. Constituency Statements: (i) if a Supermajority Vote was reached, a clear statement of the constituency's position on the issue - the constituency's position is detailed in the submission. (ii) if a Supermajority Vote was not reached, a clear statement of all positions espoused by constituency members: Non applicable. (iii) a clear statement of how the constituency arrived at its position(s) The BC has three representatives to the WHOIS Task Force: Marilyn Cade, David Fares, and Sarah Deutsch. Throughout the work of the Task Force, the representatives have maintained interaction with the membership, including postings and briefings by BC TF members on the work of the WHOIS Task Force. BC members are generally quite concerned and interested in WHOIS, and are actively engaged in this topic, when it is raised within the BC, or is the subject of ICANN public forums/workshops. As an example, members were briefed on both of the proposals; and discussions took place in the face to face ICANN meetings, as well as on the BC list. The BC Rapporteur and fellow Task Force members forwarded the draft Constituency comments to the BC list on December 28. BC members had 14 days to provide comments and edits to the Comments, and were specifically asked to show their support to the report, and to identify any areas of disagreement. The BC TF members edited the Comments, and prepared this final submission, taking into account all responses received, and discussions that have taken place on the BC list and face to face meetings and workshops. (iv) analysis of how the issue would affect the constituency; including any financial impact on the constituency The BC's interests are harmed by the lack of accurate WHOIS data and will be harmed by lack of access to WHOIS data, if public access to WHOIS data is changed, and if there is no suitable substitutes to ensure that legitimate users have timely access to accurate WHOIS contact data, so that they can deal with network attacks, trademark infringements; phishing and pharming attacks, as well as undertake normal use of the WHOIS database related to checking for availability of registerable names for use in setting up new web sites. The BC expects the impact of the OPOC proposal and the Special Circumstances Proposal to have significant financial and resource impact on registrants, including business users during the time to incorporate a system wide change. As users of WHOIS data to address problems, the BC anticipates significant resource demands as new procedures are developed, disseminated, and incorporated widely. The OPOC proposal is anticipated to have an ongoing negative financial impact to users of WHOIS data, who rely on access to WHOIS data to quickly identify and contact the party responsible for cyber squatting, phishing, pharming, network attacks, and trademark infringements. A move to web based access coupled with improved contractual terms for bulk access will represent the least invasive change to users, but will curtail data mining in displayed data. Thus, this change, as recommended by the Business Constituency, provides improvements to WHOIS but without the associated harms to the interests of the Business Constituency's members. (v) an analysis of the period of time that would likely be necessary to implement the policy(ies): The time frames to implement any of these changes is significant. If improved and adopted, the OPOC proposal would take extensive time to finalize and implement, since it is dependent upon changes in operation that affect all registrants of domain names. An implementation team should include broad representation from ISP/Connectivity providers, business users and At Large, since it is registrants who will have to first understand and undertake the changes needed to identify an OPOC, and then incorporate this change in their registration process. In the past, implementation teams have been dominated by registrars and/or registries. In this situation, it is imperative that full attention be given to the challenges that registrants will face as they are asked to incorporate possible changes in their operation in order to identify an 'OPOC'; establish such a role internally, or reform how they manage their domain name portfolio to take into account 'outsourcing' of these functions now managed internally. While the impact on small companies who typically rely upon their ISP or registrar already for such services may be minimal, larger more distributed corporations may take more time to assimilate a change in functional assignment of responsibilities typically managed internally. Implementing changes involving several tens of millions of registrations as required if OPOC moves forward, is a major change and one not yet achieved in the history of an ICANN with the number of registered domain names under management in the non sponsored gTLDs. The BC notes that the TF has not discussed the scope and scale of such changes, nor the details related to educating and creating awareness among registrants, although the topic has been raised in the TF. Therefore, until such discussion takes place, the BC cannot estimate the length of time, but does call for an examination of how the registrant population will be educated about changes, both in OPOC, and in SCP. The SCP is more limited in the number of registrations affected, since it is limited to those registrations determined to have a need for privacy. The time challenges for SCP will be related to the creation of a process to determine who should be eligible; and identifying and retaining an entity(ies) that can accept applications. The BC acknowledges that the SCP process can be modeled upon the .nl model, but the issues of scalability need to be addressed. ICANN staff resources are implicated for both proposals, and a discussion of the feasibility and implementation details are needed for both proposals. These should be scheduled and completed during the public comment period so that the TF can take this consideration into account as part of the preparation of the Final Report. The BC's recommendations related to a study and to other changes also deserve further consideration in terms of time to implement. Just like the OPOC and Special Circumstances Proposal, the change to web based access would require work by an implementation team that should include representatives from all constituencies and the operational staff. And, similarly to the other two proposals, an outreach and awareness 'campaign' by ICANN that announces substantive changes to WHOIS access would be needed. Once ICANN agrees to fund a study, the terms of reference for a study can be defined, and posted for public comment. It is conceivable that with commitment to undertaking the study, and with assigned staff working with the relevant expert parties to solicit input and feedback, a well documented and statistically valid survey instrument; coupled with a series of data interviews of representative users, registrants, registrars, etc., can be developed within a matter of a few weeks. The study will probably require both public data gathering, and solicitation of subjective data, describing misuses or abuses of WHOIS data, and also misuses and abuses of domain names, where WHOIS data has been used to address and provide investigatory resources to curtail or end abuses. The design, preparation, and conducting of such a study should become a priority in order to guide and inform policy making. Once agreed, the study could even proceed in stages, with interviews and statistically oriented questionnaires proceeding simultaneously. The study could be developed and implemented in parallel to the rest of the work on WHOIS needed at the GNSO Council, in its further outreach and consultation with the advisory committees. Submitted on behalf of the Business Constituency WHOIS Task Force members: Marilyn Cade Sarah Deutsch David Fares 15 Jan 2007 _____ [1] It is important to note that there remains significant confusion over the scope of activities covered by "operational issues relating to the configuration of the records associated with the domain name within the DNS server." Indeed, the Chair of the GNSO Council interprets this phase broadly while others construe it to mean only technical matters. Attachment:
BC Comments related to the Preliminary Task Force Report on WHOIS Services.doc |