<!--#set var="bartitle" value="WHOIS Privacy Steering Group"-->
<!--#set var="pagetitle" value="WHOIS Privacy Steering Group"-->
<!--#set var="7 August 2003" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Privacy Steering Group minutes'"-->
<p align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Privacy Steering
Group Teleconference August 7/8 - Minutes</b></font></p>
<p><b><font face="Arial, Helvetica, sans-serif">ATTENDEES:<br>
<br>
</font></b><font face="Arial, Helvetica, sans-serif">Acting Chair: Bruce Tonkin
(non voting)<br>
<br>
Voting members of the committee (Note with reference to the GNSO Council decision
documented in the <a href="http://www.dnso.org/dnso/notes/20030605.GNSOteleconf-minutes.html">minutes</a>
of the meeting on 5 June 2003, each constituency could appoint one or two members
to the WHOIS Steering Group - the members may be from outside the GNSO Council
- each constituency would have one vote in any vote proposed in the WHOIS Steering
Group.) <br>
<br>
Intellectual Property Interests Constituency : Steve Metalitz <br>
gTLD Registries constituency: David Maher, Ken Stubbs <br>
Commercial and Business Users constituency: Marilyn Cade, Grant Forsyth <br>
Non Commercial Users Constituency: Stephanie Perrin (replacing Ruchika Agrawal)
<br>
Registrars Constituency: Tom Keller, Mark Jeftovic <br>
Internet Service and Connectivity Providers constituency: Tony Harris, Maggie
Manonukia <br>
GNSO Council independent representative: Alick Wilson <br>
GNSO Council independent representative: Demi Getschko <br>
<br>
Non-voting Liaisons<br>
At-Large Advisory Committee (ALAC) liaisons: Thomas Roessler, Wendy Seltzer
<br>
<br>
(Note the At-Large Advisory Committee has the same status of the Government
Advisory Committee in the new ICANN structure and may report its findings and
recommendations directly to the ICANN Board, and in addition may appoint non-voting
liaisons to the GNSO Council. The role of Advisory Committees is described in
<a href="http://www.icann.org/general/bylaws.htm#Xl">Article XI of the new bylaws</a>
- and part 4 of section 2 describes the structure of ALAC in more detail) <br>
<br>
Government Advisory Committee Liaison: (non yet appointed to the Steering Group)
: </font></p>
<p><font face="Arial, Helvetica, sans-serif">Absent</font></p>
<p><font face="Arial, Helvetica, sans-serif">IP Constituency : Kiyoshi Tsuru</font>
<font face="Arial, Helvetica, sans-serif"><br>
Non Commercial Users Constituency: Milton Mueller</font></p>
<p><br>
<font face="Arial, Helvetica, sans-serif"><b>Item 1 Update on selection of chair</b><br>
Bruce Tonkin reported that during the meeting in Montreal several options were
suggested for the chair and Bruce contacted, Mike Roberts, Scott Bradner and
Paul Kane on behalf of the WHOIS Privacy Steering Group. Mike Roberts has indicated
that he is not available, and Paul Kane would accept the role if no one else
would but it was not his preference. No response from received from Scott Bradner.
Bruce Tonkin offered to act as non-voting chair, until another chair is selected
by the Steering Group<br>
<br>
<b>Items 2: Update on WHOIS policy coordination with other related groups in
ICANN (GAC, ASO, IAB, ALAC, etc) chaired by Paul Twomey. </b></font></p>
<p><font face="Arial, Helvetica, sans-serif">Re-iterating from: <a href="http://www.gnso.icann.org/mailing-lists/archives/whois-sc/msg00006.htm">http://www.gnso.icann.org/mailing-lists/archives/whois-sc/msg00006.html</a>
<br>
At the end of the WHOIS workshop in Montreal, Paul Twomey stated: <br>
<br>
<a href="http://www.icann.org/montreal/captioning-whois-25jun03.htm">From</a>:
<br>
"I am asking the chairs of the GNSO, the Governmental Advisory Committee, I'm
also asking the IAB Liaison if they will come together with me and help plot
out a program for joint meetings between their particular ongoing groups, the
GAC as a working group, there's a working group, a steering group in the GNSO,
if they'll come together and plot out a program of joint meetings with an aim
towards two things: a prioritization of issues to be addressed or issues that
need to be further explored, and a work program for the exploring of those issues
together, with the aim that that would be done intersessionally, but we would
have another report from that joint meeting framework in Carthage." <br>
<br>
Subsequently two informal teleconferences have been held with representatives
from GAC, RIRs, IETF to identify what issues raised in the WHOIS workshop are
appropriate for further analysis. The topics discussed included status of the
<a href="http://www.ietf.org/html.charters/crisp-charter.html">IETF CRISP</a>
work, documenting uses for each data element collected at the time of registration,
possibility of classifying types of registrants, and different approaches taken
by cctld operators. </font></p>
<p><font face="Arial, Helvetica, sans-serif">I expect that the next steps forward
at an ICANN staff level are probably to collate some of the data from the work
already done on WHOIS within the DNSO/GNSO, and also data presented at the Montreal
meeting to help provide factual data to guide policy development. The timing
of this work will probably be affected by ICANN staff resourcing. The work in
turn may result in issues reports, and then subsequently a formal policy development
process on some aspects. <br>
<b><br>
Item 3: Review the objectives and terms of reference for the WHOIS Privacy Steering
Group</b><br>
</font><font face="Arial, Helvetica, sans-serif">The WHOIS Steering Committee
was formed after the GNSO Council received the Staff Manager's report which
was not in a format to allow for a policy development process. The GNSO Council
decided to form a Steering group to examine the 20 issues mentioned in the Staff
Manager's report and identify which of the issues should be dealt with first
and decide on one or more task forces.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><a href="http://www.dnso.org/clubpublic/council/Arc13ch/msg00016.html">Re-iterating</a>
from: <br>
The objective of the steering group is to:<br>
- examine the Staff Manager's report on WHOIS Privacy <br>
- review the factual presentations of the ICANN public forum on WHOIS in Montreal
<br>
- develop recommendations, for the GNSO Council to approve, to form a small
number (e.g less than 5) of Task Forces to carry out the policy development
process on the major issues identified in the Staff manager's report (it should
be possible to group some of the related issues for examination within a single
task force)<br>
- the recommendations should incorporate for each task force a terms of reference
in accordance with the ICANN bylaws (Annex A, Section 7(b)): <br>
<br>
" Such Charter will include: <br>
<br>
1. the issue to be addressed by the task force, as such issue was articulated
for the vote before the Council that commenced the PDP;<br>
2. the specific timeline that the task force must adhere to, as set forth below,
unless the Board determines that there is a compelling reason to extend the
timeline; and <br>
3. any specific instructions from the Council for the task force, including
whether or not the task force should solicit the advice of outside advisors
on the issue." - if the steering group recommends more than two task forces
be created it should recommend to the GNSO Council an order in which the task
force work should be done, and an approximate timeframe for when each task force
will commence and finish Steering Group members might like to review the <a href="http://www.ietf.org/rfc/rfc2418.txt">IETF
standard RFC2418</a> on IETF Working Group Guidelines and Procedures. The standard
documents best practice within the IETF in forming working groups and defining
charters. Section 2.1 (criteria for forming a working group) and Section 2.2
(Charter) are particularly relevant. <br>
<br>
Thomas Roessler reported that the ALAC was looking at how the WHOIS would evolve
in general terms and timewise, the ALAC felt that it was continuous policy work.<br>
<br>
Bruce Tonkin noted that there should be an evolutionary approach in making improvements
to the contractual requirements for gtlds to better address privacy concerns,
rather than a sudden radical change.. <br>
As far as the WHOIS Steering Committee mandate is concerned, in the ICANN structure
the GNSO is only able to make recommendations on gTLDs that become binding on
Registrars and Registries. Some documents produced by the GNSO could be used
as "best practice" documents in other parts of ICANN. It was stressed
that the GNSO should focus on a few manageable tasks at a time.<br>
The difference was explained between representatives from constituencies, responsible
for policy recommendations, and liaisons who were responsible for bringing information
from work done within their policy development structure and taking back information
from the GNSO work to their fora. The hope was that by ensuring that all parts
of ICANN were well informed on the activities relating to WHOIS and Privacy,
that a workable balance could be achieved amongst the various stakeholder preferences.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Item 4: Review the objectives
and terms of reference in light of the <a href="http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm">Staff
Manager's report</a> . <br>
</b></font></p>
<p><font face="Arial, Helvetica, sans-serif">The Staff Manager's report drew a
distinction between WHOIS itself that is concerned with the display of data,
and the wider issues of privacy that relate to the entire domain name registration
and maintenance process, and include what data is collected from the registrant,
and how it is used, maintained, and made available to others. <b><br>
<br>
<a href="http://www.icann.org/gnso/issue-reports/whois-privacy-report-13may03.htm">Preliminary
Catalog of Issues</a><br>
Issues concerning data collection<br>
</b><br>
1. Should the elements of data that registrars are required to collect at the
time of registration of a domain name be revised? (See Registrar Accreditation
Agreement (RAA) § 3.2.) <br>
<br>
2. Should registrars be prohibited by ICANN from collecting additional items
of data? <br>
<br>
3. Should all registrants, or certain classes of registrants (see Issue 18 below),
be afforded the option of not providing some or all elements that registrars
are required to collect and, if so, which elements? <br>
<br>
4. Should the current mechanism for pseudonymous registration be changed or
supplemented with one or more alternative mechanisms? (See RAA § 3.7.7.3.) Should
steps be taken to encourage broader availability of this mechanism? <br>
<br>
5. Are the current requirements that registrars make disclosures to, and obtain
consent by, registrants concerning the uses of collected data adequate and appropriate?
(See RAA §§ 3.7.7.4 to 3.7.7.6.) <br>
<b><br>
<br>
Issues Concerning Data Quality </b><br>
<br>
<br>
6. Are the procedures currently followed by registrars adequate to promote accurate,
complete, and up-to-date data, as required by both privacy and accountability
principles? (See RAA §§ 3.7.7.1, 3.7.7.2, and 3.7.8, as well as the GNSO’s Whois
recommendations on accuracy adopted by the ICANN Board on 27 March 2003.) <br>
<br>
7. What should be the consequences when a registrant provides inaccurate or
incomplete data, or fails to correct inaccurate or incomplete data? (See RAA
§§ 3.7.7.1, 3.7.7.2, and 3.7.8.) Are safeguards needed to prevent abusive reports
of inaccuracies? Should certain classes of registrants (see Issue 18 below)
be permitted to provide inaccurate or incomplete data?<br>
<b><br>
<br>
Issues Concerning Data Handling </b><br>
<br>
<br>
8. Are the current requirements that registrars handle personal data according
to the notices given at the time of registration, and in a manner that avoids
loss, misuse, unauthorized access or disclosure, alteration, or destruction,
adequate and appropriate? (See RAA §§ 3.7.7.7 and 3.7.7.8.) <br>
<br>
9. Are the current requirements for handling of registrar data by registry operators
adequate and appropriate? <br>
<b><br>
<br>
Issues Concerning Data Disclosure </b><br>
<br>
<br>
10. Are the current means of query-based access appropriate? Should both web-based
access and port-43 access be required? (RAA § 3.3.1.) <br>
<br>
11. What are the purposes for providing public query-based access? Are the elements
currently required to be disclosed in public query-based access adequate and
appropriate? (RAA § 3.3.1.) <br>
<br>
12. What measures, if any, should registrars and registry operators be permitted
to take to limit data mining of Whois servers? <br>
<br>
13. Should access to data be differentiated based on the party receiving access,
or based on the use to which the data will be put? If so, how should differentiated
access be implemented and how should the cost of differentiation be funded?
<br>
<br>
14. Should the current requirement that registrars provide bulk Whois access
for non-marketing uses be further limited or eliminated? (RAA § 3.3.6, as well
as the GNSO’s Whois recommendations on accuracy adopted by the ICANN Board on
27 March 2003.) <br>
<b><br>
<br>
Issues Concerning Data Use </b><br>
<br>
<br>
15. Which uses of Whois data by members of the public should be permitted (e.g.,
resolving technical problems, sourcing spam, identifying online merchants, law
enforcement activities, identifying online infringers for enforcement of intellectual
property rights, etc.)? Which uses should be prohibited? <br>
<br>
16. How should restrictions on permissible uses by members of the public be
enforced? (RAA §§ 3.3.6.3 to 3.3.6.5.) <br>
<br>
17. To what extent is Whois data actually used to the harm of registrants (e.g.,
identity theft, spam, stalking, and other harassment)? <br>
<b><br>
<br>
Issues Concerning Classification of Registrants </b><br>
<br>
<br>
18. Should certain types of registrants (e.g., those using domains for political
and similar activities) be exempt from the usual requirements to provide data,
or to have it available in Whois? How should the eligibility of particular registrants
for these exemptions be determined? Are measures required to address the possibility
of abuses in the classification procedure? <br>
<b><br>
<br>
Issues Concerning Commercial Confidentiality and Rights in Data </b><br>
<br>
<br>
19. Should registrars have the option, independent of their customers, to protect
the confidentiality of Whois data based on registrars’ proprietary rights to
that data? Are the current provisions permitting registrars to claim proprietary
rights in personal data about their customers appropriate? (RAA § 3.5.) <br>
20. Should there be ICANN requirements limiting registrars' ability to sell
or use Whois data, or other data collected about customers, for commercial purposes?</font>
</p>
<p><font face="Arial, Helvetica, sans-serif"><br>
</font></p>
<p><b><font face="Arial, Helvetica, sans-serif">Bruce Tonkin reported on the Top
level Steering group commentary</font></b><font face="Arial, Helvetica, sans-serif">
as reported by the representatives of each group during the 2 teleconferences:</font></p>
<p><font face="Arial, Helvetica, sans-serif">1. Data collection: what is the actual/original
focus of the data?<br>
The ICANN staff charged with creating a table from the WHOIS workshop in Montreal
on data elements/data use</font></p>
<p><font face="Arial, Helvetica, sans-serif">2. Data quality - accuracy. Discussed
by the GNSO and in Montreal. This has been dealt with as a first step in the
reminder to registrar to ask registrants to provide accurate data. </font></p>
<p><font face="Arial, Helvetica, sans-serif">3. Data handling: not much discussion<br>
<br>
4. Data disclosure: Work is going on in Internet Engineering Task Force on new
protocol. John Klensin, the IETF liaison on the ICANN Board requested input
from the GNSO on the requirements of this protocol.</font></p>
<p><font face="Arial, Helvetica, sans-serif">5. Data use: not much discussion</font></p>
<p><font face="Arial, Helvetica, sans-serif">6. Classification of registrants:<br>
</font><font face="Arial, Helvetica, sans-serif">Individual and commercial users.
How does the registrar make the separation?<br>
It is possible that ICANN staff may assist in developinga discussion paper on
the various options.<br>
</font></p>
<p><font face="Arial, Helvetica, sans-serif">7. Different countries have taken
different approaches to the managementof privacy issues associated with domain
names within their related country code, and ICANN staff may assist in putting
together a table to compare the various approaches..<br>
<br>
<b>Alick Wilson</b> proposed:<br>
</font><font face="Arial, Helvetica, sans-serif">That there should be different
rules for disclosure and different rules for eligibility for the Registrant
and for the domain in which the Registrant registers the name.<br>
<br>
<b>Ken Stubbs </b>noted that there may be some variances to the handling of
data based on the purpose of the TLD. For example .name has some different requirements,
as it is primarily aimed at individuals. <b>Marilyn Cade</b> noted that a conscious
policy decision should be made on whether to attempt to establish some minimum
common standards amongst all gltds, or whether to treat each gtld differently.
<br>
<br>
<b>Item 5: Initial discussion on possible task forces<br>
<br>
</b>As the GNSO needs to prioritize its work program, Bruce Tonkin called for
input from each constituency of the GNSO to help select 5 top issues for further
consideration in one or more task forces.</font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Intellectual Property Interests
Constituency : </b></font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Steve Metalitz</b> reported that
issues 10, 12, 14, 20, and 5 were of most importance. In particular it should
be possible to makes some recommendations in the short term (related to issues
10,12) to deal with the present problems of data mining of registration data
using the IETF WHOIS protocol (which uses TCP port 43). He also noted that the
contractual requirements associated with the use of bulk WHOIS (related to issues
14,20) for marketing purposes were not being enforced, and it also appeared
that registrants were not properly informed about how the data collected at
registration would be accessed by the public (related to issue 5). </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>gTLD Registries Constituency:
</b></font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>David Maher</b> selected issues
18, 10, 3, 4, and noted that with regard to the .org registry that some registrants
were seeking anonymity (related to issues 3,4,18). <b>Ken Stubbs </b>added issues
12, 20 (related to issue 10), and also agreed with Steve Metalitz that issue
5 was a problem. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Non-commercial Users Constituency:
<br>
</b> </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Stephanie Perrin</b> noted that
the non-commercial users constituency was interested in the preservation of
anonymity (related to issues 3,4, 18), and if there was some distinction made
between data made available publicly and data provided to for example law enforcement,
that there was sufficient transparency to the user as to who had access to non-public
data (related to issues 5 and 15). An appropriate oversight mechanism would
be required for differentiated access. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Commercial and Business Users
Constituency </b><br>
<br>
<b>Marilyn Cade</b> noted that WHOIS data should not be used for marketing and
cited the need to control data mining related to issues 10 and 12. Marilyn also
stated that registrars should not use data collected for the purposes of domain
name registration for other commercial purposes related to issue 20. Finally
commercial and business users of domain names require accurate data (related
to issues 6 and 7). <br>
<br>
<b>Registrars Constituency <br>
</b><br>
<b>Tom Keller </b>noted that the main issue for registrars concerned the data
mining of registration data via the query based service provided by port 43
WHOIS (related to issues 10 and 12). In addition registrars were considering
whether differentiated access to data is feasible (related to issue 13). <b>Tom
</b>agreed with <b>Steve</b> and<b> Ken</b> that registrants need to be made
more aware of how the data collected at the time of registration would be made
available to others (issue 5). Tom also questioned whether all data elements
currently required in the contracts were necessary (e.g customers may be prepared
accept a poorer quality of service that results from providing only a limited
number of contact points e.g if only email, or only postal address was supplied).
<b>Mark Jeftovic</b> noted with respect to issue 7, that registrants needed
to accept some responsibility in return for being online. Mark also noted that
the impact of providing bulk WHOIS on registrants needed to be examined (issues
14, and 17). <br>
<br>
<b>Internet Service and Connectivity Providers Constituency </b><br>
<br>
<b>Tony Harris</b> selected issues 6, 7,10, 12, and 13. <b>Maggie Manonukia</b>
elaborated that data quality (issues 6,7) and limitations on data mining (issues
10,12) were the main issues for ISPs. Specifically accurate technical contact
information was very important (related to issues 1 and 6). <br>
<br>
<b>Issues under consideration within the At Large Advisory Committee</b> <b>Wendy
Seltz</b>er reported that the At Large Advisory Committee was reviewing WHOIS
from first principles and considering what data must be collected (related to
issues 1,2,3,4,5). There were concerns that if the present data collected was
restricted for public access, but with mechanisms for law enforcement access,
that registrants may not be aware of what uses their data would be put (ie this
would lead to a lack of transparency for individual users). Wendy reported that
some individual users desire anonymity (the ability to use a domain name without
supplying their name), and pseudonymity (the ability to provide a false name
or nickname when registering a domain name). In the absence of an accurate name,
if a domain name was being used for illegal purposes the action could be to
shutdown the operation of the domain name. <b>Thomas Roessler</b> added that
individual users should be able to choose how much contact information they
supplied at the time of registration, on the basis that an individual could
choose to experience a lower quality of service from a registrar that would
result from such limited information. <br>
<br>
<b>Advice from GNSO Council members <br>
</b><br>
<b>Demi Getschko</b> noted that in his personal opinion the most important issues
are 5,7 12, 14, 18, and 20. <br>
<br>
<b>Alick Wilson</b> recommended that each constituency review the data that
must be collected by registrars currently and identify which elements should
be mandatory and identify for each of these elements the consequences if the
data element was not available. Alick also suggested that ICANN review how countries
that are operating cctlds have handled WHOIS with respect to the privacy legislation
applicable in that country. <br>
<br>
<b>Alick</b> suggested that ICANN staff develop a data model for domain name
registration data. <br>
<br>
<b>Item 6: Next steps </b><br>
<br>
The GNSO Secretariat will prepare a draft table of the top 5 issues from each
GNSO Constituency based on the discussions above prior to the next meeting of
the Steering Group. Each Constituency should discuss amongst its members to
reach a consensus on the top 5 issues and report these to the GNSO Secretariat
to create a final version of the table. <br>
<br>
The GNSO Secretariat will prepare a table of the current data elements that
must be collected by registrars at the time of registration. Each constituency
should discuss amongst its members to reach a consensus on which data elements
should continue to be mandatory and identify the consequences if a mandatory
element was not available. <br>
<br>
The Steering Committee also requested that the chair (<b>Bruce Tonkin)</b> liaise
with the ccNSO through the ccNSO Liaison to the GNSO to seek a non-voting liaison
from the ccNSO on the steering group. Individual cctlds may be able to provide
their input on the table of data elements.<br>
<br>
Alick Wilson to provide further information on the requirements for a data model
for domain name registration data. <br>
<br>
Next teleconference to be scheduled by the Chair, with the objective of agreeing
on the top 5 issues, and beginning to see how the issues could be grouped in
one or more task forces. <br>
</font></p>
<p><font face="Arial, Helvetica, sans-serif"><br>
<b>Bruce Tonkin ended the call at 9:00 am Friday 8 August, Melbourne time, 24:00
UTC. </b></font></p>