ICANN/GNSO GNSO Email List Archives


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

[dow1-2tf] Whois task force 1/2 draft minutes teleconf 4 January 2005

  • To: "12DOW" <dow1-2tf@xxxxxxxxxxxxxx>
  • Subject: [dow1-2tf] Whois task force 1/2 draft minutes teleconf 4 January 2005
  • From: "GNSO SECRETARIAT" <gnso.secretariat@xxxxxxxxxxxxxx>
  • Date: Sun, 9 Jan 2005 12:34:31 +0100
  • Importance: Normal
  • Reply-to: <gnso.secretariat@xxxxxxxxxxxxxx>
  • Sender: owner-dow1-2tf@xxxxxxxxxxxxxx

Dear Task Force 1/2 Participants,

Please find the task force 1/2 draft minutes of the teleconference held on 4
January 2005 attached in htlm.

Thanks to the very complete notes taken by Barbara Roseman they have been
produced in a detailed version. If there is anything that you would like
changed, please let me know.

Thank you very much.
Kind regards


Glen de Saint Géry
GNSO Secretariat
<!--#set var="bartitle" value="WHOIS Task Forces 1 and 2 teleconference"-->
<!--#set var="pagetitle" value="WHOIS Task Force 1 and 2 teleconference"-->
<!--#set var="pagedate" value="4 January 2005" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Task Force 1 and 2 
<h4 align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Task 
  1 &amp; 2 <br>
  4 January, 2005 - Minutes</b></font></h4>
<p><b><font face="Arial, Helvetica, sans-serif">ATTENDEES:<br>
<p><b><font face="Arial, Helvetica, sans-serif">GNSO Constituency 
  </font></b><font face="Arial, Helvetica, sans-serif"><br>
  gTLD Registries constituency: - Jeff</font><b><font face="Arial, Helvetica, 
  </font></b><font face="Arial, Helvetica, sans-serif">Neuman</font><b><font 
face="Arial, Helvetica, sans-serif"> 
  - </font></b><font face="Arial, Helvetica, sans-serif">Co-Chair <br>
  gTLD Registries constituency - David Maher <br>
  Commercial and Business Users constituency - Marilyn Cade</font><b><font 
face="Arial, Helvetica, sans-serif"><br>
  </font></b><font face="Arial, Helvetica, sans-serif">Commercial and Business 
  Users constituency - David Fares</font><b><font face="Arial, Helvetica, 
  </font></b><font face="Arial, Helvetica, sans-serif">Registrars constituency 
  - Tom Keller <br>
  <font face="Arial, Helvetica, sans-serif">Registrars constituency - Paul 
  Intellectual Property Interests Constituency - Steve Metalitz <br>
  Intellectual Property Interests Constituency - Niklas Lagergren,<br>
  </font><font face="Arial, Helvetica, sans-serif"><br>
face="Arial, Helvetica, sans-serif"> 
  </font><font face="Arial, Helvetica, sans-serif">At-Large Advisory Committee 
  (ALAC) liaisons - Thomas Roessler </font></p>
<p><font face="Arial, Helvetica, sans-serif"><br>
  <b>ICANN Staff Manager</b>: Barbara Roseman</font> <font face="Arial, 
Helvetica, sans-serif"> 
  </font><font face="Arial, Helvetica, sans-serif"><br>
  </font><font face="Arial, Helvetica, sans-serif"><b>GNSO Secretariat:</b> 
  de Saint G&eacute;ry <br>
  <b>Absent:</b></font><font face="Arial, Helvetica, sans-serif"><br>
  </font><font face="Arial, Helvetica, sans-serif">Registrars constituency - 
  Buchanan - Co-Chair - apologies<br>
  </font><font face="Arial, Helvetica, sans-serif"><font face="Arial, 
Helvetica, sans-serif">Internet 
  Service and Connectivity Providers constituency: - Antonio 
