ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

GNSO Council Public Forum
Tuesday, March 28, 2006

>>BRUCE TONKIN: Okay.
Well, we'll jump -- If you've finished there, Kurt, we'll jump straight into the discussion on the GNSO public forum, which is fairly packed today.
There's quite a few topics for discussion.
The agenda will consist of an update on what work we're doing on the WHOIS policy, what work we're doing on new TLDs, what work we are doing on some of the contractual issues associated with existing TLDs, some work on -- some initial thoughts that we have on the IDN policy issue, and, finally, if anyone's still left and if we still have time, an update on what's happening in terms of reviewing the GNSO structure.
So I'd like at this point to hand over to Maria FARRELL, who will provide an update on the current work on the WHOIS task force.

>>MARIA FARRELL: Hi, everyone.
Sorry for the delay there.
I'm just going to give you a very brief update on the WHOIS task force and the work of the task force.
And before I do that, I would like to just pay tribute to the work of the chair of that task force, Jordyn Buchanan, who has -- is now moving on and has left that position, but has done an absolutely Sterling job in always testing circumstances and managing to find the middle ground on some rather tricky issues.
The WHOIS task force was chartered by the GNSO Council in June last year.
It was given several work items that it needed to do.
The first of those is the main feature of the presentation today, which was defining the purpose of WHOIS is contacts in the WHOIS.
Second -- once that's established, it will move on to looking at which data should be public and how that data should be accessed.
Then it's going to work on the accuracy of WHOIS data.
And, finally, the other -- the fourth bullet point which you see here, resolving conflicts between ICANN contractual requirements and local privacy laws.
That work item has, in fact, been concluded by the GNSO Council, and we expect it will be the subject of discussion and decision very shortly by the ICANN board.
So the progress to date on WHOIS is that the task force has come up with two alternative formulations of the purpose of WHOIS.
Now, purpose of WHOIS is very important, because it is -- it is something that, in a way, defines what are the acceptable uses of the WHOIS system.
The first formulation -- and I'm going to read it out for those of you who possibly may not be able to read it on the screen, is formulation 1.
Formulation 1 says the purpose of the gTLD WHOIS service is to provide information sufficient to contact a responsible party for a particular gTLD domain name who can resolve or reliably pass on data to a party who can resolve issues related to the configuration of the records associated with the domain name within a DNS server."
That's what we are going to refer to as formulation 1.
This formulation is supported by the registrar constituency, the registries, and the noncommercial users constituency.
It's also supported informally by the at-large advisory committee to the ICANN board, which has a liaison on the GNSO Council.
It's considered to be consistent with the narrow technical mission of ICANN and ICANN's core values, and particularly with regard to the historic or possibly the initial uses of the WHOIS system.
And the core values, the ICANN core values, which are generally referred to in support of WHOIS formulation 1 are that it's the security and stability, respecting creativity and flow of information by limiting ICANN's activities to matters in ICANN's mission, and, thirdly, to delegating to and respecting the policy role of responsible entities that reflect the interests of affected parties.
So that briefly is formulation 1 of the purpose of WHOIS.
Formulation 2, and I'm going to read that one out again, is, "The purpose of the gTLD WHOIS service is to provide information sufficient to contact a responsible party or parties for a particular gTLD domain name who can resolve or reliably pass on data to a party who can resolve technical, legal, or other issues related to the registration or use of a domain name."
Formulation 2 is supported by the intellectual property constituency, the Internet service providers and connectivity constituency, and also the commercial and business users constituency.
This approach is also consistent with the history of WHOIS and follows the growth and expansion in users and importance of WHOIS and of the Internet as a means of communication.
Effectively, it maps to the uses of WHOIS that we see currently today.
This approach is also consistent with ICANN's mission and core values.
And, briefly, to conclude, both formulations agree that WHOIS should provide contact names that can be used in relation to issues due to -- connected to a domain name.
And I suppose the main differences would be possibly in relation to the scope of issues that should be dealt with.
So if you have any questions regarding the interpretation of either of the formulations, may I refer to you the council members.
Thank you.

>>BRUCE TONKIN: Thank you, Maria.
I think the -- at least the task force is fairly evenly split over those two formulations.
We did present them earlier this week to the Government Advisory Committee, and one of the questions they asked, which I thought was a good one, was, when you look at those two formulations, the differences between them are probably fairly subtle.
And I was asked, what do those differences mean?
I think rather than me answering that question, what I will do, just before we open it up to any comments from the floor, is allow a person from either side of that debate just to say what they think the differences are.
So if you want to raise your hand if you want to speak in favor of formulation 1 or, I'll take one speaker from the council.
Do you want to do that?
Just one speaker for each.
For formulation 2.
Sorry.
Okay.
All right.
Formulation 1, I'm getting confused between the order.
Okay, Ross Rader is prepared to tell me why formulation 1 is better than formulation 2.

>>ROSS RADER: Actually, in everybody's interest, I think we've all heard the merits of each formulation.
Today I'm here to listen to what the public forum says --

>>BRUCE TONKIN: We've seen the (inaudible).

>>ROSS RADER: Then I'll defer to -- yeah, I'm not going to advocate that.

>>BRUCE TONKIN: Does anyone else want to make a statement on formulation 2 at all?
Formulation -- formulation 2.
Do you want to?
Yep, go ahead.

>>MARILYN CADE: What I'd like to do is just explain the difference that I see as a business constituency representative, and I think actually probably as an initial primary drafter of this particular formulation.
As a business constituency representative, we supported 2, because we felt that WHOIS needs to be available to assist in the addressing of problems that involve DDOS attacks, involve network assaults, involve the use -- the misuse of the name, the illegal use of the name for purposes of committing fraud or crimes, et cetera.
And we did not believe that formulation 1 would ensure that the accurate contact details that are necessary to support those contacts would be ensured.

>>BRUCE TONKIN: Yeah.
And I don't understand why.
I guess that's my issue there.
So perhaps, Maria, if you can just put formulation 1 up.
So I understand your objectives.
You want to support being able to deal with things like DDOS attacks and things like that.
How does formulation 1 not allow you to do that.
Yeah, the formulation is back up.
Because it says provide information sufficient to contact a responsible party who can resolve the issues relating to the recording.
So the records themselves are the only way that you would be -- that's the only thing that you can change.
There is no other thing you can change about a domain name.
So I just want to understand why you think that that definition doesn't meet what you've -- you've defined a requirement in terms of a use requirement.
So you've said -- and this is what I'm just trying to flesh this out a little bit -- why you think formulation 1 doesn't allow you to do that.

>>MARILYN CADE: In the extensive discussion and dialogue that we had within the task force, we talked about the limitation in -- the potential limitation in formulation 1 to issues that deal with the configuration of the registration as opposed to, for instance, let's say, that ATT.net -- this is an accurate example which happened a couple of years ago -- ATT.net was, I guess I would say maybe spoofed.
And the name that was being used was used for phishing attacks.

>>BRUCE TONKIN: Okay.
So you said "the name."
Right.
So the only thing you can do about that name is either remove it from the DNS or change its configuration is the only two things you can do.
And that's what formulation 1 says.
So I still am struggling a little bit.
Are you saying that what you really want to do is find the contact party of the Web hosting company?

>>MARILYN CADE: And so, Bruce, you asked me what our purpose was.
What we want to be able to do when we encounter that kind of misuse of a name, is to find the contact information and to either pursue, let's say that the name -- that particular assault involved an infringement of a valid copyright.

>>BRUCE TONKIN: Yes.

>>MARILYN CADE: We wanted to be able to find out who was misusing the name, contact them --

>>BRUCE TONKIN: Yeah, but this is the thing where it's -- the only thing that DNS is is that DNS record.
So I still don't understand.
Do you mean in terms of, say, I could misuse the domain name "AT&T.com" if I wanted to by putting it in the "from" address of an E-mail, and I can use that to do phishing or spoofing as well.
But that would have absolutely nothing to do with me, because I don't have any relationship to the domain name record AT&T.com.
So this is why I just wonder whether this is partly a misunderstanding.
Because everything you described that you wanted to be able to do you should be able to use formula 1 to do.
That's what I'm struggling with.

>>MARILYN CADE: I don't actually agree with you, based on the discussions that we have had in the task force.
Because I want to be able in the event of fraud, abuse, crime, I want to be able to get the details to be able to contact someone who is responsible for the name --

>>BRUCE TONKIN: Which is what that is.
So it says contact details for the person responsible for the name.
So I'm -- I just -- I'm still -- I'm just trying to understand the difference between the formulation.
So everything you've asked for sounds perfectly reasonable.
But then you've said that you don't believe formulation 1 does it.
So I'm still trying to find a situation where formulation 1 doesn't meet the requirements, but formulation 2 does.
So do you want to go ahead, Philip.

>>PHILIP SHEPPARD: Sorry, Bruce.
I think we may be asking the wrong question.
And I think that question may be fundamentally why this task force has come one two formulations.
Because, for me, there's a difference between purpose and use.
And your question just now was relating to subsequent use.
And I think the question that the task force had been addressing was what do you believe is the purpose in today's world of the WHOIS.
And I think that --

>>BRUCE TONKIN: Yep, I agree.
It's --

>>PHILIP SHEPPARD: -- was done fundamentally in order that you can then build from there the various actions that we need to take subsequent to that in relation to the subsequent use or so.
But if we carry on pretending that the purpose of WHOIS is (inaudible) technical, we end up in a whole series of circular discussions.

>>BRUCE TONKIN: I agree.

>>PHILIP SHEPPARD: That don't help in the least.

