[dow1-2tf] WHOIS TF 1/2 Open Call CRISP Transcription 12 January 2005

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

To: dow1-2tf[at]gnso.icann.org]

Please find the transcription of the Whois task force 1 & 2 CRISP open call
held on January 12, 2005 at 11:00 EST 16:00 UTC.

I do apologise for the previous postings where the document was not attached
and then attached in a form that cannot be opened.

If you would like any changes made, please let me know. I have tried to
clean up the transcript, but may have overlooked some things.
The document will be posted on the GNSO website for reference:
http://gnso.icann.org/issues/whois-privacy/index.shtml

Thank you very much.
Kind regards,

Glen de Saint Géry
GNSO Secretariat

<!--#set var="bartitle" value="WHOIS Task Forces 1 and 2 CRISP transcription"-->
<!--#set var="pagetitle" value="WHOIS Task Force 1 and 2 CRISP transcription"-->
<!--#set var="pagedate" value="12 January 2005" value=""-->
<!--#set var="bgcell" value="#ffffff"-->
<!--#include virtual="/header.shtml"-->
<!--#exec cmd="/usr/bin/perl /etc/gnso/menu.pl 'WHOIS Task Forces 1 and 2 CRISP 
Transcription'"-->
<p align="center"><font face="Arial, Helvetica, sans-serif"><b>WHOIS Task 
Forces 
  1 and 2 Teleconference <br>
  CRISP Presentation<br>
  12 January, 2005 - Transcription</b></font></p>
<p><b><font face="Arial, Helvetica, sans-serif">ATTENDEES:<br>
  </font></b></p>
<p><b><font face="Arial, Helvetica, sans-serif">GNSO Constituency 
representatives:<br>
  </font></b><font face="Arial, Helvetica, sans-serif"> gTLD Registries 
constituency: 
  - Jeff</font><b><font face="Arial, Helvetica, sans-serif"> </font></b><font 
face="Arial, Helvetica, sans-serif">Neuman</font><font face="Arial, Helvetica, 
sans-serif">- 
  Co-Chair </font><b><font face="Arial, Helvetica, sans-serif"> <br>
  </font></b><font face="Arial, Helvetica, sans-serif">Registrars constituency 
  - Paul Stahura </font><b><font face="Arial, Helvetica, sans-serif"><br>
  </font></b><font face="Arial, Helvetica, sans-serif">gTLD Registries 
constituency 
  - David Maher </font><b><font face="Arial, Helvetica, sans-serif"><br>
  </font></b><font face="Arial, Helvetica, sans-serif">Commercial and Business 
  Users constituency - Marilyn Cade<br>
  Intellectual Property Interests Constituency - Steve Metalitz <br>
  Intellectual Property Interests Constituency - Niklas Lagergren,<br>
  <font face="Arial, Helvetica, sans-serif"> </font>Non Commercial Users 
Constituency 
  - Milton Mueller </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"> 
  <br>
  <br>
  <br>
  <b>Liaisons:</b><br>
  At-Large Advisory Committee (ALAC) liaisons - Thomas Roessler<br>
  <font face="Arial, Helvetica, sans-serif">Suzanne Sene - <font face="Arial, 
Helvetica, sans-serif">Govenment 
  Advisory Committee</font></font><br>
  <br>
  <b>ICANN Staff Manager</b>: Barbara Roseman</font> <font face="Arial, 
Helvetica, sans-serif"><br>
  <b>GNSO Secretariat:</b> Glen de Saint G&eacute;ry <br>
  <br>
  <b>Visitors<br>
  </b>Bruce Beckwith<br>
  Phil Colebrook - gTLD Registries constituency - GNSO Council<br>
  Ken Stubbs - gTLD Registries constituency - GNSO Council<br>
  Tim Cole - Registrar Liaison ICANN<br>
  Chuck Gomes - Verisign<br>
  Maureen Cubbereley - GNSO Council Nominating Committee<br>
  Ryan Lehning<br>
  Tina Dam - gTLD Registries constituency Liaison ICANN<br>
  Tony Holmes - <font face="Arial, Helvetica, sans-serif">Internet Service and 
  Connectivity Providers constituency - GNSO Council<br>
  Greg Ruth - <font face="Arial, Helvetica, sans-serif">Internet Service and 
Connectivity 
  Providers constituency - GNSO Counci</font><br>
  Hanan Has - Govenment Advisory Committee<br>
  <font face="Arial, Helvetica, sans-serif">Robin Gross - Non Commercial Users 
  Constituency - GNSO Council<br>
  Ed Lewis<br>
  Mickey Mouse<br>
  Marcus Heyder<br>
  Cherian Mathai</font></font></font> - <font face="Arial, Helvetica, 
sans-serif">Tralliance</font><br>
  <font face="Arial, Helvetica, sans-serif">Ron Andruff - Tralliance<br>
  Rick Anderson - zip.ca</font></p>
<p><font face="Arial, Helvetica, sans-serif"><font face="Arial, Helvetica, 
sans-serif"></font></font><font face="Arial, Helvetica, sans-serif"><a 
href="http://gnso-audio.icann.org/WHOIS-20050112.tf12.mp3";>MP3 
  Recording</a></font><br>
  <font face="Arial, Helvetica, sans-serif"><a 
href="http://www.gnso.icann.org/issues/whois-privacy/sanz-whois-12jan05.pdf";>CRISP
 
  Presentation</a></font> </p>
<p></p>
<p><font face="Arial, Helvetica, sans-serif"><br>
  Coordinator All participants are on a listen-only mode. After the 
presentation, 
  we'll conduct a questions and answer session. Today's conference is being 
recorded. 
  If you have objections, you may disconnect at this time. I'll turn the 
meeting 
  over to Mr. Jeff Neuman</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman <br>
  I want to welcome everyone to the WhoisTask Force One and Two conference on 
  the CRISP working group and, more specifically, the IRISh protocol that has 
  made it to RFC status. We'll wait a couple minutes to make sure everyone is 
  one. We'll have a presentation by Andrew Newton, Leslie Daigle and Marcos 
Sanz 
  also helped put the presentation together. We'll follow with a question and 
  answer period.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> For those not on WhoisTask Force 
  One or Two, we submitted to Andrew and Leslie a list of questions that the 
task 
  force came up with. It was merely meant as a guideline to let them know what 
  types of topics we were interested in so they could prepare their 
presentation. 
  But my no means is it an exhaustive list of all the questions we had. I'm 
sure 
  there will be other questions from other people on the call. Is Andrew Newton 
  on the call? Or Leslie Daigle?</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator No, not at the 
moment.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman Is Marcos on the 
call?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz :Yes.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Since they're not on 
the 
  call yet, are you prepared to go through the presentation until they can 
join?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: I haven't prepared very 
  well, so wait one minute and I'm sure they'll appear. If in one minute 
they're 
  not here, I'll start.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman<br>
  Okay, let's take that minute. We have about 22 people on the call right now. 
  Marcos, did you want to just go into a bit about the CRISP working group and 
  background? Do you have the presentation?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz:<br>
  Yes, I have it. No problem, I'll start with that.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> It was a long time ago that we 
founded 
  this CRISP working group, more than two years by now. CRISP is an information 
  service, and one of the main goals was, to be clear, what we wanted to 
design. 
  It had to be a solution for all the problems that currently infested the 
nickname 
  or Whois is very old, more than 20 years. By the time it was designed, the 
standards 
  of the IETF for protocols were not as high as today. So the protocol is very 
  weak. There are no security considerations, no there are no international 
considerations. 
  This was identified as a problem &#133; had to be addressed and this is the 
  reason the working group was created.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: I think we have Andrew 
  now, Marcos.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: Great.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton : Leslie is here, too. 
  We were on but you couldn't hear us apparently.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Marcos filled in the 
background 
  of the group, if you'd continue on.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  Sure. I'm going to go through the slide deck that was distributed, and you 
guys 
  can interrupt at any point and ask questions. The questions provided to us 
are 
  answered in the slide deck, just not in the same chronological order they 
were 
  at. You might want to be patient with that. But we'll answer all the 
