ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>PHILIP SHEPPARD: Ladies and gentlemen, good morning. This is the start of the second part of the GNSO public forum and this is Wednesday 28th of March. I'm just going to allow my colleagues to say who they are for the sake of form and any recordings that are taking place for this. My name is Philip Sheppard and I'm chairing this first session and I'd like to start the introductions with my colleague, Avri, all the way over to my right-hand side.

>>AVRI DORIA: Okay. Avri Doria. NomCom appointee to the GNSO.

>>GREG RUTH: Greg Ruth, ISPCP rep to the GNSO.

>>NORBERT KLEIN: Norbert Klein from the noncommercial users committee.

>>JON BING: Jon Bing, NomCom appointee to the GNSO.

>>ROSS RADER: And I'm Ross Rader from the -- ah, there it is. I'm Ross Rader from the registrar constituency.

>>SOPHIA BEKELE: Sophia Bekele from NomCom GNSO.

>>CHUCK GOMES: Chuck Gomes, gTLD registries.

>>ALAN GREENBERG: Alan Greenberg, ALAC liaison for the council.

>>KRISTINA ROSETTE: Kristina Rosette, IPC.

>>JORDYN BUCHANAN: Jordyn Buchanan. Call it outgoing chair of the WHOIS task force. Of the outgoing WHOIS task force.

>>BRUCE TONKIN: Bruce Tonkin, registrars rep on the GNSO Council.

>>MIKE RODENBAUGH: Mike Rodenbaugh, business constituency.

>>PHILIP SHEPPARD: Thank you very much. So the first 10 or 15 minutes or so of this session is an opportunity to talk to Bruce Tonkin, in his capacity as candidate and indeed the one and only candidate for the GNSO election to the board. The GNSO has the opportunity to send two representatives to the board from time to time. We have an election process whereby we have nominations, an election taking place. The election itself is due to take place the 2nd to the 9th of April and this is an opportunity for those here up on the panel and, indeed, anyone in the audience to pose questions to Bruce about this election. Just to kick things off, I thought I might ask a very Vint Cerf-like question, which is: Why on earth would you want to do this, which is another way of saying exactly what is the motivation. So as we launch into this 15 minutes of intense political cross-fire debate, let's go over to Bruce Tonkin to allow us to hear his motivational statement.

>>BRUCE TONKIN: Okay. Is this a statement to motivate me or you?

[Laughter]

>>BRUCE TONKIN: Okay. So as background, I've been on -- registrar representative on the GNSO Council since I think barely 2002. Shortly after I joined the council, I was also elected as chair of the council and I've been chair of the GNSO Council for about the past five years, since 2002.

In recent times, the council has been working on some very significant issues, those being new gTLDs, internationalized domain names, and their potential use as new gTLDs, and WHOIS.

I'd probably rank those issues in order of importance in the order in which I've represented them.

I've come to the view that for this particular election, the current seat holder for the board is Alejandro Pisanty and he's been vice chair of the board for some time and is obviously widely respected in the community. But Alejandro's term finishes in June this year, and he's unable to be reelected as he has reached a term limit from a board director point of view.

I'm also aware that Vint Cerf as chair of the board is also reaching a term limit at the end of this year, and will also no longer be with us next year as a board director.

So my feeling is that now is probably the time to have someone on the board that knows the -- in detail, all the policy deliberations around new gTLDs, internationalized domain names and WHOIS. Particularly at a time where, in the next one to two years, the board's going to be receiving policies from the GNSO in these areas, and I think I can provide value on the board by being able to explain the depth behind the deliberations for those reports, rather than the board just being faced with reading a written report. I believe I can communicate the depth and range of debate on those topics.

Also, from a point of view of history, I guess the company I work for, Melbourne I.T., was one of the first five registrars and has been involved in ICANN since 1999, so I have a fair understanding of all the history of ICANN and have a thorough understanding of the contractual relationships at the registry and registrar level, both actually at the generic top-level domain point of view as well as the country code domain point of view, because the company I work for is also a contracting party with many of the country code operators.

So I guess that's a short summary, Philip.

>>PHILIP SHEPPARD: Bruce, thank you very much. Other questions for Bruce, either from the panel or from the floor?

I'm looking around. Jim?

[Speaker is off microphone]

>>PHILIP SHEPPARD: Okay. That was Jim Baskin from the audience asking position on the three issues that Bruce had outlined in his motivational speech.

>>BRUCE TONKIN: Okay. On new gTLDs, my position is basically the position of the GNSO Council, which is -- which is yet to be formed as yet, but let's -- maybe I should say is the gTLD committee. And that is basically that new gTLDs should be released, and speaking personally, I think the major benefit there is -- or should be towards growing the cultural, geographic, and other forms of diversity in terms of the use of the Internet. I think that should be our objective.

With respect to internationalized domain names, I feel that they should be allowed to be in the root. I don't see -- my technical understanding, from my point of view, means that it should be possible to implement that at the root level just as it currently is at the second level, and I think that's probably one of the most significant changes ICANN can do in the next 12 to 24 months. Is to allow the use of other than Latin scripts at the top level, and I think that will also help that first objective I had put forward with respect to adding new gTLDs. I think clearly increasing the diversity of use of the Internet, I think, means going beyond the use of the Latin script in the -- in the use of the domain name just as we've seen that at -- certainly if you look at Web site content, we already see many different scripts and languages in use in the Internet and if you look at e-mails, likewise. So I don't see any reason why we shouldn't also make an attempt to facilitate that at the top level.

With respect to WHOIS, I think WHOIS -- and, again, just speaking personally -- breaks down into probably three areas. One is that it seems inappropriate to have unrestricted mass access to a resource that can then be used with very little controls for marketing or a whole lot of other purposes, so I think some level of access control makes sense. And I can also see that the natural persons using the Internet for noncommercial purposes do deserve some level of protection from misuse as well. So that at a very high level, that's my view, and I'm happy to, as an engineer, get -- design a solution that I think meets that requirement, but from a board director point of view, I wouldn't attempt to do that.

My role at a board level is really just to take the input, if the community reaches a consensus on a particular position, my view is I would support that consensus, unless there was very strong reasons to go against a community consensus view.

>>PHILIP SHEPPARD: Bruce, thank you for the answer to that. Other questions? Maybe one from myself, really. One of the questions we've always asked candidates going onto this position is: What is the nature of the feedback or the communication that you would give in terms of board activities back to council? I mean it has to be so. We've always had fantastically good reassurances from candidates that we will have superb feedback from there and delivery has been varied. What is your opinion on this?

>>BRUCE TONKIN: Yeah, that is a good question, Philip, and that question, I think, has probably come up a number of times in some meetings I had with GNSO constituencies yesterday.

I think firstly, if I look at the feedback going from the community to the board, I feel that my approach to that would be probably fairly similar to, I think, what Jonathan Cohen had done when he was on the board as well as Michael Palage, in that I would certainly envisage attending council conference calls, provided they're not between sort of 3:00 and 4:00 a.m. in the morning for me. Most other times, I seem to do them already. And with respect to being involved in the physical ICANN meetings, my intent would be to try and spend some time with each constituency on my own, so that I can understand sort of the depth of their views on different topics. Again, I'm not just relying on a written report from the constituency as to what its position is, nor a written report from the GNSO Council on what the GNSO Council's view is.

In terms of providing feedback back the other way, I'm obviously bound by the board confidentiality in respect to what other board members might think on particular issues, but what I can do is certainly identify what are agenda items and seek to keep the GNSO informed of those agenda issues. And I'm also happy to give what my views and feelings are as one director on some of those issues before the board.

>>PHILIP SHEPPARD: Thank you very much. Any other questions for Bruce? Either from the floor or the panel? Avri?

>>AVRI DORIA: Yeah. Thank you, Bruce. I've already had a chance to ask you some questions. This is another one that's sort of occurred to me over time. It is: As a board, you're getting recommendations from SOs, you're getting advice from the advisory committees, you're getting comments from the community at large. I'm wondering how you see the board's responsibility in terms of juggling all of those different views, the fact that you will get the full scale of absolutely yes to absolutely no in some form from an entire community. How do you see balancing that? How do you see weighing the different kinds of advice, opinion, and comment that you get?

>>BRUCE TONKIN: Okay. I think with respect to the -- I guess the strength of those different inputs, firstly, the basis of ICANN is that it's a bottom-up consensus-forming body with a range of stakeholders, and this council obviously shows just the diversity of stakeholders around something like gTLDs.

So if this council can ever agree on something, that's a major feat, and, therefore, if something is coming up to the board and it's come to the council with this such a diverse environment where you've obviously got very strong views from different angles, to actually form a consensus is no easy feat, and if that's been achieved, then that needs to have a great deal of weight.

With respect to advice that we may receive from either advisory committees within ICANN, there's security and stability advice, there's public policy advice from the GAC, there's advice from the end user community, from the At-Large Advisory Committee, there's advice on root server operators from the root server advisory committee. There's a lot of advice that comes through. I think the key thing there is to take that advice and compare it against what the consensus view is, and then if there is something that has -- in most cases, the only scenario I could think of where the board would need to send something back to the council is where the feeling is that the advice has raised some new information that wasn't known at the time the consensus policy produced its position.

And that new information would need to be considered. So I would see that the policy position would be sent back to council saying, "Hey, we've received this new advice. It's a security concern that you may not have been aware of. Can you review that community concern and identify whether you feel the policy needs to be changed in some way to accommodate that concern?"

Ultimately, if you choose to reject the advice, which -- and, you know, I'd still basically say that your consensus position is unchanged, despite some advice that might be contrary to that position, then I think the board then has a pretty high bar, if you like, to then look at that and say, "Okay, the board would really have to say that this is going to be harmful for ICANN as a, you know, fiduciary responsibility or harmful toward the Internet broadly" and so I think you need to -- the board would then have to have strong reasons for rejecting that consensus position after it's gone through that process.

>>AVRI DORIA: Can I ask a follow-up, I guess? Okay. One thing is, I want to make sure on the words "consensus" because we've been having a lot of consensus talk and we certainly have one meaning of "consensus" in the GAC, which means everyone with no opposition. We tend to have a supermajority view of "consensus" within the council and is that what you meant when you said "consensus" from the council or from the recommending body? Or were you looking for a full GAC-type consensus?

>>BRUCE TONKIN: No. I'm looking for consensus as it's defined in the bylaws currently and I think we need to recognize that when you do have many diverse views, it's difficult to reach a hundred percent. But obviously the closer you get to the hundred percent is probably the -- the harder it is to knock back, let's say.

So if it's a bare supermajority at, you know, 66% and you get some pretty strong advice from an advisory committee that goes back to the council and if that's ignored for some reason, then the board, I think, in its reasons, would, you know, obviously need to be very strong reasons to go against that 66 majority, but I think the difference between going against a 66 majority and a hundred percent majority is different. So -- so the level of -- you know, I'd be very surprised if I would imagine the board ever knocking back something at a hundred percent consensus from the GNSO, given it's such a big yardstick in its own right. If it's 66%, I think it would need very strong -- to go against it, would need to have very strong reasons to go against it, basically, but I feel that it would be easy to do that if it was 66% versus if it was a hundred percent. If that makes sense. So obviously you -- I think the board needs to know what that percentage is, and that's taken into account, but whether it's 66 or a hundred, you still need a strong reason to go against it. But if it's a hundred versus 66, the strength of that reason has to be stronger, I think, if that makes sense.

>>PHILIP SHEPPARD: Bruce, thank you very much. I fear the clock is against us and we must bring this particular session to a close. I would like to thank all the candidates for their coherent and extraordinarily consistent responses to the questions that we heard around the table.

[Laughter]

>>PHILIP SHEPPARD: Polling starts on 2nd of April and the usual [inaudible], of course, for all elections is: Vote early and vote often. Thank you very much. Let me hand over to the chairman for the rest of the session, who is Mr. Bruce Tonkin.

>>BRUCE TONKIN: Thank you, Philip. I'm Bruce Tonkin, chair of the GNSO Council.