>>BRUCE TONKIN: I still think that's an assumption you have chosen to make.
Because the word "technical" isn't in that formulation.
It basically says -- because you've got to take -- and this, I think -- you know, my reading of this is a lack of understanding of what formulation 1 means.
Because all -- you have a domain name, and all a domain name is is a name.
It's XYZ.com. And then it has a record which tells what you to look up, which is the name server record, an NS record. And that tells what you other name server to look up, which in turn has other records, which is things like an A record, an MX records, and things like that.
So the only thing that you can control from ICANN, the NS record, and the NS record, in turn, which it probably is outside of ICANN's control, but then goes on to other name servers. And then the only things you can control in there are the records which is A record, Cname records, MX records.
You know, I'm sorry for being technical here.
But I just think there seems to be a lack of understanding sometimes about what the DNS is.
So if you're going to -- all WHOIS is is it tells who you is responsible for that record. And that can be broken down into who's responsible for -- who is the legal entity responsible for that record, who is the admin contact, who is the tech contact, who's the billing contact.
But it's all around the record.
That's all DNS is.

>>PHILIP SHEPPARD: Bruce, underlining formulation 2 is a reflection of things like European law in terms of data protection to activities and other data protection legislation for which you need to first define the purpose of data in order to be able to use it and request it for certain --

>>BRUCE TONKIN: Okay.
So that's a different question.

>>PHILIP SHEPPARD: For certain issues.
If we're starting off saying the purpose of data is only for the configuration of records, then the data protection commissioners are going to say to you, that's fine, guys.
But if you've got a legal problem, if you've got a cyber fraud problem or whatever, that's very nice, but that ain't the purpose you originally collected it for.
Therefore, you can't have the data.
So purpose is not purely a technical question.
It is fundamental to the collection of data in many frameworks.

>>BRUCE TONKIN: You're defining the purpose -- so if we can get at formulation 2.
Okay.
Both of these formulations as they currently stand are talking about the purpose of the WHOIS service.
Now you're talking about the purpose of data collection, which is a separate thing, again, and I completely agree with you.
You're looking at the purpose of collecting the data as opposed to the purpose of the display of some subset of that data via WHOIS service.
So they are different things.

>>MARILYN CADE: The discussion that the task force has engaged in has included the use of the data as well.
I think the distinction -- and I very much support my colleagues.
When you look at -- if the purpose is the configuration as opposed to how you're using it, why you're collecting it, that is a very narrow definition.
And we found that too limiting to support the needs that we think WHOIS is used for today.

>>BRUCE TONKIN: Right.
But -- so do you mean that you see that it's in some way being used as an identity mechanism?
Is it that it serves to identify people as distinct from provide a contact?

>>MARILYN CADE: I don't think that's what I said.

>>BRUCE TONKIN: No.
I'm still trying to understand.
Because you keep reading into WHOIS a lot more than what I can possibly see it can do, yeah.

>>MARILYN CADE: I think what I read into WHOIS is how it's being used today.
And the --

>>BRUCE TONKIN: Right.

>>MARILYN CADE: -- the definition that the constituency that I'm from believes should be the purpose of the WHOIS service is best described to us by a purpose statement that includes the uses of the data for resolving technical problems, dealing with legal or other issues.

>>BRUCE TONKIN: Right.

>>MARILYN CADE: And if it is -- if the purpose is only the technical configuration of the registration records, for instance, that is much too narrow.

>>BRUCE TONKIN: So is that because the issue there is if I configure -- you may not be -- you might be quite happy with the configuration of the records; is that what you're saying?
So you're not contacting them to have anything to do with the records; you're contacting them for something else they're doing?

>>MARILYN CADE: Typically, I would think that the person contacting them about the configuration of the records might be the registrar.
Right?

>>BRUCE TONKIN: No.
No.
Why -- because, normally -- the sorts of things that you're talking about is if a -- a domain name is just a reference point into something on the Internet.
And what you're objecting to, I gather, is, I object to the fact that you're using that name to reference this particular place on the Internet, and I want you to either delete the name or change where it points to.
Because it's -- a domain name is just a pointer.

>>MARILYN CADE: But we're really not talking about the action of the domain name itself in this point.
We're talking about the contactability.
Because --

>>BRUCE TONKIN: The contactability of who, though?

>>MARILYN CADE: Of whoever is responsible for --

>>BRUCE TONKIN: For the record.
Which is what formulation 1 says.

>>MARILYN CADE: -- whoever is responsible for registering the domain name.

>>BRUCE TONKIN: The owner.
Right.

>>MARILYN CADE: The holder.

>>BRUCE TONKIN: But formulation 1 and 2 are the same with respect to that.
It says -- formulation 1 and 2 -- that's why I've separated black and red here -- but the black in both cases is exactly the same.
That's why the difference seems to be subtle.
So the purpose of the service is to provide information sufficient to contact the responsible party or parties.
Is both that part of the definition is exactly the same.

>>MARILYN CADE: We did --

>>BRUCE TONKIN: -- so the only thing is about who can and what they can do.
The first formulation is actually more general, because you've said -- you've just chosen two particular issues and others.
You've said technical, legal, or other issues.
Whereas the previous one just said issues, which includes, because technical and legal are issues.

>>MARILYN CADE: I find this an interesting debate that we're having at this point, because I --

>>BRUCE TONKIN: I'm just trying to -- because I hadn't seen anyone explain the difference between the formulations yet.

>>MARILYN CADE: I think the debate we're having is that I understand what I'm saying and you're telling me that you don't understand what I'm saying.

>>BRUCE TONKIN: I am.
I don't understand what you're saying, yeah.
Yeah.

>>MARILYN CADE: The reason that the black is the same, Bruce, was because within the task force, in drafting, I thought it was better to try to build on language that we had -- could have agreement on.

>>BRUCE TONKIN: In common, right.

>>MARILYN CADE: We had in common.

>>BRUCE TONKIN: Right.

>>MARILYN CADE: So that is why the black language is the same.

>>BRUCE TONKIN: I understand that, yeah.

>>MARILYN CADE: And -- but I think that the major difference, and KIYOSHI, and Tony, who were both on the task force, and Maggie as well, who may want to comment on this, is that within the discussion that we had on the task force, we were hearing from our colleagues on the task force that they were seeking a purpose statement which would be very limiting and that we felt did not meet the needs of users of the Internet as we experienced them.

>>BRUCE TONKIN: Right.
Yeah.
I understand that's the --

>> Actually --
(Multiple people speaking simultaneously.)

>> ROSS RADER: The discussion that we had in the task force wasn't that we were seeking a purpose that was narrow and limiting, but simply one that was appropriate for ICANN's scope and mission.
And it's a very, very different statement.

>>KIYOSHI TSURU: Bruce, can I join the queue, please?

>>BRUCE TONKIN: Kiyoshi, yes, and then Tony.
I'm interested in the comments of people in the audience.
But I just thought it was useful to try and just flesh out a little bit what some of those subtleties are, because, otherwise, the average person would look at the two and think they were similar.
So Kiyoshi, and then --

>>KIYOSHI TSURU: Maria, could I please ask you to go to your conclusions in your PowerPoint.
Before that.
Before, before.
Another one.
Another one.
You had one slide regarding the quote, unquote, actual use of the....

>>MARILYN CADE: Kiyoshi, are you looking for the materials that were in the task force initial draft?

>>KIYOSHI TSURU: The one which is -- there's a slide that says something like, formulation 2 response to the actual use of the WHOIS.
There you go.
Sorry about that.
Thank you.

>>TONY HARRIS: Could I speak, while you're looking at this?
Mine is very short.
Just for the sake of time.

>>BRUCE TONKIN: Yes, go ahead.

>>TONY HARRIS: Just a reflection.
I'm reflecting on formulation 1.
And I may misinterpret it, but my impression is that if that becomes the rule of law or a bylaw or guidance policy towards what WHOIS will look like in the future, basically, I don't have to identify who the owner is.
I mean, we can argue about whether the owner's data should be exhibited on --

>>BRUCE TONKIN: That is correct.
Yes.

>>TONY HARRIS: Who's the owner and WHOIS to me suggest who is is the owner of the domain name.
All the rest comes afterwards.

>>BRUCE TONKIN: But form formulation and formulation 2 have that same issue, Tony.
But you are correct --

>>TONY HARRIS: I don't know, because formulation 2 speaks about the registration, not about the configuration of the records.
If you speak about the registration, then I think implicitly --

>>BRUCE TONKIN: Let's have a look at formulation 2.

>>TONY HARRIS: I've got it here in front of me.

>>BRUCE TONKIN: I have it here in front of us.
(Multiple people speaking simultaneously.)

>>BRUCE TONKIN: It doesn't say the owner.
You said that you wanted it to be the owner.
If you read the first in black, it just says a person sufficient to contact a responsible party.
I think what you're saying is you want it to be information of the legal holder of the domain name license.
I think you'd want to change the wording if that's what you want to achieve.

>>MARILYN CADE: I don't think it's --

>>TONY HARRIS: It could be, but --

>>MARILYN CADE: I don't think that's all we want to change, though.

>>BRUCE TONKIN: Kiyoshi.

>>KIYOSHI TSURU: Maria, can we go back to your...
Thanks.
I think this is a very synthetic slide, and I think this is where the difference between one and two lies.
It's definitely purpose.
Concept of the purpose of WHOIS has been around since the beginning of the task force, and task forces, and then again a task force.
And the working group for regarding accuracy.
So I think I agree with Philip in that, really, the principle and concept underlying these discussions has been purpose. And what Formulation 2 adds is this purpose of how this tool is going to be used, taking into account how it has been used in a legalcy sense. So I agree with Philip. It's purpose.

>>BRUCE TONKIN: One thing you might want to consider is whether you want to be specific about the purpose of the data collected versus the display of data. But I recognize that you are focused on purpose, yeah.
They are different things, by the way.

>>KIYOSHI TSURU: Our point is it's not just the collection of data. It's how -- how -- what the purpose of the tool is, what it has been.

>>BRUCE TONKIN: The WHOIS tool, yeah. Yeah, I understand.
Norbert.

>>NORBERT KLEIN: If there is this need to have certain clarification, I think this is exactly the point. There are reservations against the formulation tool, because we are -- you say we need clarification. The version two says just "and other issues." And this opens this formulation.

>>BRUCE TONKIN: Can you pull the version two back up?