</font></font><font face="Arial, Helvetica, sans-serif">Harris 
  - apologies<br>
  <font face="Arial, Helvetica, sans-serif">Registrars constituency -</font> 
  Ruiz <br>
  </font><font face="Arial, Helvetica, sans-serif">Nominating committee 
  - Amadeu Abril l Abril</font> <font face="Arial, Helvetica, 
sans-serif"></font><font face="Arial, Helvetica, sans-serif"><br>
  </font><font face="Arial, Helvetica, sans-serif">Intellectual Property 
  Constituency - Jeremy Banks</font><br>
  <font face="Arial, Helvetica, sans-serif">Non Commercial Users Constituency 
  - Marc Schneiders</font><font face="Arial, Helvetica, sans-serif"> </font> 
  <font face="Arial, Helvetica, sans-serif">Non Commercial Users Constituency 
  - Milton Mueller - apologies</font> <font face="Arial, Helvetica, 
sans-serif"></font><font face="Arial, Helvetica, sans-serif"> 
  Non Commercial Users Constituency - Kathy Kleiman</font><font face="Arial, 
Helvetica, sans-serif"><br>
  </font> <font face="Arial, Helvetica, sans-serif">Internet Service and 
  Providers constituency - Maggie Mansourkia</font><font face="Arial, 
Helvetica, sans-serif"> 
  </font><font face="Arial, Helvetica, sans-serif"></font> <font face="Arial, 
Helvetica, sans-serif"> 
  </font><font face="Arial, Helvetica, sans-serif"> </font><font face="Arial, 
Helvetica, sans-serif"></font> 
  <font face="Arial, Helvetica, sans-serif">At-Large Advisory Committee (ALAC) 
  liaisons - Wendy Seltzer</font> <br>
  <a href="http://gnso-audio.icann.org/WHOIS-20050104-tf12.mp3";><font 
face="Arial, Helvetica, sans-serif">MP3 
  <font face="Arial, Helvetica, sans-serif"><br>
  <b>Agenda </b></font></p>
<p><font face="Arial, Helvetica, sans-serif">1. Questions to send in advance to 
  the CRISP working group in preparartion for the call on Wednesday, 12 January 
  2005, at 11:00 am EST.<br>
  <b>Jeff Neuman</b> reported that he had sent an e-mail to ICANN staff, Paul 
  Verhoef, John Jeffrey, Kurt Pritz, Dan Halloran, Tina dam, Tim Cole 
  a call to discuss the <a 
  sent by staff</a> that was discussed on the last call, <a 
  December 2004</a>. The only response received was from Paul Verhoef stating 
  that he was not available untill 6 January 2005, but no response was given as 
  when would be good time to hold the discussion.<br>
  <b>Jeff Neuman</b> proposed sending out another email.<br>
  <b>Barbara Roseman</b> reported that she asked for senior staff to be on the 
  present call.<br>
  <b>Marilyn Cade</b> proposed that in the formal written request it should be 
  stated that the task force considered a call with the staff a priority and 
  work with staff to find another time if necessary, other than the regular 
  force call time. <br>
  <b>Jeff Neuman </b>proposed sending a formal written request, including 
  Cade's proposition, and adding that the discussion should take place as soon 
  as possible. </font></p>