We are now going to talk about one of our favorite topics, which is WHOIS. And we're lucky to have with us the chair of the -- of the WHOIS task force so I'll just put up a presentation that was prepared earlier this week on that topic and then allow Jordyn to give us an update and then we'll open up for questions on that topic. Okay. Go ahead, Jordyn.

>>JORDYN BUCHANAN: Thanks, Bruce. The WHOIS task force recently completed its work under the PDP and submitted its final report to the -- to the council. And I'm going to give a brief update on the contents of that report, the policy recommendations contained therein, as well as an alternative set of policy recommendations that were supported by some of the constituencies represented.

First, a little bit of background.

For those that are not familiar with the work of the task force, we were chartered by the council to resolve five issues, two of which we have previously completed, so this report doesn't encompass, and those two issues are to first define the purpose of the WHOIS service and, secondly, to resolve an outstanding issue from a previous set of task forces that had nearly been completed at the time the task force was chartered, which was to determine how to resolve conflicts between contractual WHOIS obligations and local or national privacy laws.

Those -- as I mentioned, those portions of our work were completed prior to this report, so this report contains recommendations with regards to three other terms of reference and those are, first of all, to define the purpose of the registered name holder, technical and administrative contacts, so basically we look into WHOIS and we see that these things are there and trying to define -- understand what they mean.

Secondly, to determine what data should be made available to the public and how to access the data that's not available for public access. So the question here is: Today all of the information that's collected and made available for WHOIS is available to everyone through both Port 43 as well as Web-based access and we looked into whether that should change and if so, what data should be provided in various circumstances. And then finally we looked at how to improve the process for notifying registrants of an accurate WHOIS data and the process of investigating and correcting inaccurate WHOIS data. The goal there being to improve the overall accuracy of the data contained in WHOIS based on responding in a better fashion when inaccurate data is brought to the attention of the registrar.

So that's what we looked at for the purposes of this task force and if I could just ask Bruce to look at the next slide.

Our current status is that we've completed our final report, as I mentioned, and sent it to the council. There is a set of recommendations that were -- that formed the policy recommendations in the proposal, and those -- that's something we've been talking about for a number of meetings, actually, called the OPoC or operational point of contact proposal. This was accepted as the majority position, a slim 7-6 majority, and as a result of it being a very slim majority, the bylaws asked that the report also includes the views of any other constituencies that don't support the majority position, and so there is a second set of recommendations that's also included, and this is called the special circumstances proposal and it's supported by three of the six GNSO constituencies.

So a brief summary of the recommendations that make up the OPoC proposal, which form the policy recommendations of the report.

These can be boiled down into -- they're a little bit more complicated than this, but I think the best way to express them are: First, that it removes the registrant street and city address from open unrestricted access, so today if you do a WHOIS lookup, you'll see for the registrant you'll see their name as well as a complete postal address, and this removes the street part of that, as well as the city part, from open access, so it leaves only the name and then a state or a province and/or -- a state or a province of a country.

The second change is that the administrative and technical contacts would no longer be displayed in WHOIS, and instead, a new operational point of contact is -- is proposed to be created. This operational point of contact would be displayed to everyone for all domain names.

The third major element is that the amount of information displayed by registries is made somewhat more consistent and somewhat more limited than is the case today. Today, there's a few -- there's two registries, com and net, that have a relatively thin set of data with no contact information, and there -- most of the other gTLD registries have a much thicker set of WHOIS data that includes contact information and we propose to make it so that the registries would only display the -- the sort of technical, the noncontact information, and the registrar would then become the authoritative source for that information.

And then the last element relates to the last term of reference point that I'd previously mentioned regarding accuracy, and this requires that the registrars do some more verification of new contact information if their old information is found to be incorrect and it also actually imposes a burden on registrars, if the information is found to be incorrect and it's not resolved, that the domain name be suspended or deleted.

So as I mentioned, there's -- there's some significant opposition to this -- to these policy recommendations, and we've had a brief amount of discussion about -- at this meeting in particular with various constituencies, as well as some objections that came up during the course of the task force work, and these objections that we've identified essentially can be summarized with the following bullets: First, that it's not -- we create -- the proposal creates an operational point of contact but it's not exactly clear what the responsibilities of the operational contact are. In fact, there's not necessarily something you might consider a job description for the operational point of contact, or if the operational point of contact did have responsibilities, what would happen if they failed to meet them. There's one other issue that's related to that, which is that if the OPoC has responsibilities to either respond to issues or to pass on information to the registrant, whether or not there should be specific time frames to complete that -- those tasks.

So there's -- there's some uncertainty, I guess, it would be a fair summary, of all those points as to what exactly the OPoC is supposed to be doing, and that's considered to be a significant cause of concern for a number of the constituencies.

The second sort of major area of objection is that the -- there's not necessarily a clearly defined way. There's additional information that the registrar will collect, including the administrative technical contact as well as the registrant's street address and it's not clear how that information would be accessed. There's no -- in fact, the operational point of contact proposal does not provide any formal mechanism to do that, and this is actually a point on which we -- I don't believe there was a majority view within the task force as to how to resolve this particular issue.

As one of the constituencies that supported the OPoC in principle made clear, they thought that on this particular topic there -- some further work needed to be done.

And then the last -- the last point was that if this -- if there's a set of data that's no longer going to be displayed, we should certainly work to make that information as accurate as possible, and there may be some additional steps that we could take to do that.

So on the next slide, we'll actually see a brief example of how the OPoC actually works. Here is a sample, a very simplified domain name but this is a domain name that I used to have registered, and the -- this is actually some old contact information for me, but you can see it has my -- it's a little bit strange because we edited it very quickly but you'll see it has my name as well as my street address, it has the city and state I live in, and then it also has a technical contact which in this case would be the registrar that I registered it with, although that could be any technical third party that was helping me with the technical issues with the domain. And then once the OPoC goes into effect, you'll see what happens is that the street address part of the address is -- and the city is removed and so in this case, we would be just left with my name and a state and the country, and instead of having a technical contact, we would just have the operational point of contact and it would apply to the administrative contact as well.

So the other proposal that -- that was discussed and that had some significant support within the task force was what's called the special circumstances proposal, and this takes a slightly different approach, in that it -- instead of changing the default behavior for WHOIS, it proposes that for a certain -- in a certain set of special circumstances, a registrant might be able to remove their -- remove their contact information from WHOIS but as a general case, the same information would be displayed as today. And the -- essentially the requirements for qualifying for the special circumstances under the proposal as it stands today is that you have to have a reasonable belief that publishing the information would threaten your safety. So if you can prove that you have a stalker or something like that, or -- you might operate a battered women's shelter or something like that where there's an issue of safety if the information is public, then there would be -- you would be able to remove the information under that circumstance. If you just have a general privacy concern like if my information's published in WHOIS, then theoretically someone might be able to find me without having any specific -- specific threat identified, then that wouldn't qualify.

In order to evaluate these claims, there would -- the proposal imagines that some neutral third party would be identified to adjudicate these decisions and if you qualified, then at that point all of your information would be -- your contact information would be removed from WHOIS, so from that perspective, it actually -- for the people that qualify, it would actually remove somewhat more data than is actually the case for the OPoC, which only removes the street address as well as the -- as well as the city.

And the other important change with regards to the Special Circumstances Proposal is that it prohibits a set of policies that exist -- or services that some registrars and affiliated companies offer today which are called proxy services. These allow for people that want a heightened level of privacy today, some registrars offer a service by which the registrant's contact information is replaced by this third-party service, either the registrar itself or some third-party. Or in some cases it doesn't actually replace all of the registrant's information but just provides some sort of forwarding service for either e-mail or the address or so on.

So this proposal imagines that the -- I believe the intent is that the special circumstances would provide a level of privacy to replace these proxy services. As a result, it would prohibit them in general.

So as with the -- since there are three constituencies opposed to this proposal as well, as you can imagine there is some objections that have been raised to this. And -- hope pulley we will be able to see them. Okay.

So the first objection that's raised -- many believe that the default level of privacy for natural persons should be significantly heightened. And as a result, if natural persons that are not engaging in commercial activity should, by default, not have their personal data displayed whereas under the Special Circumstances Proposal you would only be able to remove your data if you qualified for under the special circumstances.

So some were looking for a general heightened level of privacy for natural persons.

The second objection that's been raised is that it may be -- it may not be a good idea to have third parties making the decision about whether or not the special circumstances apply. The registrars have indicated, for example, they might be more equipped to make that decision.

The third objection is that there's -- there may be some costs -- there is very likely some costs involved in administering this policy as the evaluation of the special circumstances requests. It might require some overhead and some sort of charging model was requested to be in place to deal with this. And the last objection was specifically to that -- to the second part of the Special Circumstances Proposal relating to proxy services. And the objection is that in many cases, there may still be a place for proxy registrations and the blanket prohibition contained in the Special Circumstances Proposal might not be appropriate.

So I think the last slide talks about next steps for us, if we can get that up.

And the next steps, as I mentioned, the task force has completed its work under the bylaws. The council now can consider the policy recommendations contained in the report. It can do whatever it wants, I guess. The council can vote to support the policy recommendations contained in the report. They could modify them to make them more appealing or more likely to gain overall consensus of the council or perhaps approve some further work. For example, to resolve some of outstanding issues that were just raised, do some sort of implementation working group might be an appropriate step as well.

And in addition to this, the ICANN staff has prepared a helpful document which provides some notes to the council and identifies some areas where some further work might be useful. It identifies some issue for clarification and further discussion as well as potential implementation issues. And the staff also suggests a framework for the development of the proposal.

So that's, I guess, the end of the status report and I think it is probably -- if people have questions about this, I would be glad to answer them at this time.

>>BRUCE TONKIN: Thanks, Jordyn. So I will open the floor for about 15 minutes of questions or comments from the audience on this status of work. Amadeu?

>>AMADEU ABRIL i ABRIL: Good morning. My name is Amadeu Abril. First thing, congratulations to you for having a final report. I never thought I would see that day. The second thing is regarding the operational point of contact, who is that in practical terms? Because, indeed, the technical contact very often is the ISP or more often the registrar. The admin contact and billing contact needs to be the registrant when it is an individual. But the problem when it is an individual, will go to registry, domain name, he will probably have no idea where to find anything that can work as an operational point of contact. So is that supposed to be the registrar? Will we see the emergence of a abusers on that or some people -- the council will volunteer to be the operational point of contact for all the natural person to do that?

The only problem here is that at that moment the only logical thing is to put yourself because you will not find a real alternative.

The other question here is that I think you mentioned -- but I am not sure you said that one of the recommendations that the registry only displays what's now being displayed by the dot com, dot net registry and the rest of the input including the operational point of contact is only in the registrar base. Only I can understand the split WHOIS service. The rest of the world gets completely confused by the multiplicity of WHOIS information in different places and gets lost in that. I don't think this would be a very good idea. I see no reason for doing that. Thanks.

>>JORDYN BUCHANAN: Thanks, Amadeu. Your first question, I think -- I don't think the task force or the proponents of the OPoC attempted to identify a set of people that would necessarily serve as operational points of contact. I think that concern has also been raised by some of the opponents as well. It might not even be clear to Idaho this operational point of contact should be and to make sure we get their consent to do so as well.

I think some of the discussion within task force looked at -- certainly imagine the registrar might be an appropriate operational point of contact in cases. ISP might be an appropriate operational point of contact in many cases. It also -- it may also be, as you point out, that the registrant might choose to list themselves if they thought they were the best able to resolve any of the issues that might come up with the domain.

In addition to that, I think that the one other thing that the proposal contains is actually possible to list up to two operational points of contact. So it may be that you might list -- you might list your registrar and you might someone else to deal with the more administrative issues or you might list your ISP and one else.

I think especially larger businesses might have different people working within the business that resolve some of these issues.

>>AMADEU ABRIL i ABRIL: My problem is the operational point of contact has to be operational. The point is we want to display some information that shouldn't be there but we want to be able to contact people when there is a conflict.

So if you list someone but if you don't know beforehand this someone will play that role, it is taking that role, that's probably defeating the service.

Look, for instance, I am advising one registry to reform that. In that case -- indeed it is a small registry. The proposal is that the registry will be the operational point of contact. Charging an e-mail system to be in contact with the people that are registered there.