>>NORBERT KLEIN: -- somewhat without limits. What kind of use. The use also shows up as a term, too, is here.
When I think back of the history of ICANN, we had, time and again, to struggle with this question of mission creep, of ICANN going into regions which are not actually our original purpose. And, therefore, just to argue with what is happening now I think is not a sufficient basis to say what should happen now.
And I am very much concerned, especially about this formulation of "and other issues" which is really opening possibilities for things which may or may not be in coordination with the basic core values of ICANN.

>>MARILYN CADE: Bruce, before we go on, I do think I agree with the point we are not supposed to be debating with ourselves. I answered questions earlier. I need to point out we have people at the queue.

>>BRUCE TONKIN: Yes, mark. Go ahead.

>>MARK McFADDEN: I was wondering about that (inaudible).

>>BRUCE TONKIN: It was a long answer to the question, but I thought we hadn't really answered the initial question. I was really answering the GAC's question which is what is the difference between the two.

>>MARK McFADDEN: I was going to ask Maria if she could put up the formulation I had in my mind
[ Laughter ]

>>MARK McFADDEN: If she could put up Formulation 1, I had a question for Ross.

>>ROSS RADER: Me specifically?

>>MARK McFADDEN: You specifically, Ross.

>>ROSS RADER: And answering on behalf of whom?

>>MARK McFADDEN: Only of yourself. This is as someone who is not a lawyer to someone else who is not a lawyer.
When I read this, Ross, and I know you choose your words very carefully when stuff like this happens, the words that stick out to me are the words "issues related to configuration of the records." This seems like a very, very narrow scoping of what a WHOIS service would actually provide.
The issues that are being addressed are related to the configuration of the records.
And when I think of configuration of the records, what I'm thinking is what people are putting into a records and quad A -- what people are putting into the configuration of the records.
And it seems to me that you would use that -- that whoever came up with those words thought very carefully about that choice because that's a very, very narrow scoping.
When I think, instead, about formula two, I think --

>>BRUCE TONKIN: Formula two, please.

>>MARK McFADDEN: I think that what's the words that are in red there are -- more broadly reflect the way the service is actually used in the real world. And the reason I ask you this question is because I know the care you take in terms of picking these words; is that there's clearly a much broader feel to formula two than the words "configuration of the records."
And one of the things you said very early is one of the differences between formula one and formula two is the relationship between the way those words reflected ICANN's mission and scope.
And so I finally got to the question here.
How does the very narrow configuration of the records formulation get closer to the mission and scope of ICANN than the -- identifying the person who can resolve technical, legal and other issues, get to the mission of ICANN? I guess I am responding to a remark you made before. And I'll listen here because I'm sure I'll have a follow-up question.

>>ROSS RADER: The first question that you didn't ask but there was an implication there, I actually didn't write this language. This is a consensus view of a number of parties.
I think I was responsible for the seeds of the initial draft, but it certainly isn't just my words that you see there.
The relationship between this language and ICANN's scope and mission are very -- very, very direct, in that ICANN is an organization that is responsible for the coordination and management of the domain name system.
This formulation comes out of one of ICANN's supporting organizations, the GNSO.
We're responsible for making policy recommendations as it relates to generic top-level domain names in that name system.
We can't seen to be making policy recommendations of a legal nature around general nature, around content, around intellectual property concerns, et cetera, outside of the scope of the name system.
There's a lot of different things you can use names for. You can use them to set up a mail server and manage mail for a domain. You can use it to set up a Web site.
But the scope of those services, the Web site, the mail service, are really outside of ICANN's scope of responsibility. There is no capability of ICANN to pass policy on how you should manage a Web site, what font you should use, what colors you should use. The web might be a prettier place but it's certainly not within our scope of capability.
So what you see, the language you see here, is our consensus view as to what the best representation of the current state and the future state of WHOIS might be, recognizing that ICANN's capability to make policy is, in fact, a very, very narrow set of considerations.
We don't have a lot of scope to begin with.
So that's really what you are seeing here, is our best pass at giving as much capability around contactability, recognizing that ICANN can't be all things to all people at the end of the day.

>>MARK McFADDEN: Okay. And let me follow up, then, and thanks for that. That made a lot of sense to me.
Here is my reaction, and this will be to the whole council, then. When I look at the difference between Formulation 1 and two, what I see is a difference on the council between what is in scope and what is not in scope in term's of ICANN's mission.

>>BRUCE TONKIN: If I can just stop you there. It's not yet on council. It's a disagreement of the task force.

>>MARK McFADDEN: As an open meeting of the council, I'm saying that, and broadly based on my experience with the GNSO council.
That much said, what I'm going to do is disagree with Ross and say that I think that the broader scope that is reflected in Formulation 2 is definitely in scope. And the reason I believe that is in the initial words of the formulation, is that what we are trying to do is to describe the purpose of the service. It's not the data collection activity of the service. It's not the restrictions of how that data should be used. It's the purpose of the service.
And the definition should reflect how the service is going to be used.
That's a very broad reflection, and I think Formulation 2 does a better job of explaining it than Formulation 1.
Thanks.

>>BRUCE TONKIN: Thank you, Mark.
Other comments? And by the way, I thought that was a good question as well. It's another way, because Ross declined to give his reasons. I would have asked him the same question.

>>JOHN BERRYHILL: As someone with both a technical background and a legal background --

>>MARILYN CADE: Who are you?

>>JOHN BERRYHILL: I'm John Berryhill.
As someone with both a technical background and a legal background I would like to echo the concern about what other issues are aside from technical or legal issues. Are they political issues? Are they religious issues? Are they psychological issues? I guess we all have issues, but if they are not technical or legal, I don't know what they are.
And I am concerned that some of the rationale supporting Formulation 2 reflects a profound misunderstanding of how some of the legal issues are resolved.
One of my clients is a major European bank and I do phishing take-down for them. And what's important in those situations is minutes count. And what you have to do is you have to get to the configuration records, find out where the host is, identify a physical piece of equipment in the network, get to the person responsible for that physical piece of equipment, and get them to take it down.
The same thing is true under U.S. law with copyright enforcement. Under the digital millennium copyright act, there is a rapid take-down procedure which has nothing to do with who owns the domain name but in identifying a physical piece of equipment that is hosting a Web site. And none of that is in WHOIS to begin with.
And particularly with phishers, there's no one who is engaging in identity theft who is giving their home address and telephone number in WHOIS records.
What I have found in chasing various phishing gangs through several countries around the globe is that they will do this serially. Once they have obtained the information from a phishing attack, they will then assume the identity of one of the people whose identity records they have stolen, use the stolen credit card number, their identity, to register another domain name.
And I have seen people who are new to phishing take-downs waste valuable time on the WHOIS record because they found, A Ha, I have a real person with a real address and a real identity who used a real credit card. And the phishers are sophisticated enough to use their very own identity theft schemes to throw off people who believe that it's as simple as looking up WHOIS and sending the police to the proper door. And by the time that happens, they move on to the next one.
It's what needs to be done, particularly in the criminal context, is getting to the configuration records, finding physical pieces of network equipment, and taking effective physical action in the real world rather than chasing around this concept of a, quote, "owner" of a domain name, which itself raises legal issues that are unresolved in many jurisdictions as to whether or not a domain name is property subject to ownership or the incident of a service contract.
Thank you very much.

>>BRUCE TONKIN: Thank you, John. Any other comments?

>>GREGORY MILLEN: Gregory Millen. I work in marketing, in the CRM field.
I would just like to comment on this chap over here's comment.
You touched on the purpose of it.
What I see here in a very simple way is almost like a dog tag that can be found. And I think it's access to the information that is quite fundamental. Who has access and who has the right to access it.
So I'd like to more see it in a three dimensional way rather than, at the moment, it's very two dimensional, if you can follow what I mean.
Thank you.

>>BRUCE TONKIN: Thank you.
Any other comments?

>>PETE BECKER: I'm Pete Becker, and I just wanted to raise a point that was brought up briefly before which I think is very important in this analysis, and that's that the formulation of ICANN cannot function in a vacuum. But the purpose that is attributed to the WHOIS data by ICANN will be looked to by European governments in particular as being determinative of what that data can be used for.
And the analogy I have heard drawn would be that if the motor vehicle department issued license plates to cars and their documented purpose for that function was to collect taxes and enforce traffic laws, then under some of the privacy regulations, if the police identified the get-away car in a bank robbery by its license plate, went to the Motor Vehicle Department and said, "Please let us know whose car this was so we can arrest bank robbers," "Well, was the car illegally parked?" ''No." "Did it speed?" "No." "Well, in that case, it wasn't violating any traffic laws and your request is outside our purpose of enforcing traffic laws. Therefore we cannot give you that information."
This seems to be a nonsensical result.
Thank you.

>>BRUCE TONKIN: It's a good analogy and the big benefit of this session is it's all being transcribed. So that's very good.
Yes.

>>MAGGIE MANSOURKIA: Sorry. Maggie Mansourkia with Verizon. Let me shed a little light about what went on in the task force because unfortunately the slides had to be shortened and I think that missed a lot of what went on between Formulation 1 and Formulation 2.
If you are going to say that you can use Formulation 1 for any purpose as long as at the end of the day you are getting to the configuration, I think we could all agree that that's fine.
But in fact, the discussion that went on was you have two options. One is you only use WHOIS information when your name does not resolve.
So if you are trying to search for phishing issues, as the other gentleman, John Berryhill mentioned, that would not be allowed.
If you have your ISP and you want them to resolve some kind of DOS attack, that would not be allowed.
So all of these things are important, and I think it's disingenuous to claim that formula one doesn't have any legal or policy implications because I think it does. And the supporters of formula one always went into these descriptions of how WHOIS information is used for political reasons -- I'm sorry, not Formulation 1, but WHOIS information is used for political reasons and it's used to stalk people and things of that nature.
So there are definitely legal reasoning and rationale that they brought into their side of the debate as well.
So I think it's all in the interpretation, but, Bruce, if the interpretation you have would include all of these other matters that we think WHOIS is important for, then there wouldn't be any disagreement.
But there's very much a difference between the view there.