questions-interrupt 
  at any time.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: The way the call is set 
  up is you do the presentation and then we'll take questions because there are 
  25 or 30 people on the call.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  Okay. Page two, the background slide, IETF chartered the CRISP working group 
  in order to create a new protocol to replace the nickname Whois protocol. The 
  CRISP working group first, instead of just trying to run off to 
implementation 
  of protocol, we actually a list of requirements that we thought protocol 
should 
  have. Then we had two candidates proposals submitted to the working group. 
Then 
  the group took consensus on which protocol we felt best met the requirements 
  we set out.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> At the end of the day, IRIS was 
  selected as the protocol. There was a second based on LDEP called &#133; but 
  the working group felt that IRIS &#133; candidate came down to ease of 
implementation. 
  IRIS is now a proposed IETF standard, RFC's 3981, 3982 and 3983.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> IRIS is a very flexible 
information 
  access protocol that you can layer multiple registries on top on. The CRISP 
  has worked on two registry types called D reg and A reg, D for domain and A 
  for addresses. The D reg registry type handles thick and thin registries and 
  domain registrars, and the A reg handles what's called the Number Resource 
Registries, 
  RIRs. I should not that, before CRISP came around, in the space, the RIRs and 
  the domain registries and registrars are actually on completely divergent 
tasks 
  as far as Whois and how they were beginning to handle Who Is. Each set of 
constituencies 
  was placing different controls and things on top of the nick name Whois 
protocol 
  in order to meet certain requirements, and they were not compatible with each 
  other. CRISP actually is in alignment to try to bring these two back into the 
  same camp and allow one client to act as both sets of data.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> There is other work going on with 
  IRIS outside of CRISP. There is E-reg, which is essentially an ENUM registry 
  for IRIS, which is now a working group item of the ENUM working group within 
  the IETF.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> In addition, there is new work 
beginning 
  in IETF about emergency context resolutions. Essentially, that is how do you 
  discover which emergency response center do you send emergency messages to, 
  based on geographic location. IRIS is being set up as a proposed candidate 
for 
  that problem. There is other work going on the NGN space as well. In order to 
  have a lot of convergent network technology coming together, they need meta 
  data access protocols for that.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page four. What's the value of 
IRIS? 
  It's decentralized by design. It doesn't mean you can't do centralization. It 
  actually takes decentralization into its core essence. This is done because 
  the feedback we got when we went around asking people what they wanted and in 
  the CRISP working group itself, the registrar is really, from what we heard, 
  waned to keep the data in their own server, they didn't want to send it out 
  to a centralized spot.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> That also helps in the management 
  of the data because anytime you data being centralized, there are all sorts 
  of accuracy issues that suddenly arise that you never had before. So with 
decentralization, 
  we actually have navigation built in, we try to use DNS hierarchies where 
possible. 
  The point of doing this is so you don't have to set up a well known server 
which 
  can be a single point of failure in the system, and typically a political hot 
  button when you do that. It's also a request many people had.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> So we allowed TLDs to put NAPTR 
  and SRV pointing to their own servers. So when you do a query, you know that 
  if I'm looking for something in dot-net, you go look up the NAPTR SRV records 
  in the dot-net zone, it points to the dot-net IRIS server.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The protocol also contains NC 
references 
  and search continuations. These are ways for a server to point to other data 
  in other servers. Where an NC reference is an explicit knowledge reference 
saying 
  I know this entity exists in this server, versus a search continuation which 
  says I think this data is over here or possibly over here, but continue your 
  search there. When it comes to creating a client, those are two very 
important 
  distinctions that have to be made.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The protocol also uses a thing 
called 
  saffel for &#133; authentication mechanisms, and that allows us to do one 
time 
  passwords or certificates or plain password or whatever. It allows greater 
flexibility 
  and how you do access. Finally, the protocol is structured to allow us to do 
  internationalization and IDN support more easily than without. We do that 
using 
  XML.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Slide five. What's the cost? 
First 
  off, IRIS is an open standard, published by the IETF as we said. There is no 
  intellectual property attached to the actual protocol itself. You don't have 
  to pay royalties to anybody to go implement it. And there is no specific 
implementation 
  necessary because it's an open standard. So anyone is free to come up with 
their 
  own implementation of the protocol as they see fit for their needs. I'll 
point 
  out there are some open source clients &#133; already available.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> If you wanted to implement this 
  on your own, the protocol was specifically designed to reuse common building 
  blocks. We use XML for doing the structure and tagging of data. XML is a very 
  well known serialization format on the Internet. We use &#133; and SRV 
resource 
  records for finding a navigation of data, and also use things like saffel for 
  common access control mechanisms.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> As for the database, IRIS system 
  is designed to sit on top of a current registration database. The intent 
isn't 
  to have the database be changed in any way in order to accommodate the 
protocol 
  itself. So there are no database changes at all; it's basically another 
protocol 
  engine that sits on top of the database to get access to it.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> We find that very important 
because 
  the moment you start requiring changes in anyone's registration database, 
that 
  means they require changes in their business process and that can get 
expensive 
  really fast. So IRIS doesn't impose any matrices or tree structures or 
anything 
  that requires back end data changes.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Slide six. The CRISP status so 
far 
  is the CRISP working group has met all the original milestones to create the 
  requirements document and the core and main registry protocols. Currently, 
the 
  working group is working on the address registry. I expect that to go to the 
  last call very soon. Recently, we're undertaken new work on this IRIS over 
UDP, 
  which is to make it really fast, and something called V-check with is a 
lightweight 
  domain availability check. That will also probably be the last called pretty 
  soon.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page seven. There is other work 
  going on as well. There has previously been work on putting SRV records into 
  the zone files of TLDs, so that the Whois client can find the Whois more 
easily. 
  We're actually working on a cohabitation document which discusses how clients 
  can use that information to find Whois servers and define IRIS servers. So 
essentially, 
  one client could access both Whois data and IRIS data at the same time 
because 
  there is no flag date for transitioning. It will be an eventual, gradual 
transition.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page eight. The current 
deployments 
  that I know about, for com and net, we actually do have a server up and 
running, 
  and this year we plan on adding the UDP support once that gets finalized. In 
  2005, DeNIC is going to stand up the server, and well as NOMINET and RIPE NCC 
  is looking at standing up the server as well. I want to point out that with 
  CEUK com and net, it represents well over 60% of all registered 
domains.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page nine. Navigation of servers 
  and data, I talked of this briefly. The way IRIS determines-one of the 
methods-to 
  use DNS hierarchies is we allow zone operators to put NAPTR and SRV records 
  in their zone. At that point, IRIS using that data to find the correct server 
  to go talk to. This avoids the concept of what's known as a well known server 
  to the purposes of finding the data, which typically is a political hot 
button 
  in some circles.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> There are other methods of 
navigation 
  of the data. IRIS has a pluggable architecture for doing that, so you can add 
  other things, resolution methods. Specific to domains, there is a top-down 
and 
  bottom-up resolution method where if you were looking, for example, at 
dot-net, 
  we would start looking in the zone file like dot-net to see where the server 
  is. If you didn't find it, you go to dot-net.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> For navigation, the protocol also 
  has query distribution energy references and search continuations. NC 
reference 
  is saying go look here for this data where search continuation is. We'll 
continue 
  your search at this server. This allows registries to point to the same data 
  in the registrar. So com may point to the example dot-com in the registrars 
  database. Registrars can &#133;there is a function for the registrant to 
point 
  to stand up servers. There is a pluggable architecture. You can add new 
navigation 
  methods, if needed.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page ten, tiered access. IRIS has 
  multiple authentication mechanisms. Authentication is what allows you to do 
  tiered access, especially strong authentication. So in tiered access, who 
controls 
  what data is actually given back to the client, is done by the server. But 
the 
  authentication allows the server to determine what type of data the user gets 
  back. You can actually have multiple tiers, it's not just anonymous. You can 
  have many tiers depending on what the policy dictates.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> You can also coordinate how this 
  is done. There's a note that you can do this in band; there are mechanisms 