But some large registries like dot fr or even ca, something like that as well, they took upon themselves the responsibility. I think it is the responsibility of the managers of the DNS to make sure that this works. I repeat, I can use my registrar but how do I know whether they will do that and how do they know that I decided that they are my operational point of contact, especially a third-party.

>>JORDYN BUCHANAN: That last point that you raised, as I mentioned, that has been raised by some members of the community as well.

>>BRUCE TONKIN: It has pretty much what the current opposition is, is that it is unclear on what the responsibilities of that operational point of contact and there is no clear job description for that operational point of contact. Those points were noted, yeah.

>>JORDYN BUCHANAN: Amadeu, the to answer your second question, I think in the view of the proponents of the operational point of contact, having the -- well, I will make two points with regards to removing the data from the registry. The first is that for the vast majority of domain names, they actually are in com and net so this split already exists in most cases where you do a WHOIS lookup today.

And, secondly, in some cases where there is contact information displayed in the registry, it gets out of sync with the information displayed by the registrar. When that happens, it is very difficult to determine which is authoritative or which is more useful. Having a consistent place to look might reduce the level of confusion in those circumstances.

>> Hi. My name is Laura Mather. I am here representing the anti-phishing group, the PH kind of phishing, not the F. We have been watching this discussion very closely. We haven't participated very much until now. We have some concerns with the OPoC proposal in that the people right now that are combatting phishing are not actually law enforcement. They pick it up a few weeks later. But right now it is actually vendors, different companies and even the companies that are protecting the consumers themselves.

And OPoC is going to make it very difficult to combat phishing. It is just something that I want to be clear that may be a complication with the OPoC.

Another thing that I heard that concerns me is in the case that we change to where a private person can keep their information confidential and a commercial enterprise needs to display it, if I am a phisher, I then just go say I am a private person and I get the protection from being able to have my site investigated in a way that needs to be investigated.

I just wanted to bring up that unfortunately there is a lot of fraud that happens, as you know, with the registration of domain names that ends up impacting huge amounts of consumers. And it is important that's considered when these decisions are made.

>>BRUCE TONKIN: Can I just pick up a couple of those because I would like to understand the issues a bit further. Taking the special circumstances one, I agree both of these proposals need more work. But let's just take phishing example. Let's say one of the special circumstances was that the domain name was being used for non-commercial purposes, et cetera.

If it starts to be used for phishing, I would zeta point it is being used for commercial purposes and, therefore --

>> Laura Mather: Are you saying then it would constantly be a check on the domain seeing oh, now it is commercial? I don't think that would be the case. Still easy to hide behind that.

>>BRUCE TONKIN: If you any about how most of the systems work together. Let's forget about domain names and just talk about Web sites. ISPs and hosting companies don't check every Web site every second of the day but they have a complaints process which your community uses and when they receive the complaint on phishing, they usually shut down the site.

I don't see anything specific about this that would stop that process happening. Because it is not normally the registrant that you stop in a phishing attack. It is normally the -- my experience as a registrar is you are contacting us. If we're hosting the site, we bring it down. And if it is a service provider that we know of, we contact them and they will bring it down. So it is not -- I don't think it is really the registrant data. It is the fact that it is a phishing site that gets shut down.

>> Laura Mather: Because the WHOIS data is available to us the phisher often put indicators in the WHOIS data of who they are and that gives us more information when we get to ISP to say, look, we believe this is a phishing site and here is how we can prove it. We have a relationship with other phishing site shown in this WHOIS record and that will go away with OPoC and that's our concern.

>>BRUCE TONKIN: Effectively a bad faith thing. So you are saying because this particular set of address credentials has been used in a number of places for phishing, so you are saying here is a patent as opposed to the individual phishing site.

>> Laura Mather: That's often very effective for people. Oh, look, this person posted a Bank of America phishing site and an eBay phishing site and an HBSC, wow, okay, now I get it and I will take it down.

>>BRUCE TONKIN: How is that happening today? If we make no change and we are just at status quo, are you finding that these sites are behind sort of proxy services now or not?

>> Laura Mather: Some are, some are not. To be honest, most of the domains that are registered now use stolen identities. Again, they have to use the same one a couple of times. That's where it can be helpful.

>>BRUCE TONKIN: That's my observation as well. Even though they are stolen identities, there is some correlation between those they would be missing was using proxy services which often cost them more anyway.

>> LAURA MATHER: Absolutely. The anti-phishing working group has put together a small committee to try and put together some recommendations based on this. And if there is a new committee formed, look at this, we'll be circulating what our conclusions are.

>>BRUCE TONKIN: Just very helpful to clearly articulate in practical terms how you are using WHOIS today and how any of the proposals would impact that would be a useful understanding.

>> Laura Mather: We will get on that as soon as we can.

>>JORDYN BUCHANAN: It would be very useful to look at are there cases where the name and the country -- state and country are not sufficient. Like, there is a correlation you only see in the street address and you don't see it from the other information. It may be using a false identity, you might see the same name for something like that.

>> Laura Mather: We will look at each proposal in detail and come back. Unfortunately, I think that convincing ISPs is very difficult, believe it or not. A lot of ISPs say it isn't causing any harm. The more correlation we can show across the different entities the more convincing we are.

>>JORDYN BUCHANAN: I also wonder, maybe it is more useful -- maybe there is additional work that might be useful in having policies that would allow some sort of mechanism for registrars to have more flexibility to take down the sites instead of forcing you to go to the ISP.

>> Laura Mather: That would be fabulous. When it happens with ISP, they move to another ISP. So the registrar would be even better so if that happened, it would be nirvana.

>> My name is Carole Bird. I represent the Royal Canadian Mounted Police. Just a quick comment and a question. In reviewing the OPoC proposal, the interest of law enforcement were not easily accessed by the OPoC proposal. So my question to you because in the discussions I have had with people, one of the issues that has been raised is an law enforcement -- the police sector has not come forward and provided a response in the public consultation. Generally, and may be the misunderstanding of the police sector is how the ICANN works. The police would be providing its feedback through the GAC, through the government representatives.

In speaking to the members of the GAC, my understanding is because they are ratifying their WHOIS principles, they have the opportunity to take the recommendation of the GNSO Council on OPoC and special circumstances and consult with police. Therefore, my question to you is prior to any formal action being taken on OPoC or special circumstances, is the intent to allow for meaningful consultation to occur with the GAC by their countries on these specific proposals now they have ratified the GAC WHOIS principles and therefore wait for formal advice?

>>BRUCE TONKIN: Let me ask you a question first. I am pleased to see someone from the law enforcement actually here and speaking in the public forum. One of the struggles the GNSO has had is how to get effective input from the law enforcement community. You provide input to your government representative who, in turn, provides input into the GAC which then tries to reach a statement which is agreed by all governments. By the time your input gets through that process, it is almost unrecognizable. In other words, it is not at a practical level that the council can use in terms of looking at implementation issues.

So the GAC -- by the time it comes through the GAC, it will be more likely something like law enforcement's interests need to be considered or something. I haven't actually seen the GAC statement. Let's just say that's what it was.

That doesn't help me very much. It is like, yes, I know that. We know law enforcement issues need to be considered. But what are they?

And so I think it is absolutely appropriate that you provide input through your process through the GAC and I think that's great.

But I think the GNSO, particularly the task forces, would also really appreciate something that is in detail from the Royal Canadian Mounted Police because that's a useful piece of data for us. That would be saying given one of these proposals, doesn't really matter which one it was, you would say here are the Royal Mounted Police implementation issues with that.

That's not saying we are treating that as a consensus position of all police forces. We are treating it as your input from the Royal Canadian Mounted Police.

But it is at a level of detail that we can engage with. I think we need to see just like the anti-phishing group has stepped forward and said this is how we are using the data today, the changes you have proposed could cause issues and then the task force could go back to the anti-phishing working group and come up with another way of meeting their requirements or we've change our proposal. My question to you is: How could that be done? What would we need to do to allow you to give us that detail response as opposed to something that ends up at the high-level principles? The GAC gives us principles? It doesn't give us this is how law enforcement -- this is how I type my name and password in. I am using a Mac and your proposal is not compatible with my Mac. That is not going to come through the GAC.

Just interested to see what would we need to do to help you give information at a more granular detail.

>> Carole Bird: My own personal opinion, there is probably a number of different things that could be done. The biggest issue is who is law enforcement. We mean police officers, but there are also government groups such as the Canadian Revenue Agency and a number of other things that are replicated in other countries. They are technically law enforcement but not police officers.

There is, of course, the private sector as well that uses that terminology, when they are working on behalf of clients to deal with things such as intellectual property.

So to get meaningful consultation back from certain sectors, you have to identify what that sector is. And then there is opportunities, I think, to approach if you are talking specifically about the police sector. Quite frankly, I would say some of the policing needs are unique and distinct from some of the other sectors. Or at least the government agencies that are empowered by their respective governments to enforce their laws might be distinct and unique from those in the private sector.

There are a number of different ways to do that. You can do it directly by approaching the different governments that are affiliated through the ICANN. Again, I recognize that may not be feasible or may not fit in with the ICANN structure.

The other way is it there are some policing organizations that have a large scope, such as Interpol and they could be approached. Or we may have to look at something like a plan C which is recognizing the ones that have come to ICANN that have a vested interest where the law enforcement -- excuse me, where the police has developed to such a stage that they are actively engaged and have an interest in this topic where as opposed to countries where the law enforcement still hasn't had a chance to deal with that issue because they have other issues that are engaging their time. I have spoken to a couple of you about some of the law enforcement in places in the Middle East where quite frankly they are struggling just to stay alive as police officers. They have different issues to deal with. They are not going to be coming to this table per se.

So I think there is different opportunities. I would welcome the opportunity to sit down with any of you at any point in time and discuss what those avenues would be to provide meaningful consultation as well to work through the GAC.

>>BRUCE TONKIN: You would feel comfortable if we would have had a meeting on the weekend to talk to the law enforcement sector and there happened to be a number of people here from that sector that were attending ICANN any way, you would be comfortable attending that meeting and giving us input, would you? I have heard feedback also saying that members of your community aren't comfortable doing that.

>> Carole Bird: I can only speak for myself personally, for the Royal Canadian Mounted Police. RCMP is way shorter. To provide their views. There are other colleagues that are here. The thing that has to be recognized again is that this is a small segment of thousands of police forces across the world that eventually may be using and developing to the point where they're able to use the information to support complaints made by the public whether they are individuals or businesses to meet our mandate which is in most cases to protect and certify.

As long as that context is there, I am sure the police personnel at this conference will welcome the opportunity to have the meaningful consultation.

>>BRUCE TONKIN: I think we need to work together and happen to talk about it offline. The council is considering what to do next. One of the things I have heard about in the discussions in the last few days is, certainly I can speak for the registrars, that they do want to engage more meaningful with the law enforcement sector.

Your comment about trying to speak on behalf of all police is no different to our own issues because our structure is any one of our constituencies, the registrars, there are 880 registrars I believe at the moment. We can't sit down and meet with 880 registrars. We tend to meet with a subset and that gives us a sample and that is useful information. Same with businesses, we have the business users constituency. Obviously there is probably a billion businesses. We can't clearly say we represent every possible business in the world.

But that group does give a representative sample of some of the issues that we can consider. So I think there is still value. It is not the same as saying it is a directive. So we are not asking you to sort of give us a directive and tell us what we must do but in terms of issues you have problems with you have with the current WHOIS, at the practical level, how that impacts your day-to-day job is really useful information for us to consider.

>>CHUCK GOMES: Bruce, can I just jump in here? I will be real brief. I am not suggesting we discuss this now. But as a council, I think it would be useful for us to at some point in the near future think about when we form working groups or task forces to consider how we might involve representatives of key stakeholder groups, even if they're not part of the GNSO system.

And I know it's hard to get representation of such a diverse group as law enforcement all around the world. But even if you had one representative from the law enforcement community that could at least share their perspectives during the work instead of after we reach recommendations, I think it would be very useful.

>> Carole bird: I agree. It is as simple as that. Thank you very much for your time.