>>BRUCE TONKIN: I am just react to go what I am reading and that's going to be the final formulation if that's what Formulation 1 is. So it's up to you.
Are you a lawyer by training?

>>MAGGIE MANSOURKIA: I am.

>>BRUCE TONKIN: You tell me. I am not a lawyer. I just read stuff as an engineer. That has a particular meaning to me. But are you saying that reading that, which would be the formulation, does that --

>>MAGGIE MANSOURKIA: Which one? Formulation 1?

>>BRUCE TONKIN: Yeah. Because it doesn't limit issues to technical, because I heard someone say that it's only technical issues, but it's not. That just says issues.

>>MAGGIE MANSOURKIA: Yeah, and I guess that brings up a problem with the task force in itself, because those who supported Formulation 2 didn't have any input into the wording of Formulation 1 and vice versa.
So maybe if we all take a look at everything and everybody's language, then we can start to add in words that would make me support Formulation 1, or vice versa, and make Ross or others support Formulation 2.

>>BRUCE TONKIN: And that's what we are trying to do. We are trying to reach consensus. One of the reasons I am pushing hard on this is because the task force couldn't reach agreement, but there were people on other side. Now it's coming to the council, so let me explain, what happens next is the council will vote on these two formulations. So I want to be clear as a council member that I understand the difference.
Because at a quick reading, they look pretty much equivalent to me. In fact, one is written by an engineer and one is written by a lawyer. That's probably the only difference I can see between the two as they are currently drafted.

>>ROSS RADER: That's twice you have accused me of being an engineer this week.

>>MAGGIE MANSOURKIA: I was going to say, no one can accuse Ross of not being a lawyer. Never.
[ Laughter ]

>>BRUCE TONKIN: So any other inputs? But I think that helps sort of understand the thinking and why you have not supported Formulation 1. And I just wonder whether a lot of this has to do with perceptions based on a whole lot of months and months of discussion. Whereas at this point the council has to decide on just those words, because that's what would end up being the formulation.

>>ROSS RADER: Just for the sake of the record, I also wanted to make a small correction to one of the things that Maggie had mentioned in that the creation of formulation number one was actually open to all participants of the task force who were on a subcommittee working list and the invitation was open to all comers. So it wasn't that there was no input requested or allowed from anybody but that was participating in this small group. It's just that others chose not to.

>>MAGGIE MANSOURKIA: No, that's right. And I didn't mean to imply I was left out of formulating anything. But I knew what it was about Formulation 1 that I disagreed with, so my focus personally was on drafting a statement that I did agree with and I did feel served the needs of ISPs.

>>BRUCE TONKIN: Marilyn.

>>MARILYN CADE: I have a question but I want to make sure that no one else in the audience wants to speak about WHOIS.
Here is my question. We do have a -- we probably should try to respect, as much as we can, a hard stop. Our hosts have done a fair amount of effort to organize. We have a couple of incredibly important issues, I think. And I would ask, Mr. Chair, if we might perhaps move to the other policy issues.
And then if we need to come back to WHOIS and if we have time, since this is public comment, it's not the decision of the council.

>>BRUCE TONKIN: I think if it's a discussion among the council, we can wait until the council meeting. The only reason I was asking is just to give enough information for the audience to be able to interact with what we were saying.
So perhaps if you want to hold off until the council meeting or did you want to speak now?

>>NORBERT KLEIN: If I may make a short comment.

>>BRUCE TONKIN: Sure.

>>NORBERT KLEIN: I was not yet hearing any response to this question that what is important in law enforcement is to find the physical piece of equipment. Maybe I misunderstood the story about the bank robber, but not all bank robbers have the correct license plate on their cars when they rob the bank.
And I think this is really part of the discussion also between the two groups. Which of the records really leads to the physical piece of equipment which is committing the crime, and in what way to achieve it -- to achieve the way to this place in the most fast and in the most legal way.

>>BRUCE TONKIN: Yes, Marilyn.

>>MARILYN CADE: I guess I'm going to feel compelled to respond to Norbert.
Yes, getting to a physical piece of equipment is important. But in cooperating with law enforcement, in dealing with crimes and misuses, you also very often have to take action against the perpetrator.
So there's the immediate response of trying to get an attack stopped, and there is the problem with trying to identify and deal with a person who is a repeat offender.
And we find in using the data, we use both the IP information in looking for the physical, the hardware and the network, and we also use the contact information.

>>BRUCE TONKIN: Okay. All right. I think we should then go onto our next topic unless there is anyone else from the audience who wishes to comment on this.
One more.

>>ALICK WILSON: Bruce, Alick Wilson.
I have a question about process.
I was on council for some two and a half years, as most of you will remember, and I guess my question about process of WHOIS is how well does council think it is doing in terms of meeting the required time frame for policy development on WHOIS?
I I'm mindful that council is in the process of being reviewed, so I guess before I am interviewed by the LAC tomorrow, it would be helpful in my thinking if I knew the answer to the question I just asked.

>>BRUCE TONKIN: We are not meeting the PDP time line.
Okay.

>>BRET FAUSETT: The WHOIS task force was chartered just at the Carthage meetings in November 2003.

>>BRUCE TONKIN: So it's not as bad as you thought. Is that what you are saying, Bret?
(Laughter.)

>>BOB HUTCHINSON: My name is Bob Hutchinson, and my comment is I have used the WHOIS records many times for resolving legal issues, and I would like to see them retained in their current form or enhanced.
Many times when informing is used incorrectly on Web sites, it's convenient to contact them and they remove it. It's very simple.

>>BRUCE TONKIN: So both formulations support that objective. Let's be clear. I think sometimes, there's some perception that suddenly people are trying to stop you doing your job. I don't think that's true.

>>ROSS RADER: One thing, Bruce, I was hoping to make clear for the record is when we're hearing from participants of the constituencies versus participants in the general public at large, and I just wanted to ask both Bob and Pete what their affiliations or organizational interests were. In other words, who do you work for or....

>> Bob Hutchinson: I work for a company called dynamic ventures, and we build Web sites and back-end software for U.S. corporations, primarily.

>> Pete Becker: I am in the IPC and work with Microsoft.

>>MARILYN CADE: While you are finishing, we might see if we have anybody else who wants to comment?

>>BRUCE TONKIN: From the audience or the council?

>>MARILYN CADE: I was looking at the audience.
The public.

>>JOOP TEERNSTRA: I am Joop Teernstra of ICANN at-large.com.
Thank you. I had to question whether the council feels that the input of the at-large public, the domain name holders themselves, has been sufficient so far to come to a proper judgment about what the opinion is among domain holders with regards to WHOIS.

>>BRUCE TONKIN: Is that a question for the council?

>>JOOP TEERNSTRA: It is a question for whichever councillor would like to address this issue. I would like to hear it.

>>MARILYN CADE: I wonder if it would be helpful to explain what our process of taking input is.

>>JOOP TEERNSTRA: The process is you have asked for public input.

>>BRUCE TONKIN: Can I just clarify. Is your question has the ALAC been able to provide input or --

>>JOOP TEERNSTRA: No, no. It's a little bit broader because I know you have gotten input from the ALAC and I know you have gotten input from all the other different kinds of sources.

>>BRUCE TONKIN: Yes.

>>JOOP TEERNSTRA: What I would like to hear is that the council is satisfied about the representativeness of all this input from the different sources.

>>BRUCE TONKIN: Okay, yeah.
So the question there is I guess in many ways, the GNSO consists of constituencies that often consist of domain name holders, and then what you are probably trying to talk about is you are thinking -- you, an individual domain name holder, as opposed to a corporation? Is that what is your focus?

>>JOOP TEERNSTRA: Yes.

>>BRUCE TONKIN: So let's take individual name holders.
There's two mechanisms for them to contribute. One is as a member of an at-large organization, and then hopefully the input there is structured in some way before it comes to the council. And the other is through the public comment process.
So both -- well, at all stages of the WHOIS development, both in the initial call for comments as well as the comments on these formulations, individual domain holders can contribute.
Of course, it's an issue of whether they are aware that they can contribute, is probably a separate issue. Like, in other words, how widely the opportunity to comment has been advertised. But the mechanism of perceiving input for individual domain name holders is either through the at-large organization or through individual comments submitted through the public comment process. Does that answer the question?

>>BRET FAUSETT: Bruce, could I respond to it as well?
I think we all know that Joop was very involved in trying to create an individual constituency for the GNSO, and I think it's still an issue that ought to be very high on the GNSO's priority list.
And I would note that both the GNSO and the ALAC are under review this year.
And so I think trying to figure out a way to increase end user input into both the GNSO process and the ALAC process and the whole ICANN process now is a very good time to get that into the London school of economics people and other folks.

>>BRUCE TONKIN: Yes.
So the option's there.
I don't know whether it's even the GNSO that would make that decision.
It's -- there's a process in the bylaws for a constituency to be proposed, and I believe it's the board that decides on that rather than the council.
So the council just basically responds to the constituencies that it's constructed with.
And it's not just individual users.
Any group that -- of entities can put forward a constituency.
And I believe the board can decide to add it or not.
Yeah.
Yeah, go ahead.

>>ROSS RADER: I think to more directly answer the question, Joop, from my perspective, I heard a lot in this task force from commercial interests of all shapes and sizes in different sectors, the registrar sector, the user sector, the commercial user interests.
We heard a lot from governments.
We heard a lot from legal interests, lawyers and so on.
Certainly the ALAC and the noncommercial users constituency had their fair share of advocates at the table.
I don't think, though, if you asked me the question was I satisfied with regards to the amount of input we received from individual users, that I could say categorically yes.
It was certainly nowhere near the amount of input that we saw from those other factors or factions or groups.
And certainly the level of advocacy that those other groups had at this particular -- or through this particular process far overshadowed that of the individual users.