within 
  the IRIS protocol itself to allow servers to coordinate policy and 
authentication. 
  It can be done out of band with some other mechanism or both ways with a 
combination.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> I put an example at the bottom of 
  the slide. Basically, you have someone accessing an IRIS server looking for 
  Mark Costers or Costers.net and they get nothing or they get the fact that 
they 
  know his name and what country he is in. But if they provide the correct 
authentication 
  or credentials, they get the full contact information.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle &#133; that full contact 
  information is provided in today's Whois server. Andy actually thought that 
  of the Whoisdata, and there aren't any options in today's Whois server to do 
  anything other than display all.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton<br>
  </font><font face="Arial, Helvetica, sans-serif">Page 11, authentication 
distribution. 
  One of the challenges with tiered access is how you know the right user is 
accessing 
  the right information without overburdening the servers providing that 
information. 
  So IRIS actually has a couple mechanisms within it to make that border far 
less 
  that with typical distributions lists. It doesn't mean you can't do it, the 
  old ways are still there and possible. There are other methods; one is 
digital 
  certificates. You may not understand, when a client accesses a server data, 
  the server looks at the digital certificate and says, I don't know who this 
  is but I know who gave them this cert and based on that information, I can 
give 
  them a level of access to the data. Or the actually certificate since the 
data 
  inside the certificate is signed, they know it's maybe law enforcements, 
fellow 
  registrar They would then give them appropriate access. That's actually 
standard 
  digital certificate technology. IRIS didn't invent any of that.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> There is a thing in IRIS called 
  relay bag, and what that allows you to do is it allows a server to relay via 
  the client some authentic data to a reference server so access can be 
controlled 
  at that level, if necessary, where the first server may not have the data, 
but 
  it refers on to the next server. But it is able to authenticate the user and 
  pass that authentication credential on to the reference server.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The server also has another 
extensibility 
  control, we call them controls, in the protocol themselves. It's just another 
  mechanism that allows the client to hand the server some extensible piece of 
  data the server uses to act upon a request. As an example, when we 
implemented 
  the IRIS server for com and net, one thing we wanted was we didn't want the 
  speed bumping or rate limitations from the Web server to be adversely 
effected. 
  The Web server was actually talking directly to the IRIS server. So when the 
  Web server makes a request to the IRIS server, it hands it a control that 
says, 
  &quot;Here's the requesting IP address of the person coming to me,&quot; 
therefore 
  the specific IP address cannot get more data via the Web or IRIS server if 
they 
  wanted. They couldn't take out the system, in other words.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page 12: Again, the IRIS server 
  is policy neutral. The protocol actually doesn't speak the policy, and that 
  was one of the mantras of the CRISP working group, which is about creating an 
  access protocol that didn't require any policy to be made within the protocol 
  itself. So all sorts of information can be given back in the protocol, or it 
  can not be given back, or the server can actually tell the client, &quot;I 
have 
  this data but I can't give it to you. In addition, there are other privacy 
mechanisms 
  in there where the server can say, &quot;This specific data is sensitive and 
  you are not allowed to redistribute it. Things like that.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The information within IRIS can 
  be centralized in one central IRIS server. It's a typically easy thing to do. 
  The service was designed for decentralization so you can have it distributed. 
  Or it can be centrally indexed and then distributed, so you could have an 
index 
  server that has an index of the data but not the actual data itself, but 
points 
  to the place that does. This is all a matter of policy. The protocol itself 
  is policy neutral. This give policy makers a lot more options in order to 
make 
  policy for the situations they're determining. </font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page 13. The protocol is well 
structured. 
  It allows you better server performance because in many cases &#133; 
sometimes 
  the client doesn't have a lot of knowledge about what the request is, so the 
  servers have to guess at the request in many cases, not all. What the 
structure 
  does and what &#133; queries is it allows the client to be very formal about 
  what it's requesting. Therefore, this is not only ambiguity on the client 
side, 
  but the server then doesn't have to go hunting through multiple database 
indexes 
  to find the data; it knows exactly what the client is requesting.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Provides structure, normalized 
data, 
  this does two things. It enables localization of the internationalized 
protocol 
  elements, and I'll show you an example in a minute. It also provides for 
richer 
  client presentation, so the client no longer has to be very similar to only 
  text out, but we have a graphable user interface that we've developed here. 
  But if it wanted to also be in Brail, whatever the end user needs &#133; we 
  can do that.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The relationship to the query is 
  clearly noted. Because all the data is normalized, each entity is well tagged 
  in what the entity is. The relationship is clearly noted, and the 
relationship 
  to whether it's a direct answer to the query or some sort of ancillary data 
  is also noted in the protocol.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> When you combine the well 
structured 
  data of the queries and responses with strong authentication, this enables 
you 
  to have very good audit trails, if the implementer wants to do that. The 
other 
  side effect is, because the data is highly normalized and the queries are 
well 
  known, these audit trails can be meaningful to third parties, if 
necessary.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Page 14. We talk about structure 
  and internationalization, the way this works is what the content of the data 
  is under the control of the server. So the server dictates whether to hand 
back 
  the address or not, or the postal code of the user or whatever the 
information 
  is. The actual presentation of the data, though, can be determined by the 
client. 
  This allows for localization of tags within the protocol itself. So we have 
  here a picture of our graphical user clients. You'll notice a lot of the 
menus 
  and other things are not in English but French. This allows a French user to 
  more easily look at this data and be able to figure out what's going on. When 
  they click on something like the verisign-atlas.net, it opens another window. 
  Instead of saying domain name it says the French equivalent. </font></p>
<p><font face="Arial, Helvetica, sans-serif"> You'll see that on slide 15. 
Here's 
  a close look at the data. On one side we have English, one side French. This 
  more easily gives the end user access to the information, especially if they 
  are a non-English speaker.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle<br>
  I want to really underscore that point about the presentation of the data 
being 
  localizable. It's certainly not all that tricky a job to provide localization 
  within interfaces for clients. But the fact is, the data is structured and 
machine 
  parcable makes it fairly straightforward to also apply that localization to 
  the data itself.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton Yes. <br>
  Slide 16, there are some questions about extensibility. IRIS is a layered 
protocol-we 
  have clearly defined layers within the protocol, and extensibility mechanisms 
  built in to each layer. There is an application transport layer so we can 
have 
  multiple application transports to meet the needs. The current ones defined 
  in Core is beep, but we're also working on a UDP version because we did some 
  analysis and determined, both in the domain and address case, 90% of all 
queries 
  are for single entities such as domain names or single IP address, map to a 
  network. Those answer can typically be small enough to fit into one UDP 
packet. 
  If you take this transaction off the TCP, TCP by itself no matter what has a 
  three packet handshake, and all other sliding window stuff to keep the data 
  going. So even at the transport level, it's three times slower than UDP, so 
  UDP would actually make it three times faster once we switch off to that. 
This 
  also allows us to say in certain cases we need to use UDP and certain places 
  we need to use TCP and so forth.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Then we have the common registry, 
  which is essentially the IRIS core layer which describes how you talk about 
  entities and searches, then we have the registry specific stuff. So we have 
  the main and address registries. And you can have data from one registry 
point 
  to data in another registry type, but this stops you from complaining the 
different 
  types of data.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Also, this allows reuse of these 
  common components. All of these things are common components on the Internet. 
  They're easy to find, so people can implement this protocol really easily and 
  allows us to switch them out when necessary for newer, faster things or 
different 
  use cases that may come up.</font></p>
<h4><font face="Arial, Helvetica, sans-serif"> <b>Some of these common 
components 
  are things like XML, NAPTR and SRV records and SASL 4 which is an 
authentication 
  framework for doing different types of authentication.</b></font></h4>
<p><font face="Arial, Helvetica, sans-serif"> Slide 17. In conclusion, the IRIS 
  &#133; are standardized, but the basis of what we set out to do is done. 
We're 
  currently working on improvements in other areas, like the address 
registries. 
  We're working on the UDP and lightweight availability check. There are &#133; 
  for other registries like e-mail.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The benefits are that it's 
decentralized, 
  it has navigation as part of that decentralized and distributed manner so 
even 
  though it's decentralized, you can easily find the data. Better policy 
support, 
  via multiple authentication because one of the things that plagues the 
current 
  court 43 is the fact that the only method people use for authentication right 
  now is IP addresses, and that works for certain things but it doesn't take 
you 
  that far.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> And of course structure and 
internationalization. 
  The structure gives us better performance and easier to understand, less 
ambiguous 
  queries and answers, also allows for internationalization and better IDN 
support. 
  Of course, it's extensible because there will be future needs down the road 
  that we haven't anticipated but we want to be able to take advantage of 
extending 
  the protocol for those needs.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The protocol itself is low cost. 
  It's not intended to replace or change anyone's database. It's just intended 
  to sit on top of the current database, much like the port 43 engines are 
today. 
  It has many authorization management features built into it so that doing 
distribution 
  of authorization keys or management is much easier and far less burdensome 
than 
  some would think. I'd like to point out that there are open sourced clients 
  and servers already available of this protocol.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Last slide, 18. For follow up, 
here 
  are Marcos, Leslie and my e-mail addresses. If you have any questions or 
concerns 
  that haven't been answered, you can e-mail any of us and we'll be happy to 
answer 
  that. Or you can go to the Chris Burton group and send e-mail to them as well 
  and get an answer there. Jeff?</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Thanks a lot.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator We'll now begin the 
question 
  and answer session. The first question is from Marilyn Cade.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: <br>
  I want to thank all of you for putting the presentation together, and to Andy 
  and Leslie, has it been two or three years since I've been in your 
presentations 
  and each time I learn something valuable. Thank you so much.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Most or many of the people 
interested 
  in this topic, particularly from the task force perspective, are 
non-technical. 
  I think you may have questions coming that seem very simple to those of you 
  that are technical, but challenge those of us who are not. I just have a 
couple 
  of clarifications that I didn't understand.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> On the one hand, we say that IRIS 
  is waiting adoption, yet we see there are existing deployments. Could you 
explain 
  where - and I've looked at the list of registries that are adopting - but I 
  don't understand yet what an option by the rest of the registries would mean, 
  or what it would mean if not all registries adopted.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle <br>
  As part of a clarification of Andy's slide on adoption, because this is not 
  adopter, not a requirement for providing who his service is for TLDs at this 
  point, registries that are standing up servers for these are essentially 
standing 
  up prototypes or test cases over their data. Those services are publicly 
available, 
  that's why Andy was pointing at the one running at Verisign Lab. They're 
available 
  for exploring the potential of this protocol. But the expectation is that any 
  operationally and formally deployed system would have to meet whatever 
requirements 
  are determined by ICANN for the provision of Whois services going 
forward.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> That was a complicated way of 
saying 
  that yes, servers are being stood up for individual registries much in the 
same 
  way one can stand up any other kind of service for the data. But there is no 
  claim that these are the replacement for Whois servers at this time because 
  Whois still formally defined as a way to provide registrant 
information.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Part two of your question was 
what 
  happens when only some people are playing. To that point, the issue is, in 
the 
  same way that the current Whois service is somewhat &#133; really an island 
  in deployment in that every registry has slightly different implementations 
  of how they present Whois information. There is the danger that, with 
piecemeal 
  deployment of IRIS servers, there is still some level of islands of data 
available, 
  but not the whole space. The only solution to that is to develop what the 
deployment 
  policy is for registries and registrars.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade The task force does not 
have 
  consensus option on what the data should be displayed or not. Are the present 
  prototype deployments restricting access to data? Or are they examining other 
  ways of presenting data?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton I can speak to the one 
  at Verisan Labs. We do restrict the data for data mining purposes. What would 
  take someone a year to actually go through all the data, a certain query but 
  I can't remember, it's a pretty high number to hit. In fact, on our 
Whoisservers, 
  we don't actually see those type of query rates.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Once you stand up the servers 
themselves, 
  that allows the clients to start playing around with how they want to see the 
  data to begin with, and that's the important thing. So the intent of our 
current 
  server is to allow clients to access the data and to be able to see what they 
  need to with that data in a highly structured manner.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade Who would you define as 
the 
  client in this case?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton We have two methods of 
  access. We have the IRIS court access, which is what's defined in the 
national 
  protocol spec. So someone can go download an IRIS client, the client 
software, 
  and they can access it. There are two pieces of client software available, 
one 
  is written in Pearl and one in JAVA. They can go access this data.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The other way is we have a Web 
interface. 
  Our Web site talks to the IRIS server, that way they don't have to actually 
  go download a client. This allows them to get to the data via Web interface. 
  If you go to the Web site, which is IRIS.verisanlabs.com, we play around with 
  how that data should look to users, etc. Because it's not unstructured, 
textured 
  data, we can do that.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade I'm sorry, my question 
wasn't 
  clear. When I use the term client, as a consultant, I mean the people I'm 
working 
  for. I should have asked what kind of users are accessing the data, by 
category. 
  Law firms? Registrars? Law enforcement? Business organizations? Do you 
know?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton We don't know because we 
  haven't placed any strong authentication on the server at present. One reason 
  we haven't is, first off, we don't want to step on anyone's toes, especially 
  the ICANN Whois task force. So we're waiting to see what you come up with in 
  that regard. In addition, we're only a thin registry for com and net at the 
  moment. We're not sure how much information we have is all that interesting 
  to some users. We are looking at what we can do, what makes sense, as far as 
  restriction of the data and data access to certain clients. But we don't 
know, 
  at present, who they are.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle So it's not the case 
that 
  we've been directly targeting &#133; customer segments and saying, 
&quot;Here's 
  a new service you should go and use.&quot; It's more a case that you put the 
  server up because, as you know, this whole process is &#133; Having defined 
  the protocol, it's now important to actually put it up where people can 
actually 
  work with it, &#133; can go and play with it and get a sense of &quot;Aha, so 
  this is what's feasible technically.&quot; Get a sense of what the range of 
  possibilities are to help inform the range &#133;</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade My next question has to do 
  with the statement you made that authorization is easier and less burdensome 
  than some people think. The two areas that I saw suggested as forms of 
authentication 
  did not seem to take into account the developing country issue where 
certificate 
  authorities are, and the use of credit cards, it's very different than it is 
  in the developed world. Are we assuming that authentication will be possible, 
  but we're not assuming it will be mandatory unless there is a policy 
recommendation. 
  Is that right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  Yes, that's accurate. The protocol has no assumptions about who gets what 
access 
  to what data. That's all a policy decision. With regards to certificate 
authorities, 
  don't think of commercial certificate authorities such as Verisign. You can 
  definitely do that with a commercial certificate authority, it doesn't 
necessarily 
  have to be. So the U.S. government has its own certificate authorities that 
  it has, and those can be used, as well as the certificate authorities of any 
  government or organization. It doesn't have to be a commercial entity. I also 
  want to note that a particular server can use multiple certificate 
authorities. 
  </font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator The next question 
comes 
  from Maureen Cubberley.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cubberley Marilyn, thanks for 
  introducing the questions that way. I have the same view, that some technical 
  things may be complex, but they seem to flow into some fundamental questions. 
  I'd like to ask a question about slides ten and eleven where we're talking 
about 
  the tiered access and authentication distribution. When we talk about the 
multi 
  type authentication methods, does IRIS draw a line between the categories of 
  viewable information, the types of viewable information that exists? How 
customizable 
  is that?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz<br>
  That's not &#133; a protocol issue. That's more the policy you have developed 
  for the registry. You just have to implement it. IRIS supports for it, so 
it's 
  not that IRIS says that there is going to be four or five levels or access or 
  this number of information categories, this is something that you can 
implement 
  locally. IRIS allows for communicating that maybe you are not allowed to 
access 
  this kind of information at that authorization level you are using at the 
moment.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cubberely: So it's infinitely 
  customizable. Right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: Right.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator No further 
questions.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: I think you said 
something 
  about the fact that response times shouldn't be effected by layering the IRIS 
  protocol on top.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: No, it shouldn't 
be.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: That's true whether 
it's 
  a thick or thin registry?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton : It's better for a 
thick 
  registry. It helps in both situation, but a thin registry doesn't have as 
many 
  indices to look across as a thick registry. Therefore, because the queries 
are 
  well structured and a lookup is defined as hitting one index, so in a thick 
  registry you'd probably get better performance.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz <br>
  Maybe somebody is thinking that, because of this whole graphical presentation 
  level, that this implies that there is lots of data being transmitted. 
Obviously, 
  everything has to be much slower. This is not true. I want to say that 
clearly. 
  This graphical thing Andy presented, there is something that it's running on 
  the client. So the amount of data being transmitted over the net, it's very 
  small. It's admittedly more transmitted by the Whois protocol. There is a 
slight 
  overhead, but this overhead doesn't account for a bigger delay in response 
times 
  when compared with factors that are much more important, like the actual 
speed 
  of your relational database on the server or how far away you are physically 
  located from the server. So this overhead that IRIS carries is not relevant 
  to the response times, not practically relevant.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  Most of the latency that comes with a Whois query or an IRIS query is 
basically 
  transit time of the packets and the actual data lookup inside the database. 
  The actual marshalling of the data is usually pretty small compared to the 
time 
  it takes to do the other things. Even though we've finished the core work, 
we're 
  still looking at ways to make this even better. So something we're doing is 
  this UDP work where we're trying to offload what we statistically found are 
  90% of all our queries into the UDP space. So at the network level, it 
becomes 
  three times faster. It doesn't mean your database is going to be any faster, 
  but if the network level becomes three times faster and the load on a server, 
  UDP is much less.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> You can look at a DNS server, 
which 
  actually handles much more load for CPUs than a Web server. The reason is the 
  vast majority of their traffic is &#133; Those are the things we're still 
refining. 
  We're even talking about a more refined TCP transport, but that's work we're 
  just now looking into. So there would be no reason why you couldn't meet your 
  current SLAs you have now. In the future, this protocol will be even 
faster.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator There's a question 
from 
  Marilyn Cade.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade I have a number of 
questions. 
  It may spark questions from others. A couple things come to mind. We opened 
  the conversation by saying that the existing nick names Whois protocol was 
developed 
  many years ago. We all know we've learned a lot, and that in fact, the 
Internet 
  has changed a great deal since then. So if IRIS were implemented today, if 
there 
  were a consensus policy, for instance, that supported the implementation of 
  IRIS-and I'm speaking hypothetically-if it were implemented today with full 
  display of all data that is gathered, what exists in IRIS that will help with 
  the accuracy problem, which is a serious problem in today's Whois.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> Secondly, what exists or could 
exist 
  with the implementation of IRIS that would allow the discrimination between 
  category of registrant? For instance, in a dot-post, which is announced by 
ICANN 
  staff as being under negotiation or their authority and post, as I recall 
from 
  their application provides something equivalent to a post office box where 
they 
  gather accurate data such that accurate data is not displayed. But in another 
  TLD, there might be a different kind of category of use, like a user who says 
  I'm an individual and I've authenticated, does IRIS allow us to discriminate 
  in the display of data between different categories of users?</font></p>
<p><font face="Arial, Helvetica, sans-serif"> My next question has to do with 
  trying to understand the cost and burden on registries and registrars of 
moving 
  in this direction, and whether there is a transitional period or cost 
anytime, 
  as I know from having run a business, anytime you adopt a new software or new 
  means of doing something, you have a number of both hard and soft costs, 
including 
  training of your people. What are the cost areas we should be thinking about 
  if we were to move forward in this direction?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  I'll try to attack the accuracy question. First off, IRIS is only an access 
  protocol, not a provisioning protocol. So most of the accuracy comes in on 
the 
  provisioning side, not the access side. You could potentially sign the data 
  coming out of the IRIS server so you'd know it was authentic, but that's one 
  thing.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> The big answer to that is that 
people 
  will be much more willing to make sure their data is accurate, or be much 
less 
  apprehensive about providing accurate data if they didn't think it would be 
  shown to everyone on the planet.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: I think that's right, 
  and it does somewhat lead into the second question about distinction 
categories 
  of users. The point with allowing signing of data, etc, from a display 
perspective, 
  you can make the distinction between types of data and types of users. It 
becomes 
  a question of deployment realities, whether that is useful or not.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: Andy, I've noted your 
comment, 
  and Leslie's support, for your personal view that people will be more willing 
  to provide accurate data, or less apprehensive, if not shown to everyone on 
  this planet. I think that the task force doesn't have a consensus view on 
that.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: What we're saying is 
that 
  is the limit and extent to which IRIS supports a solution in the accuracy 
problem. 
  We recognize there is a much larger issue about detecting and ensuring 
accuracy 
  of data, and that's beyond the scope of IRIS.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Marilyn, can we see if 
  there is anyone else in the queue?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: We can, but I just want 
  them to pursue, since the task force doesn't have the consistency on that 
particular 
  force, and I understand that IRIS isn't the answer to accuracy. Are there 
other 
  steps that could be taken or other activities underway that could effect the 
  accuracy problem, leaving aside the display issue, but could address the 
accuracy 
  problem?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton:<br>
  I don't think those are protocol problems; I'm actually not sure if they are 
  technological problems. Sounds more like a social issue. Technology can help 
  with the problem, but will not solve the problem. Most of it is on the 
provisioning 
  side, so if it's not within the EPP protocol, then it would actually be 
within 
  the EPP implementations themselves that would have to do some accuracy 
checking, 
  etc. It may actually just be people who do the checking. I know what we do at 
  Verisign on the certificate authority side, even though I don't work for that 
  division. They actually have humans in the loop because you can't get 
computers 
  to do it.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: The answer is that all 
  technology can do is help to accurately convey the level of confidence in the 
  accuracy of the data. You can convey that the registry/registrar believes 
this 
  data to be accurate, that's all you can do.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade Can you go on to address 
  my last question which was more about what you &#133; different areas of 
cost.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz:<br>
  About costs, I think that Andy already addressed this in the presentation. 
There 
  are no IPR's software which is for downloading out there. It's open source so 
  you really can check what you are running on your machines. The only excuse 
  I could find from somebody to implement it is this initial investment that 
you 
  always need when you have to deploy something new. You have to get along with 
  it and learn something. We are always a bit lazy when we have to learn 
something 
  new. This is the only &#133; I could find to start implementing something 
like 
  that. On the other hand, we've already seen the list of advantages. I really 
  think the advantages are worth it.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle <br>
  I think some of the cost incurred is going to be in changing whatever 
business 
  practices to meet the policies that are agreed on. That's nothing to do with 
  IRIS. What I mean is, if there is a policy to move to, accepting distinctions 
  between categories of users, etc, then registries and registrars are going to 
  have to look at how they categorize users and make sure that all their data 
  systems support that. That is nothing to do with an IRIS deployment. It's 
just 
  a change in the Whois service question.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade <br>
  That's very helpful. I think you said this, Andy, but I just want to verify 
  it. Hypothetically, let's say that we have a tiered approach and it would be 
  possible, if the implementation supported this, for certain categories of 
users 
  to say I wish to have all data displayed and other categories to say I don't 
  want data displayed.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton <br>
  Yes, that's correct. It's whatever, whoever is setting policy, ICANN, the 
Whois 
  task force or whoever that says law enforcement &#133; this data item, this 
  data item and this data item, whereas registrars get to see everything. I 
can't 
  even begin to speculate what that would be. But it is a matter of policy 
only.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: It is the case also 
that 
  an individual user can say I'm willing to have my address shown publicly, or 
  no I'm not.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: Good answer, both were 
helpful.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Operator, anyone else 
  in the queue?</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator Next question from 
Mickey 
  Mouse.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: I suppose that was 
probably 
  not a serious one.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator It was someone who 
refused 
  to give their name, sir. In that case, we'll take the next question from Ryan 
  Lehning.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: This is Steve 
Metalitz 
  with Ryan. A follow up question to one or two of Marilyn's questions. When 
you 
  say it's not a provisioning protocol, it doesn't effect then what goes into 
  the Whoisdatabase. It's just a questions of what comes out in response to a 
  query. Is that right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Correct.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: In that case, the 
question 
  about different registrants specifying different data to be made available, 
  that does require categorizing registrants. I'm not clear on how IRIS helps 
  with that. You'd have to distinguish between a registrant who says all my 
data 
  can be available, as opposed to a registrant who says let's assume the policy 
  allowed none of my data available.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: That's true that that 
  distinction has to be made within the database, but the issue is what will 
happen 
  is, when an IRIS query comes in and it's made to the database, the data 
either 
  is provided to as part of the response, or it is not. Inbound on the query is 
  also an indication as to whether or not this is a general anonymous question, 
  or whether there was any level of authentication and credentials 
available.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: I understand it can 
  distinguish between Whois requestors. In terms of distinguishing among domain 
  name registrants, just to take the domain name side of this, it doesn't do 
that. 
  There has to be a distinction in there that it will &#133;</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: The distinction must be 
  captured in the data held by the registry/registrar.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: EPP does that, has 
those 
  type of capabilities already in it. So registrar's can tell the registry the 
  desire of the registrant.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: It's got that in the 
protocol 
  that the EPP want to and the registries are in the process of implementing 
it, 
  but most registries at this point on the policy side, don't activate those 
privacy 
  flags yet.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: That's a good point 
that 
  again, here is something that the protocol provides that policy has not 
stated 
  as needed or even has maybe overridden in some cases. So the registrants 
could 
  be saying I don't want any of my data showing, it's just not a policy 
decision 
  that's allowed to be made. Essentially, the example that a registrant has 
said, 
  &quot;I don't want any of my data to be shown to anybody ever except for 
me,&quot; 
  and a law enforcement person comes into an IRIS server and authenticates, as 
  law enforcement, it doesn't matter what the registrant asks for. The policy 
  is that the law enforcement gets to see the data. Or it could be that they 
don't. 
  It's all a matter of policy.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: To the extend that 
there 
  is a differentiation, given holding the requestor constant to the extent that 
  there is a differentiation in what's returned from the query based on 
characteristics 
  for desires of a registrant, IRIS does not have that capability. That would 
  have to be an EPP capability that's used, or else that protocol would have to 
  be adapted to provide that capability, right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: We're having a problem 
  with terminology. I think the right answer to convey what you want to hear is 
  yes, but I'm not comfortable saying that IRIS doesn't have the capability in 
  distinguishing between users because I believe it does.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: It does, if that 
distinction 
  is already there in the database.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: Right. There would be 
  no way for IRIS to fabricate or interpolate what the registrant's desires 
were.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator The next question 
comes 
  from Paul Stahura.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura: I'm worried about 
people 
  who have the correct authentication getting the data and then distributing it 
  to people who don't have the correct authentication. It's a policy thing. I'm 
  wondering if IRIS can help. Let's say we had a policy that said people with 
  dis-authentication could only keep the data for 24 hours &#133; Can IRIS help 
  us there?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: I'm sorry to say I don't 
  think IRIS can help because once the data has been delivered, there is no 
real 
  way to track what is happening with this data and for how long the data will 
  be kept at the other side.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: That requires 
proprietary 
  software to accomplish that. It's really hard to watermark data in such a way 
  that people don't notice, but this is all textural data which is much harder 
  to watermark. On top of that, if you want to do something similar to DRM like 
  what ICANN does, that is proprietary software and that's exactly how they 
accomplish 
  that task. You can't really say we're going to have an open standard, and 
then 
  require everyone to get a certain piece of software.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> P. Stahura: I understand that if 
  somebody is not following the protocol, they could ignore. Let's say there 
was 
  &#133; to live on this piece of data, they could ignore that but then they 
would 
  be breaking the protocol &#133;</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle The issue is that 
they're 
  breaking the policy. What you need is mechanisms for detecting if there are 
  continuous &#133; doing that. For instance, if there is a registry client 
that 
  has signed an agreement not to do that and they're repeatedly doing it, there 
  should be the ability to turn around and revoke their rights.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> To follow on Andy's ICANN's 
example, 
  I don't know how many people are familiar with that software and service. 
Apart 
  from the fact that it's proprietary software, two important aspects need to 
  be understood about how it achieves the control of the digital material. It 
  not only requires their specific software, it also means their software has 
  to anticipate what our appropriate and likely use case is. Those are the ones 
  supported for all users across the globe. That's not the sort of thing that 
  we've seen as being applicable for Whois. Marilyn mentioned some ways in 
which 
  different regions of the world are different in terms of their needs and 
abilities.</font></p>
<p><font face="Arial, Helvetica, sans-serif"> I'd also observe in the case of 
  ICANN, since this is music which is very popular, it wasn't that long before 
  they started to use software which ripped &#133; controls out of the data. 
Then 
  you're right back to square one. If it was of sufficient interest to people 
  to do that here, exactly the same thing would happen.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: If you want a short 
answer, 
  yes, you can put a TTL on the data if you really wanted to. I don't know if 
  that's what you were getting at, but you can put a time to live on there and 
  if someone violates it, they're a bad actor.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: You can provide 
mechanisms; 
  you can't provide enforcement.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura I'm just wondering, if 
  it was in the protocol at all. I understand that if somebody breaks a policy 
  of ignoring the TTL or if the policy was in contract with the people getting 
  the information to say you can't store it or pass it on, I see that. They 
can't 
  help us because we're not implementing some kind of visitor right management 
  thing, and we would need a proprietary client, &#133; on the front end, to 
enforce 
  all that. I see that. But if it had a TTL, people who got the &quot;standard 
  reference clients&quot; would at least have that. Then they'd have to build 
  their own client if they want to violate that TTL.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: You can put in those 
types 
  of policies, if you want. If you go to the com net IRIS server, you can see 
  where we have stuck in that you're not allowed to use the data for spamming. 
  It's not going to stop anyone from using it for that, but we have that in 
there 
  where we put the notice. You can't use it for spamming, so we've given them 
  the notice. If they do it, they're in violation.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura: I see that. But if you 
  had a TTL, then your Web based clients would not be able to store the 
information 
  if you complied with the spec. Right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: If you're asking 
specifically 
  if there is TTL in the actual current dereg spec, no there is not. Could one 
  be added very easily? Very, very easily. I can do it in about two minutes. 
But 
  I want to point out that this is textual data. Someone could easily cut and 
  paste it and it wouldn't even require implementation of the client to do it. 
  Then off they go.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: This is why I said at the 
  beginning that it's not feasible.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator We're showing no more 
  questions.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Okay, a follow up on 
the 
  audit trail comment. You talked in the presentation. Would this make it 
possible 
  for the server to collect information about the requestor of the information 
  and distribute that information out to the registrant?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Yes. I want to be 
explicit 
  about this. Audit trail is actually not a function on the protocol, it's a 
function 
  of the implementation of the protocol. You do have the benefit of the fact 
that, 
  because the data is highly normalized, it's well understood what was accessed 
  and by whom. When you use strong authentication, you can say here is the 
actual 
  serial number of the certificate or the user ID of the person who came and 
got 
  this data. And they got this specific piece of data, they didn't just query. 
  They entered this and got a bunch of data back. So the audit trail would then 
  be meaningful to a registrant or any third party.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle And if you were serving 
  up data with only on access, then you could provide information in terms of 
  the number of accesses to the data.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: And since the queries are 
  much more structured, you can really categorize, and have the refined 
granulated 
  policies in the sense of &#133; person is only allowed to make ten queries 
regarding 
  person data per minute, but he's allowed to make 100 queries regarding domain 
  data per minute. Because you really know what the person is querying so you 
  have very fine granulation of it.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton Also, there is a 
particular 
  type of &#133; access mechanism called one time passwords. It's basically a 
  cryptographic password solution where a password is only good a certain 
number 
  of times. So you issue the password, it can only be used a certain number of 
  times before cryptographically it can no longer be used again. So not even an 
  accountant administrator could up the number or whatever. Once the password 
  it is handed out, it can only be used a finite number of times for 
access.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: In the case of 
certificates, 
  this is much more extreme. Even if you were able to keep track of old data 
that 
  the client has sent to the server, there is no way for the server to 
impersonate 
  the client.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Okay.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator We have a follow up 
question 
  from Marilyn Cade.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: Jeff, have you gone 
through 
  the questions that were submitted? Because you just asked one I know had not 
  been asked. Is that what you were going to do next?</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: That's what I'm going 
  through now.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: Okay, because I wanted to 
  ask a follow up question in line to what we were just talking about and 
consistent 
  with the questions that we're going through. On the ability to identify who 
  has submitted the request to gather data on the type of request that's being 
  asked, whether it's just availability of domain name or actually information 
  about contact, etc, is there any mechanism in IRIS that would, when incorrect 
  data is identified, flag that? Of if fields are left blank, it's possible to 
  print out a report showing that a certain percent of the data that is being 
  input by the registrant is being left blank, those kinds of reporting 
statistics?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: How do you mean block 
that, 
  not being deliberate to the client?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: You're right because this 
  is an overlay to the underlying database.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: It's just about 
delivering, 
  not entering the data. Obviously, the implementation you have, you can keep 
  track whenever you are answering and query whether you found not well formed 
  data in your database. That's possible. But I think that's too late. You are 
  just realizing you have something inaccurate or not well formed, you should 
  have checked that before entering it into the database. Does this answer your 
  question?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: I don't think so, but it 
  was helpful in any case. I'm learning more. Let me refine my question. One 
thing 
  that the registrars are responsible for is, upon being notified that there is 
  inaccurate data, they need to take steps to notify the registrant of the 
registrant's 
  responsibility to correct that data.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: I see. It's much easier 
  with this protocol to identify inaccurate data in the sense that the protocol 
  is much more structured than Whois was so, now, you have very well defined 
fields. 
  Here you have to have a telephone number and it has to have to have this 
format 
  otherwise it's wrong. The protocol itself provides this information, XML 
information, 
  so it's really easy for a registrar to check their results coming against a 
  pre-defined format and get aware whether the data is fulfilling the rules 
defined 
  in the schema.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: That's what I was looking 
  for was the reporting &#133;</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator No more questions at 
  this time.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Jeff Neuman: One other question I 
  had was on the Whois servers. Is there is an IRIS server run by the registry, 
  it would be that individual server that defines what the output is, 
correct?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Ultimately, yes. So 
let's 
  say that ICANN says there is a policy that certain classes of users see 
certain 
  types of data, but the decision is ultimately the server operator can make 
who 
  sends that to the client. If they didn't do what ICANN is asking them to do, 
  then they are in violation of ICANN policy. But you're right. However, 
because 
  the data is well structured, it's easy to figure out when they're not 
conforming 
  with policy.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: One more question on 
data 
  structure. Although you initially talked about the cost being pretty low, are 
  there costs imposed on the operators for existing names to put all that data 
  in the format that's specified by IRIS?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton No, the intent is that 
  you don't have to restructure your database or do anything to it. You're just 
  accessing the database in the same way that the current Whoisservers are 
doing 
  it. We actually spent some time on this in the CRISP working group, wanting 
  to make sure the protocol itself didn't require any type of reorganization of 
  indexes or anything like that. We felt if that occurred, suddenly this is too 
  burdensome to implement.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: I would refine that 
slightly 
  and say the cost essentially is in a software that does the translation, the 
  mapping between your existing software and providing data in the IRIS 
protocol. 
  It doesn't have to be a flat out conversion of data and databases or the 
backend 
  software tools. The other thing I would say is, to the extend that there are 
  changes needed in that backend database, it's going to be required to support 
  policy changes, is not a software question.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: So it will be the 
translator 
  that registry, let's just take a phone number, for example, some registries 
  start the country code with a plus sign versus just having the number out 
there 
  without the plus sign, some have it separated by periods and some might use 
  hyphens. You're just talking there would be a conversion software that would 
  convert it - it wouldn't make any changes in database - but convert it so 
when 
  it's displayed.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle Right. Whereas, if there 
  are policy changes about only display the first five telephone numbers of 
telephone 
  numbers for people whose last name starts with D, that's something that would 
  be needed whether you're using IRIS access or Whois</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman Okay. That answers all 
  the questions I have in the form we gave you.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator The next question 
comes 
  from Steve Metalitz.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: It's a follow up on 
  the same point. This goes to the question of the accuracy of the data in the 
  database. I thought I heard the statement that the accuracy would be improved 
  because the fields are well defined. Let me take an example. Let's say the 
phone 
  number listed is 1-2-3, which we know is inaccurate. Can anyone explain how 
  IRIS would help you determine that this was inaccurate?</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: On the outside, in 
terms 
  of a client looking in as opposed to the provisioner, the issue is that you 
  understand that this is asserted to be the phone number as opposed to 
wondering 
  whether this was a fragment of, for instance, a zip code.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: So as the 
Whoisrequestor, 
  I would have a higher degree of confidence than today that this is really the 
  phone number listed in the database.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: You understand the 
assertion 
  that this is the phone number.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: It's not that you have a 
  higher confidence that this is the phone number listed in the database. You 
  can have the absolute confidence that this is the data listed as delivered by 
  the server. The point is, this is not the definition of accuracy. It depends 
  on the definition of accuracy that you're using. Do you have accuracy if you 
  interpret this is the data delivered by the server. But 1-2-3 is obviously 
not 
  a valid phone number.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Ryan Lehning: This is Ryan. Can 
you 
  have confidence that that was what the registrant entered as the 
number?</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: You can only have the 
confidence 
  that that is the data that the registry is delivering you. If you tracked the 
  registry-</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: That goes back to a 
disconnect 
  in the terminology. When I hear the question about accuracy, I think of the 
  provisioning side. But the questions you've been asking is accuracy in how 
the 
  client understands the structure of the data. But as to what's in the 
database, 
  that's more of a provisioning instrument that must be undertaken. I think 
ultimately, 
  there are technologies to help and to detect inaccuracies, but there are not 
  technologies to make it accurate.</font></p>
<p><font face="Arial, Helvetica, sans-serif">S. Metalitz: My other question was 
  the audit trail question. It was stated that this is not a function of the 
protocol 
  but of implementation. So our questions about if there is a record of the 
query, 
  where is it stored and who has access to it. Those are questions that would 
  be decided by the implementation of the protocol. The implementation could 
say 
  you only have access to it if you present a court order, or it could say the 
  registrar has access to this for marketing purposes. It could say 
anything.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle Right.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator The next question is 
  from Maureen Cubberley.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cubberley: On an entirely 
different 
  topic, one of the earlier questions was what does this mean if not all 
registries 
  adopt it. You do have an item in your presentation about port 43 
cohabitation. 
  What are the main issues you're working on in order to enable both IRIS and 
  those registries to chose to stay with what they've got with port 43? What 
are 
  the issues around compatibility and insuring that it is a closed running 
system 
  and the access protocol you described is complimentary, if not supportive, to 
  what's already happening with those registries that stick with port 
43.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Port 43 is not all that 
  complicated of a protocol. You could write a Whoisclient in about five or ten 
  minutes. Putting that functionality into an IRIS client is really not that 
difficult. 
  The thing is that the end user sitting at the IRIS client doesn't get the 
IRIS 
  benefit of accessing Whoisdata over at port 43. When we talk about 
cohabitation, 
  it's a way of allowing the navigation elements within IRIS to actually be 
back 
  quartered to port 43, so you can find the correct Whoisserver. You still 
don't 
  have query distribution and some of the other nicer things built on the IRIS, 
  but at least you can do that. You would have one piece of software that could 
  talk to the Whoisservers, and one to talk to the IRIS servers. You don't get 
  all the IRIS functionality out of port 43, but it means you don't have to do 
  through different ways of getting that data.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cubberley: So one query will go 
  to where ever. There's not a hierarchy of ranking how it's 