>>BRUCE TONKIN: Margie.

>>MARGIE MILAM: I'm Margie Milam with Markmonitor. We specialize in intellectual property matters. We also represent about 50 of the fortune 100 companies and have been very active on the WHOIS issue. What we have done at Markmonitor is try to educate our customers as to the issues related to WHOIS and have been successful in getting their participation and opinion on how WHOIS affects their business. It affects their business in many ways. They're concerned about how it affects their customers. In discussing the issue with customers and getting them to sign up to our position which was in support of special circumstances, the consensus among our customers was that OPoC was probably a little more difficult for them to protect their customers' interests than special circumstances.

And I think one of the reasons is that there is a perception that OPoC is going to become a big proxy service, if you will, and there is no way to get information behind the proxy. I think that's representative of the task force vote, if you take a look at the task force vote, it was a very slim majority. And, in fact, as Jordyn mentioned, only three out of the six constituencies actually supported special circumstances.

And so as the GNSO, I would urge that you consider both proposals and maybe other proposals and not jump quickly into a decision because there is a lot of issues that haven't been dealt with and need to be dealt with adequately. Just to give you an example on one aspect of the OPoC proposal, the aspect about if there is an accurate WHOIS and information is not responded to quickly that a site has to be shut down. That can affect stability of the Internet.

Even though we think about it from a perspective of a bad actor who hasn't updated their WHOIS information, it applies across the board to all companies. And if the company -- a major corporation doesn't respond to their registrar within an amount of time, if there is an inaccurate WHOIS report, that registrar would be required to shut down and put that domain name on hold and that could have serious impact on its customers and on the Internet community as a whole.

So I would just urge the GNSO to have caution and really look into implementation issues and whether there are other alternatives since there was no real strong consensus on this particular issue.

>>JORDYN BUCHANAN: Thanks, Margie. I just want to note one thing with regard to accuracy. The accuracy provisions of the of the OPoC proposal actually had much broader support than the rest, so those -- I think there were some constituencies who expressed their view that those could -- they would support the accuracy provisions of the operational point of contact proposal, even if they don't support the rest of the terms.

>>MARGIE MILAM: Right. And I support a more accurate WHOIS. I just think the Draconian rule that you have to shut down a Web site if there's no response can have implications that we're just not thinking of when you're, you know, talking about, you know, a requirement in all cases.

>>BRUCE TONKIN: I must admit, I missed that in the proposal. Can you just elaborate what the change is?

>>MARGIE MILAM: I believe -- maybe I misunderstand it, Jordyn. Isn't it not the case that if there's no response, the registrar has to put the name on hold?

>>JORDYN BUCHANAN: Yeah, that's right. Today, there's -- if a registrar has a complaint and there's no response or they identified inaccurate information and it's not updated within a certain amount of time today, the current policy gives the registrar the option of either taking the site down or leaving it up, whereas the accuracy requirements in the report would require that the domain be placed on hold or deleted if the problem is not resolved in a certain period of time.

>>MARGIE MILAM: Right. So as an example, you know, Microsoft.com, if you send an inaccurate WHOIS report on Microsoft.com, that information is accurate in the WHOIS, but the registrar for that company has to go and contact the -- whatever, the OPoC or whoever the person is you have to contact, and if they don't get a response within 10 days, Microsoft.com goes down. I mean, is that really the intent here? Even though they know the information is accurate because they -- you know, they've checked it a million times but, you know, it's just one of those things that I don't think there's been a lot of thought to some of the -- some of the details in the OPoC proposal.

>>ROSS RADER: Jordyn, if I might jump in, one of my frustrations with this process that's now been going on in some form or another since -- well, since before the GNSO even existed, is that I'm not hearing a lot of constructive -- or what I would view as positive -- suggestions around how we might move the issues forward. Specifically around the issue of accuracy, this is a -- a set of concerns that's of high interest to the intellectual property community. And I think as it relates to the OPoC proposal specifically that the accuracy provisions of that proposal were presented by that community. So now hearing that this is unacceptable to a large corporate IP interest, yet those proposals came from that community, is disappointing, I think. I would like to better understand how the proposals could be improved versus what we each dislike about them at this point. So if there's things that we can do to improve those provisions --

>>MARGIE MILAM: Sure.

>>ROSS RADER: -- I think that would be much more productive line of discussion for us.

>>MARGIE MILAM: Sure. And in that particular situation, the improvement would -- you know, obviously we prefer more accurate WHOIS. I just don't think an absolute rule of shutdown in all circumstances is appropriate, so the improvement would be to give a little bit of discretion if the registrar has reason to know that the information is accurate. I mean, in the case of MarkMonitor, we know who our customers are, we know what the WHOIS information needs to be. We don't need to contact our customer, you know, for thousands of requests because we know it's accurate. And -- you know, but if we're forced to do so, we're not going to risk our registrar accreditation and not contact our customer and bug them, even though we know the information is correct. So I -- you know, that would be an example of an improvement.

>>ROSS RADER: I think more specifically, my point, Margie, is that we have that flexibility in the system now. IP interests said that flexibility was a concern to them. Now we're hearing from IP interests that that lack of flexibility in this new proposal is also of concern to them. So I would ask the intellectual property committee what their real concern on this specific issue is. Is it flexibility or lack of flexibility? I'm not sure I understand that today.

>>BRUCE TONKIN: Okay. That's probably good for you to talk to Margie afterwards then to understand what has been a Vittorio?

>>VITTORIO BERTOLA: Thank you. And the first thing I wanted to say, speaking personally and not embarrassing my [inaudible] first I want to dispel the myth that this is a discussion of privacy versus law enforcement. So even those who are in favor, strongly in favor of privacy protection, are not against law enforcement and I can tell you we are in Europe now, where we have the strictest privacy laws and there's a lot of law enforcement. It's not like there's people running and crimes in the street and they're not being punished. So the point is not about anonymous registration or letting people hide when they publish something on the Web or use a domain name. The point is, how -- who has the right to access that information and how.

And I would like to keep that -- I mean, I guess the -- well, you have been discussing this for years now, but not everyone still in the community seems to have a understanding. So I still hear a lot of confusion, for example, between proxy services and privacy protection, which are actually two very different things. I mean, proxy service is a way of providing you anonymous registration by letting someone else figure out the registrant and this is not what I'd like. Actually, I'd like to provide my full name and address so that I can be contacted, but not -- just not to have it available to anyone else.

So the other thing I wanted to say is, anyway, that I've seen the opinion of the European privacy authorities and I hope all of you have read it. It's very clear, and it's not the first one. Actually, there was already one in 2002, which was basically ignored because we were in the middle of this process. So there's a new one, only it's a different proposal, that basically says that both of them are legal under European law. Even if it makes a difference and says there are special circumstances, special circumstances which apply to individual registrants is clearly out of any possibility of complying with the European privacy laws, while the OPoC proposal says it's better but still to be fully compliant with European laws, it would imply that you would have to allow for full withdrawal of the information of individual registrants from any kind of publication in the WHOIS.

Now, I could go ahead and say okay, this is all you have to abide by and personally I tend to be somewhat insulted by the fact that I could approve a policy that is illegal under my legislation. What I'd rather think is that there is so much polarization of the discussion and really I'd call it a values clash, a deep difference in values between certain parts of the world that I'm starting to think that the only thing that ICANN can do is actually to strike any WHOIS requirement from this contract and recommend that there is some publication of data but let each registrar work it out with their local legislation and privacy authorities because I'm -- the more and more we are in this discussion, the more that I think we will never be able to agree on a policy that's acceptable to everyone.

>>MIKE RODENBAUGH: Vittorio, I have a question on that, please. I think you're saying that under EU privacy laws, the special circumstances proposal would be illegal but yet it's based on the Netherlands law and current practice in WHOIS. Can you explain how that is so?

>>VITTORIO BERTOLA: No. I wasn't clear, perhaps. It's not me saying it's illegal. It's the official authorities that in the Europe have the right to say what's legal or illegal under European privacy laws, so you should -- I tell you you should just read the opinion because it's -- I mean, it's -- it actually goes in depth into saying what is legal or illegal, and so I can tell you that still today perhaps not all ccTLD policies in Europe are actually compliant fully compliant with European privacy laws but, I mean, at the same point in time, I think you should really just read that and take that into account, because it's an official opinion from the entities that are -- in Europe have the legal right and the authority to interpret privacy laws.

>>PHILIP SHEPPARD: Philip here. Just to make a clarification, if I may. The Article 29 group is so called because it's set up under Article 29 of the data protection directive. It is essentially an advisory board that comprises the member states of the European Union. Their opinion may be taken into account in subsequent laws, but we need to be careful in terms of use of language here as to whether their opinion is legally binding, et cetera, just for clarification.

>>VITTORIO BERTOLA: Yeah. Okay. Yeah. Actually, it's the members of the Article 29 that I believe have legally binding powers in their own countries and not the council per se but I would expect that what they say is what their members think.

>>TOM KELLER: Just to your point, Philip, I want to point out that the head or the chair of that working group actually is Peter Char, who is the main privacy officer for Germany, so if he's issuing such opinion, I would be deeply thinking about that, whether he's not representing the German view of the German government and German rules.

>>BRUCE TONKIN: Okay. Any other input. Okay. Well, thank you for all that constructive information.

The next topic is the -- an update and the rest of the session is more or less updates on some ongoing work or work that's just been recently completed. I'll hand over to Avri Doria to -- as the chair of the work on policies for contractual conditions for existing registries.

>>AVRI DORIA: Okay. Thank you, Bruce. Okay. This is basically an update of this task force and where we are at the moment. Specifically, we have a draft of the final report in comment period. This is the second comment period that we've had on this task force, given how long it's taken, and I'll go through some of the items that are in that particular report.

So basically, I'm going to cover a registry constituency issue that has been with us since the beginning of the task force, proposed recommendations that have majority support, proposed recommendations without majority support, and then a little bit on the next steps.

Next slide, please.

Okay. The registry constituency has, throughout this policy development process, expressed its opposition to the terms of reference, to the potential applicability of any of the proposed policy recommendations and to the work of the task force as a whole. The registry constituency, prior to the commencement of the formal PDP proceedings issued a statement and a preface to that statement which sets out its objections to the process. These are documented in the report, and, in fact, just received today a minority -- or an extra position from the registry constituency, restating that position.

Next slide, please.

What happened?

I know there was a next slide. I can...

>>BRUCE TONKIN: Just keep talking Avri.

>>AVRI DORIA: Okay. I'm trying to bring up the slide on mine, so I know what slide I'm talking to. I'll be right there. Oh, dear. Huh.

>>BRUCE TONKIN: I had it on the thumb drive, which I'd just given to Chuck.

>>AVRI DORIA: Oh, okay.

>>BRUCE TONKIN: I should have copied it onto my hard drive.

[Laughter]

>>AVRI DORIA: Okay. Basically, in terms of the sequence of events on that, the creation of the PDP -- and this is in response to the registry constituency's issue -- the creation of the PDP was a decision taken by a supermajority vote of the GNSO Council under annex A, Section 3C of the bylaws. The use of a task force and their terms of reference of that task force is a decision of the council taken in accordance to the bylaws, and, in fact, it wasn't for the task force itself to make any decisions regarding the appropriateness of its terms of reference. Having been given the terms of reference by the the council and having the council reaffirm those terms of reference was the motivation for the task force to continue working on the terms of reference. And the outcomes of the task force then need to be considered by the council before voting to approve any recommendations and sending them to the -- the ICANN board.

So essentially there's an acknowledgment of the registry constituency's position, both in the meetings, in the report, and in this review, and there's a task force that is operating under the council's mandate.

Okay. Then the council -- the ICANN board will then need to vote -- and this would be the next slide -- to approve any recommendations as policy, taking into account public comment, legal advice it may receive, along with advice from all the advisory committees.

Then the terms of existing contracts would affect whether any of the ICANN policies were implementable. Each of the contracts has a different set of statements in it about its relation to consensus policy. So -- and then the contracts have various terms to resolve disputes and ultimately if a decision couldn't be reached, legal courts can be -- can be used to resolve any of the disputes.