>> JOOP TEERNSTRA: Thank you very much for addressing that.
Thank you.

>>BRUCE TONKIN: I'm just in the process of -- sorry, Jay.
Go ahead.

>>JAY WESTERDAL: Oh, okay.
Jay Westerdal with Name Intelligence.
Part of the registrar constituency.
I'd just like to get up and say that WHOIS records are extremely helpful.
And I wouldn't want to take away from that.
That they should retain the ownership information of the registrant --

>>BRUCE TONKIN: Yeah, they don't currently have ownership information required.
So you're saying you'd like them to have ownership information?

>>JAY WESTERDAL: The registrant is required.

>>BRUCE TONKIN: I don't think so.
Check the rules.

>>JAY WESTERDAL: I'm pretty sure registrant is required.

>>BRUCE TONKIN: Yeah.
I'll check on that.
But -- because that's something that's important, yeah.
It's certainly not in the formulations at the moment.
But -- So you want the legal -- just clarify that for me -- the legal name of the registrant --

>>JAY WESTERDAL: The legal owner of the domain name.

>>BRUCE TONKIN: The legal -- the name of the legal owner.

>>JAY WESTERDAL: Sure.

>>BRUCE TONKIN: The name of the legal owner of the domain name.

>>JAY WESTERDAL: Yes.

>>BRUCE TONKIN: Okay.

>>JAY WESTERDAL: When possible, the actual contact information for the legal owner, or their administrative contacts.
It should really be up to the end user how much level of detail they want to put in there.
There's obviously free speech sites that don't want to have their end information covered.
And I think there's privacy services right now that are perfectly adequate.
But I wouldn't want the -- any consumer to be, basically, shortcutted at the registration process and not have, by default, their ownership information being shown.

>>BRUCE TONKIN: Okay.

>>ROSS RADER: Bruce, if I may, may I ask a follow-up to Jay?

>>BRUCE TONKIN: Sure.

>>ROSS RADER: Jay, when you're referring to the ownership, you're referring to the registrant?

>>JAY WESTERDAL: I am.

>>BRUCE TONKIN: The use in the agreement says name holder, I think.
But it's the same thing.

>>MARILYN CADE: And, in fact, that is the term, right, because there's no such thing as domain name --

>>BRUCE TONKIN: Exactly, yeah.
Owner is kind of a general term that's used.
But -- yeah, it's name holder, I think.
Yeah.

>>RON ANDRUFF: Mr. Chairman, Ron Andruff, Tralliance Corporation, the dot travel registry.
I just wanted to bring on to the record as the -- I understand the GNSO is reviewing PDP on gTLDs.
And as this topic is somewhat related, in fact, very importantly related, I wanted to point out that sponsored top-level domains, in fact, enable an absolute pristine WHOIS database from the point of view of all of the data is checked by human beings, so that we can make sure that as people move forward, that if you're looking for finding out who is that person that owns that data or owns that Web site and so forth, we can categorically say that they've been reviewed and that their street address, telephone number, all of those things, are absolutely 100% accurate.

>>BRUCE TONKIN: Can I just ask you a question there, Ron.

>>RON ANDRUFF: Please.

>>BRUCE TONKIN: What happens if someone sells a dot travel name?
Are they transferrible?

>>RON ANDRUFF: It is transferable.
And then, again, they have to reregister immediately so that the WHOIS data set is exactly 100% correct.

>>BRUCE TONKIN: So they have to be reauthenticated.

>>RON ANDRUFF: Exactly.

>>ROSS RADER: Sorry, Ron, one more question.
The human authentication of the data, is that a function of the sponsorship status of the registry operating or is that a function of the business model you've employed?
In other words, is that a requirement for all sponsored registries or was that a business decision.

>>RON ANDRUFF: It's a business decision we made.
And, in fact, has proved extremely effective, because what's happening is, every association that is an authentication provider can also clean up their data set to make sure that the information is correct if there's anything missing.
And on the other side, if it's not coming through an authentication provider that's an association, it's come through D & B, which is a global records check organization.
So, in fact, what we're talking about is making sure it's a very high level of authentication.

>>ROSS RADER: That's great to hear.
Thank you.

>>GRANT FORSYTH: Bruce.
Hello.

>>BRUCE TONKIN: Go ahead, grant.

>>GRANT FORSYTH: If I might just interpret something from Ross's question.
I think the distinction that Ron was making there is the fact that, as you have noted and as he has -- Ron has confirmed, as a sponsored gTLD, they can choose in their business model, the community can choose, to undertake the verification which Ron has explained.
Whereas in an open, unrestricted gTLD, one couldn't seek to have that.

>>ROSS RADER: I think that's a matter for discussion, Grant.
I believe that any business is allowed to make certain decisions around its business model.
And the fact that that is not something that's mandated through the sponsorship agreement, I think Ron made that quite clear.

>>GRANT FORSYTH: Perhaps I'm getting confused between new and existing.
And I'll stop at that point.

>>BRUCE TONKIN: Yeah, go ahead, Ken.
I'm just trying to get my computer organized for the next part of the talk.
So go ahead.

>>KEN STUBBS: Excuse me, yes.
I have two questions, if I could, Ron.
First of all, you referred to D & B.
Does D & B do the checking for applicants who are not members of specific trade associations?
Suppose my mother and father had a bed and breakfast and wanted a dot travel domain and weren't a member of, let's say, some regional travel organization.
How would you verify the information there?

>>RON ANDRUFF: That is correct, it's through D & B.

>>KEN STUBBS: The second question is this: Is not the requirement for the information verification process one principally designed to ensure that the person who is registering you is in fact a member of the travel community as opposed to -- I mean, in other words, in order for me to get a dot travel, I have to be able to be verified that in fact the function of the service I'm performing is within the scope of your -- the community you serve.
Is that not the reason for that?

>>RON ANDRUFF: That's -- that is one reason.
And the second reason is, we actually verify at two levels.
So if, for example, you have Ken Stubbs bed and breakfast and you want a dot travel domain name, we want to make sure that we have your information exactly correct, your street, telephone, all the rest of the relevant data for contact information.
But then you would also have to submit a documentation that demonstrates you have a legal claim to Ken Stubbs bed and breakfast dot travel.
That would be your document that you might file with the state of Florida, so when you have actually taken your -- established your company, you would send that documentation in.
So we not only authenticate your address and so forth, we also authenticate your name, so that you have -- actually can only claim a name you have a legal right to.

>>KEN STUBBS: Okay.
I guess I'm just one more step and I won't bother you anymore.
You say we need this information so that we can -- I thought that -- aren't you using ICANN-accredited registrars?
Do you have the ability to directly contact your registrants and deal with them?
Or do you have to use -- deal through registrars?

>>RON ANDRUFF: We deal through registrars.
What happens is the first step is they have to be identified as in the industry.
They get a unique identifying number.
They go to the registrar.
And the registrar takes over from there and registers the name.
Thank you.