accessed?</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: There is the ability to 
  express preference, naturally that would be towards IRIS servers because the 
  truth is it's IRIS clients who will be making use of this. Whois clients 
don't 
  have notion of this idea of co-habitation or anything else. But it is, at 
least, 
  a mechanism for bringing the Whois servers into the fold to the navigation 
side 
  of what IRIS provides. You get to that point, and there is a hand painted 
arrow 
  pointed down a pot-holed bouldered dirt road. Go down there at your peril, 
but 
  there it is.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator Next question is from 
  Marilyn Cade.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: We could have skipped 
past 
  something you said earlier that is actually very important to ISPs and big 
infrastructure 
  providers. That is and to business users themselves. We rely on not only the 
  DNS Whois but also the Whois maintained by the RIRs. You mentioned one thing 
  IRIS does is bring together a form of consistency across those two 
&quot;Whoises&quot;. 
  Could you elaborate on what the stat is with the RIRs and what's going on to 
  the extent you know it?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: All four RIRs are 
current 
  participants to the CRISP working group. One of the co-chairs of the CRISP 
working 
  group is George Michelson, Whoisthe CTO of APNIC. The RIPE NCC is doing a lot 
  of work in this area in getting Gunders and Shane Curd have actually are now 
  owners of the draft that talks about how the address registries are to be 
structured 
  over IRIS. In fact, we believe that we'll go to last call pretty soon in the 
  CRISP working group. They worked pretty strenuously to get this right. We 
have 
  engaged with ARIN and LACNIC and &#133; as well. ARIN is very involved as 
well. 
  </font></p>
<p><font face="Arial, Helvetica, sans-serif"> A lot of what was going on there 
  is coordination between the RIRs and the different data models. Between the 
  four, RIRs there are three different types of data models three differnt 
types 
  of registries. A lot of that was making sure we got it right, and I believe 
  we do now. We started it a year ago, it seems, and so ARIN and APNIC and RIPR 
  NIC are all talking, and they represent each other within the CRISP working 
  group. We're not going ahead with what we're calling A-reg.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: I'm sorry, ARIN? 
APNIC</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: &#133; LACNIC which is 
  Latin America and RIPE NCC.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Cade: The provisional AFRINIC 
  is participating or not yet?</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: We haven't seen any 
evidence 
  of them, but my suspicion is &#133; because they've got more primary things 
  on their minds.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: A lot of how things 
work 
  in the RIR space, I don't want to speak for them but I'll say what I've 
observed, 
  the RIPE NCC has software they developed, and it's reused by the other RIRs. 
  What happens is once the RIPE NCC has done it, the others will take it on. 
This 
  is extremely true with the Whois servers, run by APNICare the ones that write 
  distribute. This is true of what the call the NIRs, as well.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: I wanted to confirm that 
  is the behavior I observe, as well.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator Next question from 
Chuck 
  Gomes.</font></p>
<p><font face="Arial, Helvetica, sans-serif">C. Gomes: Several times, it's been 
  stated that the provision or data is the registry. I'm assuming that, because 
  of the distributed nature of IRIS, that the provisioner of the data could 
actually 
  be a registrar. Then you don't have the duplication of both registry and 
registrar 
  being authoritative for the data, while at the same time the registry would 
  be the provider of the IRIS Whois service. Is that correct? </font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: I don't understand the 
  question, Chuck.</font></p>
<p><font face="Arial, Helvetica, sans-serif">C. Gomes: Several people said the 
  data is coming from registry in every case. That could just as well be a 
registrar 
  instead. Is that correct?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Yes. When I say 
registry, 
  I'm actually meaning a generic versus a thick/thin domain registry or 
registrar. 
  A registrar is a type of registry. I'm sorry if I was inaccurate.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator Next question from 
Paul 
  Stahura</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura In your slide, you said 
  registrars may point registrants, and registries may point registrars. I 
understand 
  that. What if some of the information is contained in the registry for a 
particular 
  query, and some of it as at the registrar? I assume there is a provision for 
  replying with some information from the registry, some from the 
registrar?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: It really is all in how 
  the client wishes to present that data to the end user. The important part of 
  the server side is the server knows how to properly say here is the domain 
information 
  I have, and by the way, I know registrar X has this domain information as 
well. 
  You may go access it over there. How the client wishes to present that is 
really 
  a presentation style of the client. I've got certain theories on how best a 
  client would do that which I've tried to implement with our GUI work, I know 
  others have talked of other ways of doing it. But the client software can 
access 
  the data in both places. The MC reference is well understood by the client so 
  he knows the registry and the registrar have some data at the same time, and 
  &#133; go get it in both places.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: The protocol supports 
that 
  you can really combine data from different repositories.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura: What if data is 
different? 
  For example, if the registry says this is the registrant name, and by the 
way, 
  you could get this other information at the registrar. Then the registrar. 
Then 
  the registrar says this is the name and it's different. Then the client has 
  to reconcile that somehow. Which one does it use?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton That's a matter of how 
  it wishes to present the data. In the client software I have, I have what's 
  called a tree widget or tree control which is used for doing the 
representation. 
  You can see that here is the date the registry has. Underneath that, you see 
  what the registrar has. So the user can bring up both pieces of data, put 
them 
  side by side and see they're different. Specifically, the client could 
actually 
  be programmed to flag that and start blinking in big red letters that they 
differ 
  or something. But that's a function of how the client sees the 
data.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle The important thing to 
  keep in mind is IRIS is making sure it keeps track not only of data for this 
  given record but also &#133; key element of what it is aware of.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. StahuraMy second question is 
related 
  to query limit. Someone said based on the certificate or authentication of 
the 
  user, that user not only might not be able to see certain information but 
might 
  be limited to a certain number of queries per day. Is that right?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton Yes. It's really a 
matter 
  of policy.</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. So my question is, for example, 
  I could be wrong, but can a user type in joe@xxxxxxxxxxx as an e-mail address 
  and query the system to say return domain name whois information for any 
domain 
  name with that e-mail address in one query?</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: I believe so. You're 
asking 
  if the user can submit query, saying I want all the main names with a certain 
  e-mail address and they'll get all the domain names? Or are you asking if the 
  server can limit how many domains they get back?</font></p>
<p><font face="Arial, Helvetica, sans-serif">P. Stahura: If there was no limit, 
  they'd get all the Whoisinformation for all the domain names at hotmail, 
let's 
  say.</font></p>
<p><font face="Arial, Helvetica, sans-serif">A. Newton: Not necessarily. The 
server 
  can limit the number of answers it gives back. So even though the answer 
could 
  be 1,000 domains, the policy can be that you can only see 100 of 
them.</font></p>
<p><font face="Arial, Helvetica, sans-serif">Coordinator No further questions 
  at this time.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: I'll take this 
opportunity 
  to thank our presenters, Andrew Newton, Leslie Daigle and Marcos. Thanks 
again 
  for your presentation. They've been sent to the task force list, which is a 
  publicly accessible list. If there is anyone who can't access it, feel free 
  to send this gnso.secretariat an e-mail to get a copy of the presentation. 
I'm 
  sure we'll have a number of follow up questions for you guys, possibly a 
follow 
  up call in the future. Thanks a lot.</font></p>
<p><font face="Arial, Helvetica, sans-serif">L. Daigle: I'd like to say thank 
  you, too. I appreciate the opportunity to speak about this. I'd like to end 
  on the point that we're only trying to build technology that will suit the 
needs 
  that you're defining. To the extent you can keep us aware of the need and 
progress 
  in your deliberations, it will help our process in meeting our goal. So 
thanks 
  a lot.</font></p>
<p><font face="Arial, Helvetica, sans-serif">M. Sanz: It was my pleasure, as 
well, 
  to have somebody who wants to hear about this.</font></p>
<p><font face="Arial, Helvetica, sans-serif">J. Neuman: Thanks for joining the 
  call. <br>
  <br>
  The next task force call <br>
  <b>Next Tuesday 18 January 2005 at 11:00 EST</b></font></p>
<p>&nbsp;</p>