Okay. The next one. So the recommendations with majority support. The criteria were used that at least four of the constituencies were in support of the recommendation with at least one or more of the NomCom participants in the task force also in agreement. So it was a 4 plus 1 type of scenario. We had nine recommendations that did receive majority support.

Okay. On the first term of reference, which was to examine whether or not this should be a policy guiding renewal, and if so, what the elements of that policy should be.

And what I'm going to do here, just to explain, I'm going to go through all of the terms of reference that had the majority reports, and so sometimes if something is not responded to, it's because we didn't have a majority support for a recommendation and I'll cover those other parts later. So in this case, there was majority support for: There should be a policy guiding registry agreement renewal and that the registry agreement should be a commercially reasonable length. The task force itself did not define what "commercially reasonable length" was. In the discussions, it was basically considered that it should be a length that was consistent with a length picked in the new gTLD policy for arrangements. The number that often came up was in 10 years, but this was not something that was discussed for majority support.

On term of reference 3A, examine whether -- examine whether consensus policy limitations in registry agreements are appropriate and how these limitations should be determined. And the majority support was for present limitations to consensus policies are appropriate and should continue. And that's within all of the contracts.

I think I misordered. Term of reference -- I might have mis-numbered also. Apologies.

Examine whether the delegation of certain policy-making responsibility to sponsored TLD operators is appropriate, and if so, what, if any, changes are needed. Policy-making responsibilities should be delegated to the sponsored gTLD operators. It received majority support.

Term of reference 4A, examine whether or not there should be a policy guiding registry fees to ICANN, and if so, what the elements of that policy should be. In order to improve ICANN accountability and effective business planning by registries, ICANN staff should immediately implement a system that avoids individual negotiations of ICANN fees and provides consistency, unless there is an established justification for disparate treatment. That received majority support.

Term of reference 4B, determine how ICANN's public budgeting process should relate to the negotiation of ICANN fees. Majority support for the ICANN board should establish a task force or free committee to examine budgeting issues, including the manner and allocation of revenue collection, budget oversight, and budget approval. This group should solicit and review public comments on the issues.

Term of reference 5 -- the next one, thank you -- examine whether or not there should be a policy regarding the use of registry data for purposes other than for which it was collected. And if so, what the elements of that policy should be. This one is a rather long recommendation. In order to determine whether there is a need for a new consensus policy on the collection and use of registry data, including traffic data, for purposes other than which it was collected, there is first a need for a properly targeted study by an independent third party on the data collected and the uses to which it was put.

Next slide.

The study should provide appropriate safeguards to protect any data provided for the purposes of the study, and the confidentiality of which registry or other group provides the data. The findings of the study should be published and available for public review. A statement of work should be developed by the GNSO Council, with appropriate public review, to cover an analysis of the concerns for public collection and use -- data collection and use. The practice involved in collection and use of data, including task data, and the availability, when appropriate, for nondiscriminatory access to that data. I believe it goes on.

It is recommended that a current processes document be developed describing the current registry practices for the collection of data and the uses of that data. For example, but not limited to, operating the registry, preparing marketing materials to promote registration of domain names, gathering of null returns, ensuring the integrity of the registry or the DNS. This report should be available to the group doing the external study and should be made available to the public for comment. After examining the results of the independent study and public discussions recommended above, the GNSO Council should examine the findings and determine what, if any, further policy process is required. This basically came out of a very difficult issue that we had in terms of determining which data we needed to study, how we needed to do it, and not being able to actually study the full extent of the data made it difficult for the task force to make any specific recommendations, but we did feel that more work -- or a majority -- there was majority support for more work in this area.

And term of reference 6: Examine whether or not there should be a policy guiding investments in development and infrastructure, and if so, what the elements of that policy should be.

And there was majority support for: There should not be a policy guiding investment in development and infrastructure.

And a second recommendation on 6A, ICANN should establish baseline requirements for the security and stability of registries, and anything above that would be negotiated under on a case-by-case basis, if necessary. Baseline requirements should be recommended to the board by the SSAC after consultation with the gTLD registry operators. In determining those recommendations, the SSAC should solicit and consider public comments. And that was it for the recommendation -- proposed recommendations having majority support.

So for those that did not have majority support, we used the criteria if there were fewer than four consistencies in support.

Now, on these, there are still some discussions going on among the constituencies until the 28th to see if any realignment of constituency positions can bring these into the category -- excuse me -- of majority support, and that discussion is still ongoing.

Next slide.

So in term of reference 1A, dealing with what elements of the policy should be guiding renewal, the opinion was divided on three proposals. The first one, that there should be a reasonable expectation of renewal with a mandatory rebid, and that the mandatory rebid includes an advantage to the incumbent operator. No specific mechanisms were recommended. Some examples were discussed but that would be an implementation detail for -- for ICANN.

A second opinion was a discretionary rebid based on ICANN's determination of poor performance or other bad acts, but still with an advantage to the incumbent. And then a third possibility, that there's no rebid unless there was a history of repeated material breaches of the contract. And the task force members were basically evenly split across the proposal options.

On term of reference 1B, recognizing that not all existing registry agreements share the same rights of renewal, use the findings from above to determine whether or not these conditions should be standardized against all future agreements. So there were two views on that, and that the rights of renewal should be standardized for all gTLD registry agreements and the other view, the right of renewal should be standardized for gTLD registry agreements, except when there is an exceptional situation, such as a situation of market dominance or market power, and there's an extensive discussion of that in the documents.

On term of reference 3A, examine whether or not there should be a policy regarding price controls, and if so, what the elements of that policy should be. Note examples of price controls include price caps and the same pricing for all registrars. There was some support, but not majority support, for there should be a policy, and no discussion of the elements of that policy. There was no support discussions of the elements of that policy. There was not an opposing opinion rather than either an abstention or a negative opinion to whether there should be support -- should be a policy.

So there wasn't an alternative; there was just the absence.

Terms of reference 3B, examine objective measures, cost calculation method, cost elements, reasonable profit margin, for approving an application for price increase or when a price cap exists. The opinion was divided among three views on policy relating to pricing. It's too early to formulate a policy. A new PDP should be initiated specifically on this topic. The second opinion: Policy relating to pricing should not be discussed. Not even that there shouldn't be a policy, but that we should not even be discussing it.

And the third option: When a registry contract is up for renewal, there should be a determination by an expert panel whether that registry is market-dominant. If the panel determines that there is a situation of market power, then the registry agreement must include a pricing provision for new registrations, as currently is included in all of the largest gTLD registry agreements. If the panel determines that there isn't market power, then there would be no need for a pricing provision. Regardless of whether there is market dominance, consumers should be protected with regard to renewals.

So that was it for the proposed recommendations that have not reached majority support. We are currently in a -- until the 28th of March, in the second comment period that will end on the 28th of March, and that is the deadline for the task force's discussions on trying to reach majority support on any of the open options or perhaps a compromise option, should one develop.

By 12th of April, the post comment final draft will be available, and shortly thereafter, a week thereafter, the task force will have its final conference call where we will discuss the final report, discuss any comments that have come in, and then basically prepare to take a vote on sending the report to the council. The report will be sent to the council, in any case, but there will be a report within the task force on approving the report that is being sent.

And then on 26th of April would be the first opportunity when there's a council call when this can be discussed, and there will be a request to put that on the agenda for that meeting. And I believe that's it for the slides. Any questions? Comments?

>>BRUCE TONKIN: Thank you, Avri. Any comments from the audience on the policy development process on contractual conditions?

Okay. I'll now just get organized for Chuck.

>>AVRI DORIA: I was asked -- Bruce, if I can say one thing about March 28th. I kept listing March 28th and wanting to go to my calendar to try and remember when March 28th was. March 28th is today.

[Laughter]

>>BRUCE TONKIN: Yeah. Go ahead, Cary.

>>CARY KARP: Just to have it noted for the record, the registries constituency filed a separate statement about this. I'd be happy to read it into the record extensively if you find that purposeful, but otherwise, just note it, please.

>>BRUCE TONKIN: Okay. Yeah. We'll note that. So that's been sent to what group, Cary?

>>AVRI DORIA: It was sent to the -- to the task force list, which is a publicly archived list, so it is available for -- for all to read. And it was also sent to the public comment archive.

>>BRUCE TONKIN: Okay. Thanks, CARY. Chuck? Chuck Gomes is the chair of the GNSO reserved names working group. Chuck may have already covered this, but the context I guess is that the new gTLD committee identified one of the string criteria as it not being a reserved name, and we formed a working group to determine what should be a reserved name.

>>CHUCK GOMES: Is it not possible? Okay. It is up, very good I'm not -- because of time, I'm not going to give you any background in terms of the working group. I will jump right in to the recommendations that were in our final report that were presented to the council and the new TLD PDP committee on the 16th of March.

As you can see, the first one up there is the category of reserved names titled ICANN and IANA reserved names. If you look at the top of that slide, you will see two categories of names: The ICANN, ASO, GNSO, ICANN, Internic and ccNSO and IANA reserved names and you can see the long list there that I won't read.

The basic recommendation on this category of reservation -- of name reservations which occurs, by the way, in all existing gTLD registry agreements is that more work is needed at all levels.

The top level for new TLDs that will come on board, the second level which would be a reserved name category in new TLD registry agreements and then the third level only in cases where a new TLD would be proposed that involves registrations at the third level. Just as a form of example, there are only two gTLD registries right now that register names at the third level, dot name and dot pro. But there could be proposals for new TLDs that register at the third level and that's why we considered that category.

With regard to IDN versions of these reserved names at the top, second or, if applicable, the third level the working group recommends that no attempt to translate or transliterate these names be made except for one case, and that's the case of the word "example."

The more work -- I anticipate more work will be accomplished in a 30-day extension that I will talk about later of the working group, and that will be decided by the council meeting that follows this.

Next slide, please.

With regard to the use of symbols and domain names, the working group recommended status quo in that case, regardless of the level of the domain name or whether -- or the type of domain name, ASCII or IDN. We recommend that the current practice be maintained so that no symbols other than the hyphen be considered for use at any level unless technology at some point in the future changes that.

Next slide, please.

Regarding one character -- now, there is a category of reserved names in registry agreements and all current registry agreements, all 16 of them, that covers single character and dual character ASCII names, okay? These recommendations are going to be broken down a little bit further because of the different issues that come into play. The first way we broke it down was one character ASCII names.

At the top level, the working group recommended that additional work needed to be done looking at technical issues there.

For second-level ASCII names, the working group recommended -- keep in mind this has not been considered by the council yet. But the working group recommended that contingent upon the development of an appropriate allocation framework that single character ASCII letters and numbers be released at that level, the second level, in future TLDs and that those currently reserved in existing TLDs be released.

And then, again, the third level is pretty much same as the second level but only where applicable, although that one may need some more consideration after discussions with the new TLD committee on -- over the weekend.

Next slide, please.

Regarding one category IDN names, again, we're recommending additional work needs to be done, some of the -- there is some special complications with regard one character names and one character names at the IDN level can be quite significant depending on the script that we're talking about. By eliminating those, it is possible we can eliminate an awful lot of names in some scripts. So that one definitely needs some more work with the focus on IDN.

Next slide, please. Two character ASCII names only, not IDN on this slide, again, we had to break that down into several categories. At the top level for ASCII, letters only, okay? We recommend that the current practice continue, meaning that two character -- two letter names in ASCII continue to be reserved just for the use of ccTLDs. For one letter and one number, two character names in ASCII, again, we think that more work is needed looking at some technical issues on that category.

Second level ASCII, we recommend that registries may propose release of two letter and/or number strings at the second level provided measures to avoid confusion with any corresponding country codes that are implemented. Let me comment on that. That is pretty much the way the existing requirement is in all 16 registry agreements. Some of you are probably aware that GNR, the dot name registry, recently submitted a proposal to use two character names at the second level that went through the RSTEP process and was approved via that process and the terms of that being presently being negotiated.

Third level, the group didn't even have time to get to that.

