ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Commercial and Business Constituency (BC) Comments on the Preliminary Task Force Report on WHOIS Services

  • To: <whois-services-comments@xxxxxxxxx>
  • Subject: Commercial and Business Constituency (BC) Comments on the Preliminary Task Force Report on WHOIS Services
  • From: "Marilyn Cade" <marilynscade@xxxxxxxxxxx>
  • Date: Mon, 15 Jan 2007 16:54:08 -0500


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


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>


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


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


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


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


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. 




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


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


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. 



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


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
Description: MS-Word document

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy