[council] WHOIS Steering Committee: select 5 top issues

["GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx>]

[To: council@xxxxxxxx]
[To: liaison6c@xxxxxxxx]
[To: whois-sc@xxxxxxxx]

Whois Steering committee, teleconference  August 7/8, 2003

At the Whois Steering committee, teleconference  August 7/8, 2003, the
Acting Chair, Bruce Tonkin noted that as the GNSO needs to prioritize its
work program, each constituency should formally review the draft table
attached and after discussion amongst the members please provide  input to
help select 5 top issues for further consideration in one or more task
forces.
Where two representatives from the same constituency had slightly differing
priorities during the teleconference, the table reflects a best estimate of
the combined position, subject to the constituency finalising their top 5.


Item 6
Next Steps:
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.

(see full minutes attached below)

Kindly provide me with your input no later than Thursday, September 4, 2003,
at COB.

Thank you very much.

GNSO Secretariat
gnso.secretariat@xxxxxxxxxxxxxx

<!--#set var="bartitle" value="WHOIS Privacy Issue table"-->
<!--#set var="pagetitle" value="WHOIS Privacy Issue table"-->
<!--#set var="14 August 2003" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Privacy Issue table'"-->
<p align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Privacy 
Issue 
  Table, August 14</b></font></p>
<table width="75%" border="1" cellspacing="1" cellpadding="4">
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">ISSUE</font></td>
    <td><font face="Arial, Helvetica, sans-serif">Business users</font></td>
    <td><font face="Arial, Helvetica, sans-serif">gTLD registries</font></td>
    <td><font face="Arial, Helvetica, sans-serif">Internet Service 
providers</font></td>
    <td><font face="Arial, Helvetica, sans-serif">Non Commercial 
users</font></td>
    <td><font face="Arial, Helvetica, sans-serif">Registrars</font></td>
    <td><font face="Arial, Helvetica, sans-serif">Intellectual Property 
Interests</font></td>
    <td><font face="Arial, Helvetica, sans-serif">TOTAL</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) 
      </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">2. Should registrars be 
prohibited 
      by ICANN from collecting additional items of data? </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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? </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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?</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">4</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.)</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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? </font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td height="155"><font face="Arial, Helvetica, sans-serif">9. Are the 
current 
      requirements for handling of registrar data by registry operators 
adequate 
      and appropriate? </font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
    <td height="155"><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">5</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.)</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">12. What measures, if any, 
should 
      registrars and registry operators be permitted to take to limit data 
mining 
      of Whois servers? </font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">5</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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? 
</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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? </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">16. How should restrictions 
      on permissible uses by members of the public be enforced? (RAA §§ 3.3.6.3 
      to 3.3.6.5.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">17. To what extent is Whois 
      data actually used to the harm of registrants (e.g., identity theft, 
spam, 
      stalking, and other harassment)? </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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? </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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.) </font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
  </tr>
  <tr> 
    <td><font face="Arial, Helvetica, sans-serif">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></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif"></font></td>
    <td><font face="Arial, Helvetica, sans-serif">1</font></td>
    <td><font face="Arial, Helvetica, sans-serif">2</font></td>
  </tr>
  <tr> 
    <td height="67"><font face="Arial, Helvetica, sans-serif">TOTAL</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">5</font></td>
    <td height="67"><font face="Arial, Helvetica, sans-serif">30</font></td>
  </tr>
</table>
<p align="center">&nbsp;</p>

<!--#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 &quot;best practice&quot; 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>