So next slide. Two character IDN names. Again, we are recommending more work here. Via some discussion that occurred the last few days, both over the weekend and yesterday, there is some -- this category is probably a little bit different than the single character IDN names but still has some IDN complexities and will need to involve IDN expertise in that regard. So more work is needed there.

Tagged domain names, for those who may not be very familiar with the IDN implementation of domain names, the domain name system as I think probably everyone knows in the room only allows ASCII characters. To identify an IDN name according to the IDNA protocol, every IDN name in the DNS is preceded by a tag, a four-character tag, and so that's the category here.

Now, in all registry agreements that exist today, there is a requirement that the format of the tag -- any names in the format of the tag be reserved, okay?

And as you can see in the parenthetical underneath the title of the slide, it is all labels with hyphens in the third and fourth character positions at the beginning of the label. So the recommendations of working group were as follows -- let me point out there is no IDN version of the tag. This particular category doesn't have any IDN recommendations because it is not applicable. All of these are for ASCII domain names.

And at the top level, there are two parts to the recommendation. You can see number one there. In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in the third and fourth character positions must be reserved. You can see a couple of examples there. In other words, a name starting with bq-- would have to be reserved. Or a name starting with XN-- or any other variations of those with the character character dash dash representation there.

Just a comment there, the current tag that's being used in the IDN implementation is XN--. Previous version under the previous ACE encoding was bq--, and that's why we put these examples. This requirement requires all reservations of all variations of that, even though the information we were able to obtain seems very unlikely that there would be any change to the tag that's being used for that.

Second part of that is for each IDN gTLD proposed, the applicant must provide both the ASCII compatible encoding form of an IDNA valid string in the latest document on this, it is called the A label. And in local script Unicode form at the top level as well. So an applicant applying for an IDN TLD would need to provide both of those versions of what they're applying for.

At the second level ASCII, we just recommend a slight rewording of the requirement as it's in current registry agreements to say in the absence of standardization activity and appropriate IANA registration, all labels with hyphen in the third and fourth character position must be reserved.

And just a brief comment on the as rationale for that added wording. It is possible that tags could be used for other reasons besides IDNs in the future and the wording here would allow that flexibility.

And third level, if it's applicable, would be similar to the second level.

The next category is a category of three domain names -- or three domain strings, NIC, WHOIS and WWW. And those are reserved in current agreements for registry operations only. And the recommendation from the working group in this regard is that those would be reserved at the top and the second and the third level, just like they are today at the second and third level. So we are recommending that they would also be reserved at the top level.

Regarding IDNs, we recommend that no attempt to translate or transliterate those into IDNs be made and then those be reserved. The complications that get involved there appear to be really messy, so we're not recommending reserving IDN versions of those.

Next slide, please.

For geographic and geopolitical reserved names, we have quite a bit more work to do on this. I will let you -- you won't have time to read this. I am not going to read through the whole recommendation, but I will just tell you the state of it right now is that the recommendation is to try to tie in the guidelines of the WIPO 2 document in cases where a registry is located in a jurisdiction of a government that has signed on to those guidelines and, if not, letting local law govern that. These are -- this particular one definitely needs more work and, of course, we are waiting for the GAC guidelines in this regard, which we hope to get later today, which will guide additional work on this.

Go ahead and skip -- I think you can probably skip a couple slides here, Bruce. Thank you.

Another reservation requirement in current agreements is one that requires gTLD registries to reserved names of other gTLD registries at the second level and this is going to need more work, even among gTLD registries. There are mixed opinions in terms of whether this is a needed requirement or not. So more work will be needed on that category.

Next slide, please. And the last slide.

The next steps, okay. Obviously these recommendations need to be reviewed by the GNSO Council. They will be discussed in the meeting that follows this, the official council meeting. The statement of work for the reserved name working group provided for a possible 30-day extension of the working group and that will be considered in the council meeting that follows.

And then ultimately the goal would be that the recommendations would be in -- suitable format to include in the new TLD process so that it's clear when an applicant provides for a new TLD whether it be ASCII or IDN that they would know what names could not be used. In other words, what names would be reserved at the top level and at the second level and third, if applicable, what contractual reservation requirements they would be obligated to abide by.

>>BRUCE TONKIN: Thank you, Chuck. Are there any questions on the reserved names work? Okay.

I will just get a presentation on IDNs going. I have Ram Mohan who has been chairing the IDN working group. This working group -- the general position that the GNSO has on new gTLDs is that the same rules for, I guess, Latin character based gTLDs should also apply to internationalized domain names. But we do recognize it there is probably going to be some implementation issues that become more complex with the introduction of internationalized domain names, so we have formed a working group to consider that. If there are any policy issues that we haven't considered, to inform the council.

So Ram Mohan has been chairing that IDN working group and I will let him present his output so far.

>>RAM MOHAN: Thank you, Bruce.

The GNSO IDN working group was formed late last year and we spent a bit of time initially just gathering our thoughts about what we wanted to do. In general, our mission was to identify and explore policy issues that might lead to a PDP process inside of the council and to, first, get informed, we focused on four major documents: the new gTLD draft recommendations, the lab test outcomes, the ICANN staff issues report and the IAB document RFC4690. And our job was to research what policy implications there might be from not only these four documents but, in general, the topic of the introduction of IDNs at the top level, IDN TLDs and what policy issues might exist.

We began with the fundamental assumption that most of the technical and the technological barriers to the introduction of IDNs at the top level have either been resolved or very close to being resolved. And a result, the primary focus of the debate has to move on to the policy barriers.

The team itself was about 37 to 40 individuals who participated in the working group. 30 members and liaisons from the ALAC and SSAC as well as five observers and very able staff support from ICANN.

Our methodology was to go through face-to-face meetings. We held 14 teleconferences. We had very robust interactions on e-mail and also opened up a Wiki to go through both working definitions as well as work through statements that we were discussing at a given time.

We initially began with the number of areas to focus on, and we prioritized those areas to say how much time we ought to spend on it. And as you might expect, much of the focus went into the introduction of new gTLDs, the status of existing gTLDs at both of the registry level all the way down to the registrant level.

And also what technology and policy issues there might be and we had a little bit of discussion on the legal and WHOIS types of barriers but really didn't spend a great deal of time on that.

Bruce, if you can go to the next screen.

Now, we've adopted the following conventions for how we expressed our views. When you find in the document, which is posted on the GNSO site, when you find any statements that say "agreement existed," what that meant was that there was broad agreement, very little dissent with the views expressed. We kind of take it from -- as an equivalent of the rough consensus that we use in the IETF often. Support generally means that although there is some gathering of positive opinion, opposing views may and in many cases actually do exist and it is not a view that is necessarily representative of the entire working group that participated.

An alternative view is actually a level lower often than support.

So in brief, we came to a number of areas where we had agreement and I'm going to focus most of my comments here on the agreements that we came to. If we can go to the next slide, Bruce.

The first of these was agreement to avoid ASCII squatting when new gTLDs are applied for. This is really only in the case should there be a situation where IDN gTLD applications are not accepted at the same time as non-IDN gTLD applications. So pretty specifically in that case to ensure that ASCII names do not get applied for that might later squat or infringe, if you will, upon an equivalent IDN name.

Other than that there is really not much that separates it from a regular non-IDN -- sorry, yeah, non-IDN ASCII TLD application. So the first one is kind of specific to a possibility that the application process gets separated and IDN TLDs aren't accepted at the get-go.

The second agreement was that for geopolitical names, geographic names, other names that have political significance, that some consultation with the GAC is a good thing. We acknowledged that consultation with the GAC may not lead to final answers but, however, we recognize that especially with geographic terms as represented in local scripts, as well as political terms that have meaning, it might be worthwhile asking the GAC for their thoughts on this area.

The third agreement area was that it makes a lot of sense -- now, in all gTLD applications, ASCII -- non-IDN gTLD applications and IDN gTLD applications, getting support from the community is part of the principles that we endorse. But what we're saying here is that if you are applying for a specific IDN gTLD, something that's in a particular script that represents a language, then it makes sense to get input from the language community when the evaluation of such IDN gTLD strings occur.

Now, we've also said that a great deal of the initial responsibility ought to be on the applicant to make sure that the strings that they apply for, the label that they apply for actually is accurate, doesn't offend some part of the community. So a large part of the onus is on them.

But, nevertheless, when it comes to the time to evaluate these IDN gTLD strings, some input from the specific language community might be relevant and useful.

The fourth area of agreement was that when applying for an IDN gTLD, it is really not a whole lot different than a non-IDN gTLD and, therefore, it is one string per new IDN gTLD that is applied for.

The fifth area of agreement was to limit variant confusion and collision. Now, when we talk about variants, I encourage you to go take a look at the working definitions that are in the document as well as on the Wiki site. But we're talking about variants in a fairly restrictive technical sense. But what we're saying is that when new IDN gTLDs are applied for, one important criterion is that the applications ought to be in such a way that limits variant confusion and collision.

A linked area of importance is also to ensure that confusingly similar strings also -- there should not be confusingly similar strings that are applied for. That was the sixth area of agreement.

Bruce, if we can go to the next slide deck. The seventh area of agreement was that we believe really priority rights as such do not exist for -- in the new gTLD strings and new domain names. So what we are saying here is if you are the registrant of a domain name in a non-IDN string, in a quote-unquote, ASCII TLD right now, that doesn't necessarily give you automatic grandfathered rights, if you will, in the new IDN gTLD string being applied for. We agreed that that actually works not just at the registrant level but all the way up to the registry level as well.

Now, clearly there are some areas where one could assert not priority but a right to a to that intellectual property space. Intellectual property could be one way of asserting that. We are not obviating that. We are merely saying the mere fact of you having a domain name or being a registry currently doesn't automatically give you a priority, so to speak, in the new gTLD round for an IDN gTLD.

We've also -- we had pretty strong agreement that aliasing, as it has been discussed so far, it has unfortunately been reduced to the level of talking about a few technology solutions and we really thought in our working group that was both unfortunate and actually a wrong approach that the real focus ought to be on looking at aliasing as a policy matter and not worrying about the technical implementation details that really the policy issues have to be considered and some of the -- and that the council should think about aliasing, bundling, et cetera, as a policy issue, not as specific, you know, technology issue.

In the past, some technological solutions have been suggested and we think that's fine but that's really not the right kinds of focus that the council and even in the community we ought to have. We ought to have much more discussions on what is the right thing to do when you have a string that has a variant and especially at the IDN -- at the top level. What is the right thing to do when a string has another variant associated with it. Do you bundle them together? What are the kind of policy mechanisms that have to be addressed.

And that's really the right level to be at.

The ninth area of agreement was that strong exhortation and encouragement to adhere to a single script, to really discourage script mixing, of course, is ASCII exception, and there also -- there might be some restrictions that might be based on specific circumstances that attach to a language that might require the mixing of scripts. But in general, the IDN guidelines provide clarity in -- and pretty specific guidelines in terms of how or in what circumstances mixing ought to be allowed. But in general, the IDN working group's strong agreement is adherence to a single script is a good thing, even though we also recognize that from an enforcement perspective, it may not be possible to require or enforce the adherence to a single script at all levels of a domain name itself.

The final area where we had strong agreement was that we believe that the current UDRP process and the UDRP system that is in place seems to be sufficient for the introduction of new IDN gTLDs. There is really not a need to go and revisit and get to a new dispute resolution process. The current process seems to be handling it fine.

So that kind of summarizes the general -- the main areas of agreement. The thoughts of the council are to take these areas of agreement, to also read the rest of the report. There are a number of other areas where there were statements of support that came through, and I'm not going to go through all of those statements of support because there are -- they don't represent the consensus or the general agreement of the entire working group and I'm focused on making sure that your attention looks at the areas.

In general, what the working group is saying is, we think the new TLD -- the introduction of the principles that the council as a whole has been working on are good things. When it comes to IDNs in specific, you know, look at these 10 areas of agreement. You will find that I think in many cases, it's complementary but there are some necessary additions that you do need to take because IDNs require some -- not necessarily special handling, but extra handling than just a regular ASCII TLD. Thank you.

>>BRUCE TONKIN: Thank you, Ram. Are there any questions or comments on the IDN working group? Ray?