>>BRUCE TONKIN: Okay.
So the next PDP that we're working on is the new gTLD PDP.
And I will -- and we are also sort of referencing that as December '05.
This is so when someone asks us how long we're working on it, we can immediately answer the question, since December '05.
One of the things that we discussed before getting into the detail of the PDP is try to identify which of the ICANN core values were most relevant.
And one of the requirements of the GNSO, that it considers the core values and balances the values with respect to the PDP.
So these are sort of the three ones that were talked about by the group.
One is obviously related to stability, reliability, security, and interoperability.
The second one is saying, where feasible and appropriate, depend on market mechanisms to provide and sustain a competitive environment.
And seek a broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet.
So one of the things we did for this PDP was that we -- not only did we advertise on the ICANN Web site the existence of the policy development process, but we also advertised in traditional print media, such as "Wall Street Journal," the "Economist," and various other journals.
We received papers from different parts of the world, and we did allow those authors of those papers to address the committee and put forward their views.
So I'll just run through kind of the different items that we've considered so far and where we're up to.
I'll need to be very clear that what we're doing at this stage is working through each item of the terms of reference, trying to identify a rough consensus, and then moving on to the next item.
And then once we've sort of considered all the items, we'll try to put together a final initial report for public comment. And that initial report is likely to have options.
So it's unlikely to have a consensus view at this early stage on a final answer in that initial report.
With respect to the first question, should new gTLDs be introduced, I think we reached a view that, yes, but subject to getting the selection criteria right.
And that's obviously a far more difficult task.
With respect to selection criteria, some constituencies have described their criteria -- for the selection criteria.
And these are just some examples.
That the criteria should be neutral, be objective.
And these are obviously part of ICANN core values as well.
And predictable.
So, presumably, if I submitted an application one month, then I submitted the application again next year and it's the same application, you'd expect to get the same result, which is tending to imply that you're minimizing the sort of subjective ability depending on which people are considering the application.
You would hope that an equivalent group of people that are different would come up with the same answer.
The selection criteria where there was strong support -- and I've bundled these together under the category of "strong" -- strong was typically at least four constituencies as well as support from the nominating committee appointees to council, as well as ALAC.
If there was reasonably strong support being four constituencies or more people, it came into this category.
Some of these were supported by everybody.
In fact, the first one, everyone supported the concept of technical requirements.
And some of these were supported by not everybody.
The first one here, technical requirements, we did give some examples of those.
One was that it should meet IDN standards.
Another is, it should meet some selected set of IETF RFCs, perhaps those very specific to the DNS.
There was the concept that there would be some application fee applied for an applicant for a new TLD.
There's also a debate about whether that would be the same for everybody.
And that, you know, potentially there can be some consideration for applications from developing countries or different parts of the world.
There was discussion about demonstrating financial viability.
This was the subject of some debate, because some were viewing -- we're trying to work out what's a good business, and in which case that's obviously going to be in the eye of the beholder, most likely.
But I think the view at the end of that discussion was that we're particularly looking to see, from a security and stability point of view, is, is the operator or the applicant able to operate that TLD in a way that preserve the technical requirements and also ensures that the registrants in that TLD wouldn't be likely to have their service fail shortly after it went live.
Another thing that was supported by not everybody, but well over half the council -- well over half the committee, was that the new gTLD name would be for a domain space that was clearly differentiated with respect to its purpose from the existing name spaces.
And the particular examples that were given were with respect to some of the recent sponsored TLDs.
And one example was that if we have a dot jobs, there wasn't support for including a dot employment.
But if we had a dot jobs and somebody wanted to have a dot holidays for those that don't have jobs, then that would be acceptable.
Other things that had strong criteria, strong support was use of ICANN accredited registrars.
There was also a concern that if a TLD had a particular purpose, had a particular charter, that there were mechanisms to ensure that those that registered were complying with that charter or purpose and that those that didn't comply, there was some mechanism to address violations.
And there was pretty much unanimous support that they should comply with ICANN policies.
So those are the ones that sort of had strong support.
One of the things that I've asked the staff to do to help focus people's minds and understand what most criteria mean, because, ultimately, when we have developed a policy for selection criteria, the ICANN staff would need to develop an RFP.
And there are several RFPs to refer to in the past.
There was an RFP in 2000 for the first round of new TLDs.
There was RFPs for dot org.
There was an RFP for a sponsored round in 2004.
And there was an RFP for dot net.
So there's quite a lot of material, which included the sort of text that you'd expect to see in an RFP.
So one of the things that I have suggested is that we take the selection criteria that had strong support and create an example of what that RFP might look like so we can see, how would that selection criteria work in practice.
This wouldn't be binding, but it would be something that we could attach as an appendix to the document, similar to the way the transfers report was done, where we had a policy for transfers and an example reference implementation to consider.
So to create this reference, we don't really need to create any new material, because all the criteria that fitted into strong have probably in one form or another been in existence with the previous RFPs.
So we can pull some of that information.
There are other selection criteria which are more in the category of medium support.
And medium is probably roughly about half the committee supported.
And these were -- and interestingly, it was the same half of the committee that pretty much supported all of these criteria.
One was that the applicants must represent a well-defined community.
And registrants will be limited to members of their community.
And this roughly corresponds to the current sponsored concept.
Alternatively, you could say that applicants must establish a charter that addresses a defined purpose.
Wouldn't necessarily have to represent people in a community, but they would need to define a charter that would have some eligibility criteria, and that registrants must meet that eligibility criteria.
Again, they wouldn't necessarily have to be a member of a formal community.
I guess in respect to both of these was that there was the concept of having accurate verification of the registrant's eligibility.
And we've heard an example, dot travel, earlier this afternoon, they do that today.
And another concept here was explaining how the new TLD maximizes benefits for the global Internet community.
Presumably, this would form some form of relative criteria.
And this will be important in a moment when I come to talk about allocation.
One of the things that we need to consider is that assuming we have a number of applicants that pass the selection criteria, how do we process those applicants?
Do we -- and we may find that in any given year, the ICANN organization only has a certain resource capacity to process applications.
And so that would imply that maybe there's some order.
So if they can process ten applications this year, which ten should they choose is one allocation issue.
Another allocation issue is, what if two applicants want to use the same string?
And, thirdly, if we're requiring purpose, what if two applicants want to create a TLD with the same purpose?
So, for example, someone wanted the TLD "vacation" and someone wanted the TLD "holiday," if we're requiring that the purposes be very distinct, then we'd need to do some sort of allocation there.
There's, I guess, a range of use of allocation methods.
Two, I guess, common themes that came out was that -- one theme was similar to the way we register domain names today, on a first-come, first-served basis.
And an objective mechanism to deal with conflict for the same string is one method.
This would work quite effectively with criteria that are all probably in the strong category.
In other words, it's pretty clear whether an applicant should be accepted or not accepted.
And then they would move into a first-come, first-served allocation process.
The second method is to use comparative evaluation.
And that has been, I guess, an approach that has been used to some degree in some of the previous rounds.
Certainly dot net was a comparative evaluation.
Dot org was a comparative evaluation.
Even the round of 2000 was some form of comparative evaluation where you're trying to select an appropriate mix of applicants and also trying to get diversity of applicants in that particular round.
If you're going to do comparative application, you would rank the applications with respect to how well they address the selection criteria, and you might have some absolute criteria, and you might have some relative criteria.
So if we go back to these selection criteria, these are ones that would probably form the basis of relative criteria in the sense that if you're looking at how well does a new TLD maximize benefits for the global Internet community, you could make a judgment on which applicant you thought did the best job of that particular criteria, as an example.
So these two allocation methods the committee was fairly evenly split.
And so, certainly, in an initial report, we would probably then simply invite public comment on those two methods.
The final area of terms of reference we haven't discussed as yet.
And this is where we're trying to understand what the form of the contract would be for a new gTLD operator.
Here, we're really looking in the future.
So in the future environment where there are some more TLDs, what is the right contractual structure?
What things should remain in the contract?
What things should be removed?
And what things should be added, basically?
This is a big issue in its own right.
And we certainly feel that we need to spend substantial time between here and Marrakesh to consider this particular item.
So the process going forward here will be that we'll -- as we're going along in the discussion, we are publishing draft and initial reports.
And they'll be available on the GNSO Web site as we work through each part of the terms of reference.
We will develop a final initial report that will cover all the terms of reference.
And that will be posted on the ICANN Web site prior to the Marrakesh meeting.
And we'll be taking views, I guess, from members of the ICANN community.
And then, ultimately, the GNSO Council will need to vote.
Where we have options, we'll just simply need to vote on those.
If we under up with simply a majority vote on some of these things, then, ultimately, the board will need to make a decision.
If we end up with a supermajority vote, it's highly likely, provided the vote's consistent with ICANN's mission, that the board would accept that.

>>MARILYN CADE: Would you just explain that to our -- what that means, though.

>>BRUCE TONKIN: Supermajority?
Supermajority is defined as 60% of the votes cast by the members in a meeting of council where that vote is taken.
What did I say?
66, yes.
Oh, yes, 66%.

>>MARILYN CADE: And the implications of that are?

>>BRUCE TONKIN: The implications are that if it's a greater than a 66% vote, the board is required to either say yes, or if it doesn't say yes, it needs to pretty much hand it back to the council with reasons why they're having an issue, and we address it.
If it's a less than 66% vote, then the board can exercise its discretion.

>>MARILYN CADE: I'd actually like to ask a question about that.
Because that isn't my understanding.
My understanding is that on any policy, that the -- and we can clarify this.
But my understanding on any policy is that the board must hand it back.
They cannot modify it.
It has to come back to council for any change in either form of policy, but that the difference is that it is only the supermajority that is binding.
Am I wrong in that?

>>BRUCE TONKIN: I won't attempt to answer that, because I'm not the general counsel.
I'll just take that on notice.
But there certainly is a difference between the way whether it's supermajority or majority with respect to the board's freedom of movement, let's say.

>>KEN STUBBS: Bruce?

>>BRUCE TONKIN: Yes, Ken.

>>KEN STUBBS: I don't know whether we have counsel in the audience or not, but I don't know whether or not a policy that's sent up to the board even with a supermajority is binding.
I think that if the board rejects the recommendation, that there may be a voting requirement at the board level in order to reject --

>>BRUCE TONKIN: Right.

>>KEN STUBBS: -- the recommendation.
But I do not believe it's binding.
If we send a policy up and if they voted it down --

>>BRUCE TONKIN: "Binding" is the wrong word to use.
It just is -- it triggers a different part of the bylaws -- how about I say that, to just keep it completely neutral for the minute.
We're certainly not at that point yet that we need to make that decision on this point.
Go ahead, Philip.

>>PHILIP SHEPPARD: Just for clarification, if it's a majority vote of council that goes to the board and the board couldn't do anything that (inaudible), frankly.
If it's a supermajority, 66% vote on council, then the board -- the implication is that the board will adopt that report unless the board itself chooses to overturn that by a 66% majority of the board.

>>BRUCE TONKIN: But the basis for overturning it, I believe, is defined, though.
So their basis for overturning it is that they have to believe that it's not consistent with the sort of mission and core values and things like that.
So it's not really quite as discretionary as it might appear.
They would have to give reasons, in other words.

>>PHILIP SHEPPARD: Absolutely.
And having taken that vote, they have to also say why.
That's also in the bylaws.

>>BRUCE TONKIN: Okay.
Yes.
So that's the process -- I've described the process as far as the council gets.
But I haven't described the process of what the board does, because that's not really my decision at the end of the day.
Okay.
So that's that particular policy development process.
At this stage, I'm open to receive comments from the audience.
But I think we need to bear in mind, just so that there's no misunderstandings, that all of this is very early days, and so we'd really just be in the mode of listening.
So if anyone wants to make any comments with what they'd like to see with new gTLDs.

>>ELLIOT NOSS: Thank you, Bruce.
So Elliot Noss from Tucows.
And I'd really like to speak to this issue on two different levels, form and substance.
I'm going to start with substance.
I'm all -- I'm struck, in general, when we're talking about new gTLDs, and I'm struck, in particular, as you summarized your discussions to date, how absolutely difficult the whole issue of qualification in any form becomes.
Once we put requirements around the process that lead to a beauty contest, that in any way, shape, or form require a council of elders to sit in judgment around the substance of things like good for the Internet community, we are just opening ourselves to all of the problems that we've seen historically.
I would really urge you all -- and I appreciate this is early days, and I appreciate that this will be considered and discussed in the future, to think long and hard about the history of new gTLD allocation to date, about the problems that we've all faced historically, and about the difficulty -- in fact, I'd say the near impossibility -- of trying to judge things that are virtually unknowable.
With respect to form, I think that despite a lot of our best efforts, a lot of the community's best efforts, a lot of the hard work of the people up here's best efforts, the GNSO has historically been less productive than we would all like.
I really believe that this particular issue is and will be a litmus test of the effectiveness of this group to reach a practical consensus and a timely consensus.
And I urge every one of you sitting up there to recognize that this is an extremely important issue for the ICANN community, and, at the same time, an extremely important test of the effectiveness of the GNSO as a policy-making body.
Thank you.