<p><font face="Arial, Helvetica, sans-serif"><b>Glen </b>gave an update that 
  of the open call had gone out to Whois task force 1,2 &amp; 3, Council 
  the Constituency lists, the GAC. Quotes were being obtained from different 
  providers who would also be able to provide a transcript of the call and 
  services than the usual provider.</font><br>
  <font face="Arial, Helvetica, sans-serif"> <b>Jeff Neuman</b> commented that 
  he had written up some questions that he thought were relevant, but invited 
  other members to ask additional ones. First question: What's the status of 
  protocol, if not officially a standard, what steps need to be taken? <br>
  <b>Marilyn Cade</b>: Can we please start with What is it? <br>
  <b>Jeff Neuman</b>: Brief overview in layman's terms of what IRIS is,? Other 
  questions, general questions: Have there been any registrars or registries/ 
  resellers that have committed to adopting the protocol? What do they have to 
  do to adopt the protocol?<br>
  <b>Marilyn Cade</b>: How does the protocol relate to the distribution of 
  where there's a wholesaler model of resellers? <br>
  <b>Jeff Neuman</b>: do all registries/registrars/resellers have to adopt the 
  protocol for it to be effective? What if only some registrars or registries 
  in a given TLD adopt it? What happens to the model, does it break down? <br>
  <b>Marilyn Cade</b>:What does adoption of the protocol really mean, and fully 
  implement it? <br>
  <b>Jeff Neuman</b>: For example, it's one thing to adopt the IDN standard, 
  then resolution capabilities have to be built. One thing to adopt a standard, 
  what has to be built to support it from a software /hardware standpoint?<br>
  <b>Marilyn Cade</b>: can we ask if there's any additional burden on the 
  times? Given that this presupposes multiple dipping into the data base 
  to verify different elements of the information. <br>
  <b>Jeff Neuman</b>: For registry/registrar, will Registries have SLAs on 
  time, what effect if any, will there be on processing response time?<br>
  <b>Jeff Neuman</b>: Any other general questions? <br>
  <b>Marilyn Cade</b>: When they do the overview, they'll probably tell us 
  as I understand IRIS, the flexibility in the standard is there to gather all 
  the data and then decide which fields are displayed? <br>
  <b>Jeff Neuman</b>: Who gets to decide what is displayed? Who has control 
  what is displayed?<br>
  <b>Marilyn Cade</b>: Not my question, I would have assumed that the GNSO 
  come up with consistent policy on what's displayed, but what's the 
  that the standard provides of what is displayed versus what is gathered? Is 
  it element by element?<br>
  <b>Jeff Neuman</b>: I can answer that, it's element by element.<br>
  <b>Thomas Roessler</b>: You're both talking about something similar: Can a 
  be limited to certain data fields, can a response be limited to certain data 
  fields? Can you create sets of what can be displayed depending on the 
  <b>Jeff Neuman</b>: IRIS looks for the information regardless of whether it 
  comes f from a registry or a registrar. Provides a way to provide the data 
  the scene. For a thick registry does the IRIS protocol make any judgment 
  data is authoritative? Does it go to the registry or the registrar, and who 
  determines that? This is most important in thick whois tlds. <br>
  <b>Thomas Roessler</b>: It should be apparent whether the data is a referral. 
  <b>Jeff Neuman</b>: So the person getting the response knows where the data 
  is coming from. <br>
  <b>Thomas Roessler</b>: Is it possible to map how the data is retrieved<br>
  <b>Jeff Neuman</b>: Authenticating the requestor, or getting information 
  the requestor, is there a way to identify who the requestor is? Does IRIS 
  this, or is it silent on this, and can you implement IRIS to find out who the 
  requestor is and determine if they fit an access profile? Is there a way for 
  the whois provider to know who is doing the requesting? Or is IRIS extensible 
  so you can add different fields at implementation?<br>
  <b>Marilyn Cade</b>: What is the mechanism for operating different access 
  Can you block access to the "reserve data" until this information is filled 
  in? <br>
  <b>Jeff Neuman</b>: the other question on top of that, lets say it is not 
  to fill in those fields and the whois provider needs to cross check that 
  another data base of preauthenticated requestors will the protocol support 
  <b>Marilyn Cade</b>: So we should follow each of those, one scenario would be 
  that the data is gathered but not validated, the other is the data is 
  and validated<br>
  <b>Steve Metalitz</b>: another question about that authentication process , 
  whether that is that applicable to other functions besides whois data,? If 
  is an authentication function to this that determines whether or not you have 
  access to certain data can that authenitcation function be used for other 
  as well, such as registration? <br>
  <b> Thomas Roessler</b>: We should pay a little attention to the difference 
  between authorization and authenitcation. What we would have with the two 
  approach is in the first place authorization, that would be mostly focused on 
  authentication making sure that the information provided during the 
  is information that comes from the sender. Not sure what way to go about 
  </font><font face="Arial, Helvetica, sans-serif"><b>Jeff Neuman</b>: we 
  go down both ways of authorizing access, some people argue that to prevent 
  mining is to basically be sure that the certificate provided by the 
  some believe that only authorized or pre-authenticated should able to get the 
  information. We should ask if IRIS will support either or both. <br>
  <b>Thomas Roessler</b>: What can be implemented with this specific protocol, 
  when we are asking what kind of authorization models it supports, that might 
  be independent from how to authenticate information submitted during the 
  stage. <br>
  <b>Jeff Neuman</b>: We should be clear about whether we're asking about 
  or authorization. In task force 1 they talked about the possibility of 
  access for law enforcement for example, so we should ask whether there's a 
  to do that?<br>
  <b>Marilyn Cade</b>: Is there support for a special class of access that is 
  "anonymous access" For instance, for law enforcement<br>
  <b>Thomas Roessler</b>: what do we mean by anonymous access<br>
  <b>Marilyn Cade</b>: If you were in an environment where you were going to 
  the details of the person who asked for the data you would not want to 
  those details, example, xxxx Child Protection Services.</font><font 