>>RAY FASSETT: Ray Fassett. Can you hear me? Can you go back to five and six? The agreements on five and six? Actually, it was number three.

What is meant by "language community"? Was there a definition to that?

>>RAM MOHAN: We carefully shied away from defining what is the definition of "language community." In fact, the document states that that is work to be done. What we recognized was that you currently have a public comment process and a specific process for requesting input, but what we are suggesting here is that especially because it's -- the application comes in a particular script that represents a language, there might be -- not "might." There is a need to ensure that members of that community -- it might be in a geographic region. We were careful not to specify how to do it, but to make sure that members in that region -- in that -- the Diaspora that is interested in -- or that could be interested in that language being represented at the top level has a chance to be notified that there is something like this going on, and, therefore, an opportunity to provide input. But this is, I think, something that the council and ICANN need to think about.

>>RAY FASSETT: Okay. That comments across to me as a bit problematic in a general sense, just from a common sense point of view. I'm not sure why -- I'm not sure how I can articulate that yet, but it seems problematic.

And then my second question to that point is: Is that meant to be consultation from a language community in regards to the overall PDP '05 process or is this TLD by TLD? Application.

>>RAM MOHAN: I -- it almost sounds like you were sitting in some of our conference calls that went very long because of the discussion on this topic.

There has been discussion, Ray, of actually asking for specific input on a case-by-case basis. I don't think the in -- our intent is not to get input on the entire PDP itself. Our intent is that if you're an applicant who is applying for a specific gTLD string that is represented by a script that purports to, you know, represent a language (a) it's your responsibility to make sure that you've actually consulted the right folks to make sure that, you know, you're not -- what you're asking to be represented is actually meaningful and accurate, okay? And (b), from the evaluators, to make sure that they get input from interested people who may have an opposing or supporting point of view, frankly, for that IDN gTLD represented in that particular script.

>>RAY FASSETT: Uh-huh. And, you know, the PDP '05 process, for example, is taking into context how people can object or voice an opinion or what have you, so that mechanism is being built in there.

>>RAM MOHAN: Absolutely. And this doesn't attempt to replace that mechanism. This merely says that when it -- and, in fact, PDP '05 has very good language about -- you know, respecting and getting input from cultural contexts, and that's perfectly fine here.

What we explicitly did in the working group was to say: Even though there are areas that are -- what we're saying might be redundant with what's already in the PDP '05, in the IDN context it is worthwhile repeating it, because it is that important to make sure that the language -- language Diaspora, you know, gets a chance to have their say.

>>RAY FASSETT: Yeah. And, you know, the issues are really complicated and really quite beyond me, personally, but again, just from a common sensical point of view, it -- it would really be interesting to apply that to English. You know, what language community would -- you know, if this particular criteria existed in ASCII II, if we think about it in those terms, what language community input would you -- would that kind of applicant need to get, I wouldn't know where to start.

>>RAM MOHAN: I think that's -- that's actually a pretty good intellectual exercise to think about, because English is a language, and if somebody did -- did, you know, apply for a TLD that said C-l-u-o-r is for color, would not would expect somebody to come in and object and say, "That's wrong. It really doesn't -- you know, it's not the right representation of a word that means color." Right? And you would -- you know, and one could expect some -- you know, a professor of English to come in and say something in the public comment forum or perhaps a society that is focused on English or an association that works on English language to come in and have a comment on that.

>>RAY FASSETT: Right. Okay. Thank you.

>>BRUCE TONKIN: Go ahead. Can you please state your name and then ask your question. Thanks?

>>ALEXEI SOZONOV: What's the council going to do with support statements? For example, financial and technical criteria.

>>RAM MOHAN: And this is Alexei Sozonov.

>>ALEXEI SOZONOV: Right. Who is a registrar in Russia.

>>RAM MOHAN: Who is a registrar in Russia and was in the IDN working group. What we're suggesting to the council is to read through the entire report, to look through all the support statements that are there, as well as the agreement -- the statements of agreement. I think the statements of agreement have a very clear path forward. Where there is overlap, note the overlap and just understand that there is very -- you know, even stronger support for it. Where there is something complementary, you know, consider adding those complementary areas to your current process for new gTLD evaluations. Where there are statements of support that -- that clearly indicate that there is a strong support from a community or a group, and perhaps equally strong opposition, I think it's up to the council to think about what are the policy implications of such a thing and then perhaps to think about whether a PDP process ought to be initiated. To go develop policy for it. After all, as a working group, our job was to initially get an inventory of the kinds of issues that are important in IDNs, and then bring that to the council's attention and give council a very clear way forward. And I think for the support statements, they will note that there are some support statements that are controversial in nature, and there's nothing wrong with that. In the working group, we made actually very sure that we didn't try to hide the -- you know, the controversial areas. They're all there, and I think it's up to the council to think about whether some of these areas of support deserve further study and perhaps deserve some approach to arrive at consensus.

>>CHUCK GOMES: Ram, could I ask a question in this regard? The -- I think as councillors, one of the things we're going to have to consider is recommendations from the report with regard to IDNs ideally being introduced at the top level at the same time as ASCII in the next round of ASCII TLDs, and so one factor that's going to come into play here is if, in these areas where there isn't agreement, if we do more work or even, as Ram stated, start a PDP, would it be better for us to let that happen and then wait and introduce IDN TLDs or is it better to make sure that IDN TLDs are introduced quickly? And it would be interesting to hear what your opinion is on that because a lot of work in some of the areas where there's not agreement could, in fact, result in IDN TLDs being introduced later.

Do you have a priority in that regard if it comes down to that?

>>RAM MOHAN: Thank you, Chuck. We did discuss this topic in the working group, so I will first state the working group's -- kind of a summary of discussion from there and then I'll provide my own personal perspective.

In the working group, there were -- there was strong support for two completely opposing positions. One was that all policy work must be complete before any IDN TLD applications or evaluations be considered, okay? There was quite a gathering of support for that.

And at the same time, there was also very strong support for: Do not wait. We waited too long. Let's get IDN TLDs applied for and let's have the applications come in at the same time.

Now, the evaluation of these applications might take longer because of specific considerations that, you know, you have to look at on IDN TLDs, and that's really my own -- personally, that's my perspective: Allow the applications to come in contemporaneous to non-IDN TLDs, to ASCII TLDs, if you will, but start the policy thinking and the policy development process now for those areas where you know there is clear disagreement and we need to, you know, arrive at some -- some consensus, right? Begin that, knowing that that's going to take a period of time, but let the applications come in, let the applicants -- let's send a clear message to the community that is intending to apply that we're open to accept new gTLDs, whether they're in IDNs or not in IDNs, and let's accept them as applications, knowing that the evaluation for it is going to require work along the way.

>>CHUCK GOMES: So in other words, then, the application would be submitted but it would be put into a holding status while the policy development work is finished? Is that what you're suggesting?

>>RAM MOHAN: I think that's inevitable. That's what's going to happen. But I think that's better than not accepting the applications at all at the get-go.

>>MIKE RODENBAUGH: I have a question for you, Ram. Of these 10 agreements -- well, I guess it wouldn't be the agreements but which of these concepts do you think need a separate PDP? In other words, which of these do you think are really not issues that we're already considering on the task force addressing new TLDs generally?

>>RAM MOHAN: That's a tough and a good question. If I look at no. 4, I think that's already covered. No. 6 is already covered. No. 5 is something extra but doesn't -- I don't think it requires a PDP. No. 3, again, I don't think requires a PDP, but it requires thought, as Ray was pointing out, it requires thought into how to -- how to actually do the work without -- while being representative and at the same time not letting it get out of control.

>>MIKE RODENBAUGH: And just real quick on that, I mean, we definitely are covering, you know, community input into all TLD applications generally.

>>RAM MOHAN: Right, right. You know, I'm -- I was very glad that we were able to give you no. 2 and not have to provide the solution on that.

[Laughter]

>>RAM MOHAN: And if we could go to the next slide, Bruce, no. 7 to some extent has already been covered, I believe. No. 8 actually I think will require you to develop policies. You do not have an approach for that in the current process, so I think no. 8 will require you to do some work there.

>>BRUCE TONKIN: Just on that one, Ram, because I don't see that, personally. Why do you need a policy on aliasing? Do you have a policy on aliasing at the second level currently?

>>RAM MOHAN: There are policies on aliasing at the second level.

>>BRUCE TONKIN: Or can you give me an idea of where?

>>RAM MOHAN: If you look at --

>>BRUCE TONKIN: Because I guess I'm not sure what you mean by aliasing, I guess, so I need an example.

>>RAM MOHAN: Okay. So different registries apply the word "aliasing" differently. If you look at the example of how bundling, for example, is done in the CJK instance, if there is a particular label that is reserved or that has been registered, then in that context, we have registries and registrars saying, "Here is another set of strings that are exactly the same, that are identical," okay? That are variants of each other, if you will. They get put in a bundle, right? And then that bundle is provided to the registrant at one cost for -- you're effectively buying one domain name even though, in effect, in the zone file, you do not get a single entry. You get, you know, anywhere -- four or five or six entries. You also have other issues, for example, how do you deal with transfers, how do you deal with renewals, what do you do when there is a lawsuit, for example, that says this variant that is a part of a bundle, that specific variant alone must be transferred and, you know, must be promoted to be a parent, not a child of the original string. And I think those -- there are some issues there that are not necessarily addressed in any sort of global level or uniform level. Most of our experience is empirical, coming from, in many cases, what the -- what's been done in the CJK area, and I think that's -- that's why I'm saying you might need to do more work there. Because it -- it's larger than merely how do you register the string. It's then what do you do with it.

>>BRUCE TONKIN: Cary, go ahead.

>>CARY KARP: Since Ram is getting into -- since Ram is getting into the subject of bundling, I mean I think it should be noted that this is one of the major factors in all of this, that we need to consider in significantly greater detail, and it would probably be a very good idea if there were a document produced describing all of its intricacy before we go much further into its discussion.

>>BRUCE TONKIN: Yeah. I think, you know, my kind of rule of thumb on all these things is can you express the same problem in non-IDNs and I think you can. You could potentially bundle --

>>CARY KARP: This is not an IDN issue. This is right at the top of the CC list of concerns.

>>BRUCE TONKIN: Yeah.

>>CARY KARP: Our country -- the name of our country exists and there's many languages that exist and quite a large number of them are quite content with the ASCII repertoire. Where does that leave us? And I think one of the perpetual issues that tends to confuse IDN is the number of aspects of the IDN concerns that are not specific to IDN. So --

>>BRUCE TONKIN: Yeah. I mean, if I was just to use it in non-IDN characters, if I was to have the domain name dot Germany and the domain name dot Deutschland, they both can be expressed in non-IDN terms, but a -- an organization may wish to operate both of those and effectively alias the outcome. So it's interesting so to just consider it from that point of view.

>>CARY KARP: The concept and the conundrums attaching to the internalization of the domain name space are -- overlap but are not identical with the issues that attach to replacing ASCII with Unicode as the basic character set underlying what we're doing.

>>RAM MOHAN: But fundamentally, Bruce, I think you're right in the policy required here would not be necessarily just for IDNs, but it would be for that concept as a whole.

>>BRUCE TONKIN: Yeah. Understood. No, that's useful.

>>MIKE RODENBAUGH: But just to finish on that and then you can address 9 and 10 maybe but isn't 8 -- if you're assuming that you want muddling. You want people to be able to apply for Deutschland and Germany, that's totally opposite to I think the first or the second one that says one spring per application.

>>RAM MOHAN: It wouldn't -- and, again, I think this needs further peeling of the layers of the onion, which is bound to cause tears, but --

[Laughter]

>>RAM MOHAN: -- I think what's going to happen is that in some cases, what you're saying is true, in other cases, what you're saying is not true, and I could probably spend a little bit more time explaining it, but perhaps we should -- I think Cary's suggestion of a -- of a facts sheet, if you will, is a very good idea, and, you know, I'm -- I'm starting to work directly with Kieren to see if we could get something going there.