>>BRUCE TONKIN: Thank you, Elliot.
Just as a comment, one of the things that we are trying to do is spend a lot more physical meeting time to work through this -- to make this much progress.
Because we found that the approach of simply having a one-hour teleconference once a month or once every two weeks, it would literally take two years to cover the ground that we have.
So we've had a two-day meeting in Washington; we had a two-day meeting in Wellington earlier this week.
And we're certainly envisaging maybe a longer meeting between now and Marrakesh to really try and at least have something before the community to consider.

>>ELLIOT NOSS: Would it be okay if Ross just submits his points in writing and doesn't attend?

>>BRUCE TONKIN: Well, actually, I've got your comments as a transcript, Elliot.
So Ross will be able to use that when easy asking for travel support.

>>DIRK KRISCHENOWSKI: Okay, Dirk Krischenowski from dot Berlin.
We again came the long way, along from Germany, to New Zealand, to say some words.
And we would say that we are very delighted about the good progress the current new PDP, new top-level domain PDP process is doing and how Bruce and the GNSO are effectively driving this think tank from just some ideas coming from constituencies and others to really good written consensus of the ideas.
And we would love to contribute to this process constructivily.
And we already did it in the last weeks and months.
But there are three points I would like to make today.
The first point is, I know there are a couple of other potential applicants or representatives of prospective registry provider operators here in Wellington.
I think they all should work more closely together to create a sustainable and future-proof outcome of this new TLD PDP process.
And, secondly, just a question.
How can we use technologies like the WIKI technologies to make contribution and collaboration in the new TLD PDP process more effectively?
And the last point I want to make is, it is foreseeable that cultural TLDs like .cat or regional TLDs like dot Asia or dot luck, and local TLDs like dot NYC or dot Berlin, will become a much bigger issue and a trend in the future.
And, therefore, we would like to ask the GNSO to show these communities more effective ways to interact with the GNSO, participate in the new TLD process, and get organized.
Thank you.

>>BRUCE TONKIN: Yeah, thank you for those comments and suggestions.

>>MAUREEN CUBBERLEY: Could I follow up with a question?
Of the speaker.
If you could return to the microphone.
I'm sorry.
I've forgotten his name.
I just wanted to ask you a question.
You talked about the importance of interaction with the constituencies.
And we have certainly seen you and your colleagues in our GNSO Council meetings.
And I wonder if -- what sort of interaction and dialogue you might have had with the registry constituency, given that you've made a recommendation on their level of involvement with the new TLD process.
And I wonder what opportunities you've had so far to consult with and dialogue with the registry constituency.

>>DIRK KRISCHENOWSKI: Since we are not a registry yet, we hopefully will become a registry, we participated in the last two meetings, in Luxembourg and Vancouver, I think, in the constituency meetings. And this time we didn't have the time to participate and give our input because there were other things to do around. The schedules were really tight.
So if you think we should, we will do in the future.

>>MAUREEN CUBBERLEY: That's not my call, of course, but I just wondered what your approach has been, given our work with the new gTLDs.

>>BRUCE TONKIN: Maureen, if I could just provide some clarity, too, because you may not recognize the name, but Dirk did actually give a presentation at the meeting in Washington over the phone, because he has actually submitted a formal paper.

>>MAUREEN CUBBERLEY: So that was with the registry reps here on the GNSO council. They were the ones who heard the presentation, then? The once on the task force, rather?

>>BRUCE TONKIN: I don't understand your question, but we had a meeting in Washington where we invited those that had submitted papers to present their paper. And Dirk presented his paper at that forum.

>>MAUREEN CUBBERLEY: Okay. Thank you.

>>ROSS RADER: Actually, maybe I could ask a slightly different or maybe a clearer version of that question.
So what extent are the views of the registry constituency representative of the viewpoint you are putting forward?
I understand that you are not a member of that constituency as you are not qualified for admission to that constituency, but are they taking your viewpoints on board?

>>DIRK KRISCHENOWSKI: Yes. Since people like you and others have very good ideas and we already had personal talks with you, and we think the registry constituency is going a good direction.
And I think we should stay on personal talks to you. And if you -- we would be delighted if you invite us to contribute a little bit more.

>>ROSS RADER: Thank you.

>>BRUCE TONKIN: Yeah. I think we're very open to as many contributions as you wish to make, basically. The limitations are often forum and timing and so on. But definitely anything written will be taken into account, and we do our best to provide some time for you to present to the whole group that written material, if you like.
And then obviously when we are at these meetings, you are free to speak to any of us.

>>DIRK KRISCHENOWSKI: Okay. Thanks.

>>BRUCE TONKIN: Marilyn.

>>MARILYN CADE: Bruce, I think, actually, that this raises a different and broader question, and that is the -- as we talk about how we plan to make the process visible, transparent, and accessible for anyone who is interested in the process, as opposed to a particular -- right. I think that perhaps we should take on board that question in addressing it. And may even want to revisit ideas such as further calls or comments from a broader community at various stages.