face="Arial, Helvetica, sans-serif"><br>
  <b>Thomas Roessler</b> : Concealing the identity of certain requestors from 
  the registry/registrar? <br>
  <b>Jeff Neuman</b>: is it possible to conceal the identity of certain 
  from everyone or concealing it partial? <br>
  <b>Steve Metalitz</b>: Does the protocol address what record is 
  for each transaction, and if so could the protocol support limiting the uses 
  of those records? 2 Examples:<br>
  1. Know who has made what queries about whois data might be valuable 
  for marketing purposes. Would there be a way to prevent that use?<br>
  2. Is a record created and is it preserved in a way that law enforcement 
  have access</font><font face="Arial, Helvetica, sans-serif"><br>
  <b>Paul Stahura</b>: Do you mean the record of who looked up the whois 
  <b>Steve Metalitz</b>: Yes, we discussed one model in which that record would 
  exist and if there were some evidence of abuse then law enforcement or 
  else could have access to that record under certain circumstances. One of the 
  models discussed in tiered access was that the record would be created and 
  and would be accessible under some circumstances. How would that fit into the 
  protocol?</font><font face="Arial, Helvetica, sans-serif"><br>
  <b>Paul Stahura</b>: The requestor looks up the information, does the 
  provide a way to track what happens to that information ,like whether it is 
  stored or given out, has it a certain life time and disappears after a while? 
  Once the requestor looks up the data, can we track how its used? If there are 
  restrictions on how to use the data, can we check up on that? <br>
  </font><font face="Arial, Helvetica, sans-serif"><b>Jeff Neuman</b>: we can 
  ask them, but probably the answer will be no, there is nothing built in 
  <b>Paul Stahura</b>: Is there something like the Time to Live of dns, then 
  data has to be asked for again? Otherwise we are going to have requestors and 
  no matter how much checking we do with the identity of people etc the 
  will be able to be used over again.<br>
  <b>Jeff Neuman</b>: We can ask but feels that the answer will be that it is 
  a policy determination<br>
  <b>Paul Stahura</b>:If we can up with a policy that it information could 
  for a day, does the protocol help us with the implementation of that 
  <b>Jeff Neuman</b>: Okay, we have about 18 questions now. If you have other 
  questions, please send them around. I'll put up this list to the group, 
  correct any of your questions that I might have misstated. We'll send these 
  questions to the presenters on Thursday. <br>
  <b>Jeff Neuman</b>: I'll send a second request to Staff to get a date to 
  their response to our recommendations on national privacy policy. Didn't get 
  a response to the first request. <br>
  <b>Any Other Business</b>:<br>
  Constituency statements on <a 
  1</a> due on 31 January 2005.<br>
  The <b>registrar constituency</b> reported that they could probably only 
  feedback that was not officially voted on by the constituency for that 