>>BRUCE TONKIN: Yeah. I think generally what you're talking about is the concept of bundling, and are we treating each application independently or are we able to treat an application set in some way. So one organization requests a set of TLDs. And I think the view -- I think particularly in the first round, probably, because I think there's been a little bit of discussion of this at the committee level, is you may wish to treat each of those independently. Let's say I had a dot Germany and a dot Deutschland. The first instance would be to treat them independently from the point of view of, you know, is the organization able to run it, et cetera, et cetera. And then you'd say, okay, so these two organizations are the same, they're both passed, so the single organization got dot Germany and dot Deutschland and then that single organization says we would like to operate that in -- in an aliased manner. And how do we cope with that. So I think we have to think it through a bit more, but I -- it's really just a question of are we going to allow people to apply for a bundle or are we treating each application independently, as Mike had suggested, and then after those applications are granted, if you like, what happens next, because an organization that's got two things may decide to operate them in a particular way.

>>RAM MOHAN: True. And I think if you had an organization -- to use your example, if you had an organization that applied for Deutschland, also said that Deutschland can be represented not just this way, but there is another representation that is exactly identical and it's a variant and that these two are commonly recognized in our -- in our language community or in the -- and then those who use this as the compacted same word, not Germany and Deutschland which are semantically the same but the same word.

>>BRUCE TONKIN:.

[Speaker is off microphone]

>>RAM MOHAN: They're not confusingly similar, they don't look similar, but if you have the two of them kind of combined, then that I would consider to be a bundle and, therefore, I would -- I would suggest that that application would be a single application because it's Deutschland and Deutschland except it's -- you know, one might have -- and I'm making this up here, this is not exactly accurate, but, you know, one with an umlaut and another without an umlaut, as an example but there is really better examples in other languages.

>>BRUCE TONKIN: Okay. Yeah.

>>CARY KARP: I'm leaping way past where I wanted to, because I don't regard the concept -- bundling is way too important to be discussed without it being mature for that discussion, but the real problems that attach to bundles of names is not creating the bundle; it's what on earth one does when one discovers that there was an error in the way the bundle was created because you can pluck an element out of a bundle. You have to destroy the entire bundle. And boy, does this get complicated really quickly and it would probably be best if we tabled that discussion until we've had time to prepare, I suppose what we'll be calling the briefing Papal.

>>BRUCE TONKIN: Yeah. Okay. That's helpful. Okay. Last comment on this topic, Subbiah.

>>SUBBIAH S.: Subbiah IDNs.net. I know there was a discussion just now, two opposing thoughts of whether the -- you know, everybody should apply together and one of the views there was that I mean for both IDN and gTLD -- ASCII gTLDs. The view -- one of the views was that you would apply for the IDN gTLDs and have that sort of application waiting for a fairly -- possibly a long period of time while IDN policy gets fully worked out. My thought here is, does that -- I know yesterday there was a, you know -- in the other discussion, in the previous discussions, there was sums of the order of a hundred thousand dollars and more that were bandied about in terms of application fees and I think there was some comment by myself and some others that the cost of such application fees are actually probably pretty high for representation from an IDN community. I mean, meaning communities that are poorer, probably coming from regional parts of the world.

Now, if there was an application stage where it's a waiting stage, are we talking about hundreds of thousands of dollars in -- sitting in ICANN bank? Is that -- is that -- is that something that -- you know, if that's the approach we're taking, I just was wondering.

>>BRUCE TONKIN: Yeah. I don't think we know. You know, that's certainly undeveloped. If I just take the more general consideration that people have put forward, though, from -- from some communities that the -- the technical barriers might be too high and the cost barriers might be too high, to my mind and I'm giving this perspective as an engineer, it's not dissimilar to education. You could say if you want to get an engineering degree in Australia and your first language is not English, and let's say you also haven't studied mathematics in high school, it's tough. And so you've got two approaches. You can say, okay, we want to increase the diversity of engineers, so we'll allow people to get their degree without a math background or we'll somehow lower the standards to make it easier for them to get an engineering degree, that's one approach. Or the other approach is, you provide support which can be a range of financial or otherwise to allow that person to meet the same standards as every other engineer. And I think the issue is not that dissimilar at ICANN. It's a choice you make, and I'm not trying to make that choice here but I just want to make that clear here that I think the way the committee has been addressing this so far is by saying we're going to come up with minimum standards and for those that can't reach that minimum standard, if we genuinely want to increase diversity and, you know, allow broader use, then what we then need to do is look at what's the support mechanisms to help those people reach that standard. Now, that could be financial support, it could be education and training, it could be a range of things, but, you know, those are really the two -- two options, I think. Go ahead.

>>HONG XUE: Okay. Thanks. I'm Hong Xue, a member of At-Large Advisory Committee and also the liaison to the IDN working group. I have one comment, and one question.

Would you please go back to no. 6? Well, sorry, it's actually no. 3.

We believe the language community input for the policy developing process of IDN is really important and At-Large Advisory Committee strongly support that proposal. At-Large Advisory Committee made a statement on this issue and I'm sort of our liaison [inaudible] in providing information on this.

For our question, we can't see an IDN PDP at present, so I wondered whether the new gTLD PDP evaluation criteria could possibly be applied to the IDN gTLD evaluation and the day before, we learned from Mr. Bruce Tonkin that one criterion could be to consider the input from the established institution in one community, and in our context, it would be established institution in the language community. And however considered by the present situation, in some language communities, there are established institutions such as Arabic league or Chinese domain name consortium, but in other language communities, there is no such established institution and how do you handle that? So I'm really interested. Thank you very much.

>>RAM MOHAN: Yeah. I think that providing a common place where all those who are interested in commenting on an IDN string that has been applied for is important, number one.

Number two, I think it's -- for the council and for ICANN in general, I think there is a responsibility to try and ensure that when an IDN TLD string is applied for, that there is a sense of which either -- often language is associated with geography, so at the very least, which geographic areas that information ought to be disseminated to, so that those who might be interested in that region or in that language-speaking area might be able to come back and comment. There is -- the new process -- the PDP '05 clearly seems to have established mechanisms for getting input from a wide range of people. I don't think we need to change that, but I think what has to be added is the recognition that merely publishing something on the Internet might not be sufficient for -- for an IDN TLD that -- whose original goal is to actually bring onto the Internet those who are currently not served, because they are, you know, kind of displaced because they're only -- they're not able to use ASCII. So I think that probably is an addition for both the council and for ICANN in general to ensure.

Other than that, I -- I personally don't think it's a terrific idea. It is not a good idea to create a special committee, if you will, on a per-language basis, et cetera, because I think that leads -- it's a slippery slope. One expert can clearly be replaced by another. So I don't think -- that has come up for discussion in the working group and I don't think that's a good idea.

>>BRUCE TONKIN: Just a comment. It is probably better to discuss this with you in more detail off line because it is quite complicated depending on which issue you are talking about. I see a difference when we are talking about new gTLDs and in the process there is a number of different process flows, but I will pick one of them where there may be some confusion. If I am using the word "bank," what we are basically saying is if you have bank in Chinese characters, are we talking about the established community that relates to the use of the word bank in China but it is the established banking institutions we are talking about. We are not talking about the Chinese language institution, we are talking about the banking institution in that case.

We haven't a concept merely because it is in a particular language means it needs to get approval in some way for use of that language. What the concept of the established institution thing is related to is the meaning of that word related to an established institution. So does it mean -- is it bank or is it the word "China" related to a geographic region? Or is it the word "police" which relates in Chinese -- which obviously the Chinese Police Association would have input.

That's separate to the discussion that we have been talking about with string conflicts and confusingly similar. So if two strings are confusingly similar, that is where we would be consulting with the language community that's affected or relates to those strings.

And the question then is, is there an established institution that's great? We would obviously consult with that established institution and make that decision on confusingly similar. If there is not, then the approach would be to get some experts -- individual experts in that language that would be members of whatever that evaluation panel is to decide whether those two strings are confusingly similar. So they are very different things.

One is consulting a language community about whether something is confusing versus allocating a particular string that has meaning to some part of the language community and it is really that part of the language community where that meaning is relevant. It is different concepts.

Last go at it, Werner because we need to move on.

>>WERNER STAUB: I would like to briefly address the statement that Ram just made about specific language committees in the context of ICANN or other context, of course, centralization, authority to speak about many languages at once or maybe all the languages. And there was an interesting anecdote the day before yesterday at the ccNSO GAC working group and a discussion was presented in terms of what ISO can do and what ISO is currently doing in the context of getting information about language, putting that into standards.

It turned out that in ISO's view, India had two official languages. And then the Indian representative drew the attention to the fact that there seemed to be 22 official languages and not two official languages in India.

And this example just shows how difficult it is. If we go to a concept of first vesting authority into a committee and then basically waiting for something to come out actually. That usually comes to surprising and not useful results.

On the other hand, saying we don't need anything is also probably wrong. We can think of ICANN making resources available for people to know where to go to. Typically a member of a given script or language community wouldn't know where to go to actually get some consensus on a specific approach such as should the Cyrillic community in the case of Cyrillic ccTLDs use two characters, three characters or whatever. It is probably a good idea that they consult amongst one another but they don't necessarily have a forum to do that. In this case, if they don't or if they feel this could be done by ICANN, should have an opportunity at least to get their requests published.

In this respect, I know, for instance, CENTR wrote to ICANN on behalf of three CENTR members saying these three particular members would suggest the following strings.

I think it would be a good idea if at least such things could be published, ICANN could actually then, so to speak, make discussion -- facilitate discussion, actually create an informal forum for these kinds of discussions.

>>BRUCE TONKIN: Thanks, Werner. At that point, I will thank Ram for his report from the IDN working group. Ram, perhaps you could let us know this afternoon there is a further opportunity to talk about IDNs, is that correct?

>>RAM MOHAN: From 5:30 in the evening until 7:30 there is an IDN workshop and one of the interesting things is that this is a workshop that combines input from the GNSO, ccNSO and the GAC. You will find pretty much we will be covering not only the topics that were here but also topics that are of common interest across these communities are actually going to be quite controversial.

So invite you to come. It is an open, informal discussion from 5:30 to 7:30 today.

>>BRUCE TONKIN: Thank you, Ram.

So I am going to close the public comments on the IDN topic at this time. And there will be another opportunity for that this afternoon.

We have one final report in this GNSO public forum and that is on the topic of reserving the rights -- or protecting the rights of others.

>>KRISTINA ROSETTE: Bruce, I would actually propose that given that we are running almost an hour behind and that there are, in fact, some council members that are planning to leave the meeting immediately after our originally scheduled end time, that we perhaps fold in my presentation towards the end of our council meeting and perhaps put it on as kind of the last agenda item instead.

>>BRUCE TONKIN: We could do that. Perhaps just give a high-level summary of where it is up to. I think that's probably useful.

>>KRISTINA ROSETTE: Absolutely. The working group is really intended to fold in to the new gTLDs' process and specifically it has a twofold purpose. The first is to review and identify and analyze those processes that have been implemented by previous gTLD operators in connection with protecting the rights of others, particularly with regard to the startup registration processes.

So that portion of it is really intended to identify the processes, identify the commonalities and variances and distill those down, perhaps, to a common set of principles that have been applied.

The second part of the working group is really intended to develop -- to determine whether, in fact, there is any consensus or agreement, rather, within the working group as to whether or not there is a need in connection with the new gTLDs to incorporate a requirement for such a process into the contract as, perhaps, on an ad hoc basis or, rather, going forward as the future basis for a PDP. And if so, what those mechanisms would look like.

At this point, we are about a third of the way through the process. We've divided up into the project teams that are in the process of not only reviewing and analyzing the previous mechanisms but reaching out informally to the various constituencies to obtain their views as to these various processes in terms of what worked, what didn't, why, why not, what would you like to see, what would you really not like to see, that type of thing.

Currently, we are on schedule to submit a draft report later on in April with a final report due May 17.

>>BRUCE TONKIN: Thank you, Kristina. So we will now close the GNSO public forum at this point. And those that have other comments, I believe, there is an open mail list. Is that right, Maria, for the public forum? So if people wish to submit a comment while they're here, if they go to the public participation part of the ICANN Web site and submit their comments in writing, we will review those as well.