>>BRUCE TONKIN: Yeah, so one of the things that we have been talking about is when we finalize our initial report, which will have different options, I guess, we are going to try to seek the broadest, I guess, advertising of the existence of that report and the importance of it so that we do maximize the amount of input we can receive.
Okay. Any other comments on new TLDs?
Okay.
The next PDP that we have only just commenced in its fairly early days is looking at the contractual conditions of existing gTLDs. This one was commenced in February of this year.
It's worth understanding the background as to how that PDP came about.
Basically, during 2005, the changes to the dot net and dot com contracts had been very contentious in the GNSO community, and this PDP reviews some of the more contentious topics of those current contracts to see if an ICANN policy is appropriate.
The challenge, of course, will be to identify areas where there is strong support for a particular approach, because I think the views are pretty diverse. I know as a member of the registrars' constituency, we heard many points of view just within one constituency, let alone across the GNSO.
It's also important to understand that there are limitations with respect to the implications of the outcomes of the PDP.
Existing gTLD agreements have limitations on which new or changed ICANN policies must be complied with. They have a definition in their agreements, as do registrars, which is the term "consensus policy" and that definition lists the areas where or gives examples of areas where consensus policy can apply to an existing contract but also gives examples of where consensus policy can't change things in an existing contract. And there are some things you can expect, like if I signed a contract for five years and made business decisions on that, you don't expect that to be suddenly changed so it's now going to be one year.
So there are limitations on what type of policy that's approved by the ICANN board can affect an existing contract.
And it should be pointed out that most of the topics of this PDP which I'll cover shortly are likely to affect an existing gTLD operator.
However, if a new ICANN policy is developed as a result of this PDP, that policy would guide the staff in negotiating any changes to the gTLD agreements, and it's probably the changes to the gTLD agreements which has caused a lot of the friction within the GNSO to date.
So with those limitations, the topics that are under consideration are the mechanisms for renewal. Currently, registry agreements are for a fixed term. Some agreements have the concept of -- I guess what's been termed a presumption of renewal. So in other words, as long as they do the right thing, the contract is going to be renewed each year.
There are other registry agreements in place today that have no presumption of renewal. So in other words, it's conceivably possible for ICANN to give the TLD to another operator at the conclusion of the contract.
The things that would need to be considered in this is what's the appropriate length of a registry agreement. How many years should it be for. And what is the process for renewing that agreement.
The next topic is the relationship between registry agreements and the consensus policy definition within the agreement.
Should that definition of "consensus policy" be changed in some way? Is it too limited or is it not limited enough?
Current registry agreements have price controls. There are basically price caps. So a registry can't charge more than is specified in their contract. They can charge less, of course.
And some of the registries do have special promotions where they do charge less than their maximum price. So that's the status today.
But there isn't a policy on that. So this is really just something that's currently in the contracts.
And in the recent .COM contract, for the first time there was a provision that allowed price to increase by a certain percentage for four out of the next six years.
So this is really sort of saying, is it appropriate to have price controls at all? If the market is operating effectively and there's competition, maybe there is no need. Alternatively, there are some in the community who think price controls should remain.
There's the issue of what should the ICANN fees be with respect to registries. Registrars today, once the ICANN budget is developed, they pay a fee that's based on a domain name registration or renewal, and it's currently set at 25 cents a name. So it doesn't matter which registrar it is, whether it's a big registrar with several million names or a small registrar with maybe a hundred names of very high-value clients. They pay the same transaction fee per registration.
Registries, in contrast, have been negotiating a fee structure with ICANN on a case-by-case basis. And certainly we've heard that there's some concerns, whenever you get into that sort of discussion you find with some registries that are doing a few registrations might have to pay several dollars a name and another registry that does very many registrations pays a few cents a name. But ultimately the fee structure seems to vary by registry. And the question is, one of the things that relates to the scalability of adding new gTLDs is that each time the ICANN board says to the ICANN staff, "You are now authorized to negotiate a contract," we are seeing contract negotiation time of months, in some cases into a year. And part of that is because there are so many things up for negotiation.
So one thing that might streamline the process could be to have a few more policies in this field that provide certainty to the registry operator so that that whole process can be streamlined.
Uses of registry data. There is a bit of uncertainty about what data that the registry collects, or the registry collects data directly from registrars but the registry also operates name servers for the top-level domain, and the computers that operate those name servers can collect traffic data. And traffic data would consist of the IP addresses of the people that are requesting resolution for that domain name, for example.
Whether that information is useful or not, but there are concerns that if that data was made available to, say, one search engine and not available to other search engines, for example, that it could create inequities in the marketplace. So there have been some concerns around that.
And then finally, some registry agreements have financial requirements to invest in research and infrastructure and some don't.
Should there be requirements for all registries? Maybe you think there should or should not be.
So those are all topics, and at this stage we are simply asking for people's views on those. Each constituency has been asked to produce a constituency statement, and we're seeking input from the ICANN community in general.
We have extended the period of time for that public input because we recognize these are complex issues, and so we have extended that to the 30th of April, 2006.
And we also recognize that we are most likely going to need legal assistance in terms of explaining how the current contracts work and the implications of some of the current contractual provisions. And we are also likely to need some economic advice on topics such as price controls and whether they are appropriate or not appropriate, or the economic impacts of making a decision one way or another.
So those are quite complicated issues. However, if we look at those issues, they are important also for the previous PDP on new gTLDs in the sense of not only what's appropriate for the current environment but what's appropriate going forward into the future for the next sort of ten years or so with respect to registry agreements.
So are there any questions on that particular policy development process?
Okay. So that is fairly early days, even earlier days than the other one in that we haven't even met to talk about these things.
So we are just purely waiting for the input. And this week, there is a task force being formed to look at those issues. And there is a meeting to elect the chair. So that's how early on that process is in the scheme.
What's next on our agenda? AH, IDN policy.
One of the other things the GNSO has been looking at or has requested a report from staff on what are the issues associated with Internationalized Domain Names.
I have a very short presentation here that I used to stimulate some discussion with the ccNSO because, certainly, the GNSO believes that we need to cooperate and work with the ccNSO in this policy area.
So so far, the GNSO council has requested the ICANN staff to produce a report that lists the policy issues associated with introducing Internationalized Domain Names into the root zone.
One of the things that we're going to do with that issues report is identify the issues that should be worked on first to allow an initial introduction of Internationalized Domain Names strings, much as we did initial introductions of new gTLDs back in 2000, so that we can make some steps forward and provide benefits to users, but do it in a measured fashion.
And so once we have done that, we need to identify who should be involved in addressing each issue. And again, making sure that we have as much broad participation as possible.
I'll just give some examples of issues that have come up so far with respect to IDNs.
One is a fairly obvious one, that current ccTLD and gTLD operators want to introduce an IDN-based string that relates to the TLD. But it's also possible that another party may wish to introduce an IDN-based string that relates to the TLD in competition with the current TLD operator, whether it's a ccTLD or a gTLD.
There's the question of what string does a particular operator get to use. In the past, with respect to country codes, the two-letter, effectively, English string or string containing ASCII characters is taken from an existing standard, which is the ISO 3166 standard. And that's been very easy. So when somebody comes from a particular country, rather than arguing about which two-letter code do they get, it's just simply looking up that standard, seeing what string is in that standard and that's what they are allocated.
But there's no equivalent for characters other than the English or the Latin character set.
Then the question is, if we're looking at a country code operator or even a gTLD operator, how many IDN strings for an existing operator would be appropriate? Would you base this on a number -- if it was a country code, would you base it on the number of official languages or the number of scripts? Because in some languages, there are multiple character scripts used to represent that language.
Then there's the issue that languages and scripts can be used across multiple countries. So the whole sort of issue around countries and strings is far more complicated than it has been to date in that particular area.
Then there's the question about what happens to the domain name. If I have a domain name which we'll just call "label" and it relates to a top-level domain 1, and then in red I use an IDN equivalent of that domain, the question is do these two domain names or labels resolve to the same Internet location? So if I have Bruce.com and there is a Chinese character equivalent of .COM, what happens to Bruce dot Chinese character equivalent? Do they go to the same Internet location or do they go to completely different parts of the Internet? If they go to completely different parts of the Internet, should they be assigned to the same registrant or name holder or is it permissible for different parties to register those names.
If different parties can register those names, then we get into the usual problem of introducing a TLD in the sense of some sort of sunrise process to deal with people that have potentially existing trademark or other intellectual property rights.
And there is the issue of, at the moment, the IDN guidelines suggest using a single script to the left of the dot, so you don't have a mixture of, say, English or Latin scripts and Cyrillic scripts in the same name or mixtures of different scripts.
If you have made that decision, why would you, in fact, try to make the script the same between the left and the right of the dot? So in other words, if I have English script, then that connects to an English script string in the root. And then if you wish to use Chinese script, then that's associated with Chinese script TLD in the root. Or do you allow mixes? And we have today, you can have English or Chinese -- or you certainly can have today a Chinese script dot English script.
The question is should we come up with some policy, and the only reason to do this would be presumably to improve the user experience and try to meet the user's expectations.
You have string conflicts. Two parties may wish to have the same top-level domain IDN string. Who makes the decision? What are the criteria? How do you resolve disputes? This is essentially the same problem as allocation for new gTLDs, so the problem is the same.
So from a policy point of view, we may come up with some policy about who gets to have a new TLD string, which includes an IDN character set. So the selection criteria. How do we deal with contention between strings? What are the allocation methods and what's the nature of the agreement for using new TLD strings? And you can see this is pretty much the same as the PDP we already have underway. The difference is that we're looking at the additional issues that are added with respect to Internationalized Domain Names.
So I have just thrown some examples up. That's not an exhaustive list but it's just to give you a feel that there are some issues to consider at a policy level.
So where does all this work get done? Well, in the current ICANN structure we have the GNSO, which develops policy for gTLDs. We have the ccNSO, that develops policy for ccTLDs. And we have an advisory committee for IDNs that essentially provides advice, tends to have a focus, at least now, on technical engineering issues. And so they are involved in updating the IDN guidelines. They are also looking at creating some technical tests.
These technical tests would have very little impact on any of the policy discussions that I have mentioned earlier. They are merely mechanisms for implementing different approaches, but at a policy level you need to decide what the policy issue is or what the policy decision is, and then the technical community can work out what's the cheapest, most efficient way to implement that technically. And so some of this work is to allow the building of knowledge in the technical community.
So what I have suggested so far is that the GNSO and ccNSO coordinate the policy development work in the sense that we work off the same shared set of issues. We can identify which of those policies we think would allow the timely introduction of some IDN TLDs, really to give benefits to the greatest number of users and also minimize risks. So you may constrain some of these variables I have talked about, so that you can at least do an initial launch by perhaps minimizing the potential legal issues or minimizing the potential technical issues with the intent to perhaps liberalize them or make them more liberal later on.
It's easy to start constrained and widen the number of options than it is to start with a huge number of options that cause lots of problems and then try to manage them.
But clearly we would be seeking advice from the president's advisory committee where we require it.
But ultimately what we should be seeking is a timely benefit for Internet users. Let's try to do something this year to make sure we meet the user expectations and let's ensure we provide a good user experience.
So that's IDNs. So in summary, we have asked for a list of issues, and we would then need to consider how we handle those list of issues.
Yeah, go ahead, Ross.

>>ROSS RADER: Just quickly, Bruce, in addition to the presentation you made to the ccNSO, maybe you could briefly summarize some of the dialogue that happened during that, as follow-up to that presentation.

>>BRUCE TONKIN: Which dialogue? The ccNSO?

>>ROSS RADER: This presentation you....

>>BRUCE TONKIN: I have lost track of who I have presented to and how many times, but I presented this to the ccNSO just to encourage them thinking about the issues that we're working on. This presentation itself was developed after a discussion between the GNSO and the members of the president's advisory committee on Sunday.
The GNSO then had a meeting with the ICANN board where the opinions of the council members and board members were canvassed. I just selected some issues from the combination of those two discussions. I then presented to the ccNSO, and I think they are meeting on this topic, I believe, at this time.
So I don't want to speak for the ccNSO in any way, but generally I think they recognize that I think there's a shared on the to move things forward. That's probably the easiest way of answering the question.
Yeah.
I'm asking anyone who wants to comment on IDNs.
Yeah, go ahead.

>>MARILYN CADE: I might make a comment, and then perhaps people will leap to their feet and rush to the microphone in response.
I think one of the things that's very clear that we have to explore further will be how to understand and address the treatment of place names in all of the PDPs we're talking about.
And just to explain what place names are, for those of you who aren't yet immersed in this, it is the concept, it's the term that we are using to refer to something that might be a lake, or it might be a country, or it might be a city, or it might be a locale, but it has a place connotation to it. And many countries, the treatment of place names has legal issues, even sometimes in country's IP issues.
Sometimes governments feel that they should have oversight over whether or not names are registered or how they are used. While there's no international treaty that affects that issue, it is still a very relevant policy topic. And it seems to me as I was thinking about this that we have such implications in all three of our PDPs.
We have the need to understand the implications in all three of our PDPs.

>>BRUCE TONKIN: Yeah, agreed.
Any other comments?
Okay. The final topic, then, in this session is just to remind everyone that there is a review currently underway of the GNSO. Under the ICANN bylaws, when ICANN was -- came up with the latest version of the bylaws, it was accepted that ICANN, as an organizational structure, would need to continue to evolve and improve.
And, subsequently, all parts of ICANN will need to be reviewed separately, and looking at improving that part of the organization.
The GNSO is probably the one that is the most active and has the longest history in that the GNSO itself arose out of the Names Council or the DNSO, as it was called at the time, which did include ccTLDs in that incarnation.
At this stage, the board has appointed an independent reviewer.
And that reviewer is seeking input from, really, anyone that's attending this meeting here at ICANN.
They've issued a survey.
There's a Web site where you can answer questions.
I don't know if there's anyone -- any of the members of the review committee here.
They're welcome to stand up and be identified.
Would you like to come up and say a couple of words?

>> Hi, my name's Pat Dunleavy.
I'm from the London School of Economics.
And I'm one of three members of the review team who are at this conference.
And we'd be very keen to talk to anybody who might have a view about the workings of the GNSO or the constituencies.

>>BRUCE TONKIN: Thank you.
Are there anyone that wants to make a comment on the public floor on the topic of the GNSO review?
Otherwise, please feel free to contact the reviewers directly.
Okay.
All right.
Well, I think we'll leave it there.
It's getting late in the day, and I know that there's various happy hours and bars available for refreshment.
And there's, then, the dinner that will be held, I believe, at 8:00 p.m. tonight.
So I thank you all for your attendance.
[ 5:48 p.m. ]