<p><b><font face="Arial, Helvetica, sans-serif">Thanks to Barbara Roseman's 
  these minutes are so detailed.</font></b><font face="Arial, Helvetica, 
  </font><font face="Arial, Helvetica, sans-serif"> </font></p>
<h1><font face="Arial, Helvetica, sans-serif"><b><font size="3">Jeff Neuman 
  everyone for their presence and participation and proposed sending the 
  to the CRISP .<br>
  Next Regular Task Force Call:18</font></b><font size="3"><b>January 2005<br>
  see: </b><a href="http://gnso.icann.org/calendar/";>GNSO calendar</a><b><br>
  </b> <b><br>
  Questions submitted by Jeff Neuman and revised by Steve Metalitz ( in italics 
  )after the call.<br>
  I. General Questions <br>
  A. Brief overview in laymen's terms of what IRIS is? <br>
  B. What is the status of the IRIS Protocol? <br>
  C. What steps still need to be taken to make it a standard? <br>
  D. What does it mean to adopt the standard and fully implement it? What needs 
  to be built to support it from a software/hardware or otherwise standpoint? 
  E. Have there been any registries / registrars that have committed to 
  the protocol? <br>
  F. What are the obstacles/burdens on registries / registrars / resellers in 
  incorporating the protocol into their systems? <br>
  G. Do all Registrars and all registries have to adopt the protocol in order 
  for it to be effective (i.e., what would the result of some registries and 
  registrars incorporating the IRIS protocol, but not others?).<br>
  H. What is the possible effect on response time for Whois queries? Would this 
  affect a Registry's SLAs?<br>
  II. Specific Questions <br>
  A. Who has control over what is displayed for a particular TLD? In other 
  who defines which is the authoritative server for each TLD. For example, in 
  this registries, it is clear that the registrar is the authoritative server, 
  but for thick registries, does the IRIS protocol return query results from 
  registry? <i><br>
  Are there other differences between the implementation of the protocol in 
  and thin registries?</i><br>
  B. Who is responsible for defining the level of access that is given to a 
  of information? Is it the Whois Provider? <br>
  C. When there is a response returned, does the Requestor know where the 
  came from (i.e., the registry or registrar that returned the response)? <i>Is 
  &quot;referral data&quot; identified as such?</i><br>
  D. Are there ways in which IRIS would allow the Whois Provider to collect 
  about the Requestor? <br>
  a. Does the protocol address what record is made and is stored for a 
  i. In other words, does the protocol records where the request comes from, 
  time the query was made, what response was given, etc.? <br>
  ii. If so, where is that records stored (i.e., who has access to that 
  iii. Who has access to that record and is there any limit on the use of that 
  record? <br>
  b. Is IRIS extensible? In other words, can the party implementing the 
  collect other fields of information from the Requestor (i.e., contact 
  so that the Whois Provider knows who is requesting the specific data? <br>
  c. Is there a mechanism that one could use to authenticate the data provided 
  by the requestor,<i> or to consult a list of pre-approved</i> 
  before the requestor is given a response to its query? If so, what can be 
  d. If there is such a mechanism, would there be a way to create an exception 
  to allow anonymous access for certain law enforcement agencies or other 
  entities? <br>
  E. Is there anything in or through the protocol that is able to track or 
  the use made of the data retrieved? In other words, if the Requestor obtains 
  information from its Whois search, is there a way to track what the Requestor 
  does with that data or is there a way to have that data expire? <br>
  F. Is the authentication used in IRIS applicable to other things other than 
  WHOIS? For example, can that same mechanism be used to authenticate domain 
  registrants when they apply for a domain name?<br>

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