GNSO New gTLDs and IDN Working Group 25 March 2007 >>BRUCE TONKIN: Thank you. Let's just briefly introduce ourselves again, just so that for the recording we know who we have in the room. So starting -- we'll start with Neal on that side. Do you want to just introduce yourself, Neal, just for the purpose of the recording? >>NEAL BLAIR: Neal Blair, observer from the BC. >>MARIA FARRELL: Maria Farrell, GNSO policy officer with the ICANN staff. >>GLEN de SAINT GERY: Glen de Saint Gery, the GNSO secretariat. >>BRUCE TONKIN: Bruce Tonkin, chair of the new gTLD committee. >>MIKE RODENBAUGH: Mike Rodenbaugh, GNSO Council. >>PHILIP SHEPPARD: Philip Sheppard, BC, GNSO Council. >>CHUCK GOMES: Chuck Gomes, registry constituency. >>CRAIG SCHWARTZ: Craig Schwartz, ICANN staff. >>PATRICK JONES: Patrick Jones, ICANN staff. >>DIRK KRISCHENOWSKI: Dirk Krischenowski, dot Berlin and BC member, observer. >>JOHANNES LENZ-HAWLICZEK: Johannes Lenz-Hawliczek, dot Berlin, observer. >>NORBERT KLEIN: Norbert Klein, council member, noncommercial user constituency. >>BRUCE TONKIN: Thank you, Norbert. Okay. So just picking up where we left off yesterday, Chuck, do you want to just take us through the geographic and geopolitical reserved names? >>CHUCK GOMES: Okay. Oops. Better turn my mic on. Okay. Good morning to everybody. The geographic and geopolitical, as I indicated at the end of the day yesterday, is one that it's really helpful to read through the full report and the appendix for this one, because quite a lot of research was done, in particular, with WIPO II, and the recommendations actually tend to follow some conclusions that were made in that effort. You can see this is a much more lengthy recommendation, but because of the importance of it, I will go through and read it. First of all, if you do have the document, you'll probably find it helpful to look at that, and the recommendations are in Section E, again, of the document, and then the full report can be found in -- I'm looking at the list of tables, and it -- where is that one? How come that one's not on there? Is that one missing? Apparently that one is missing. >>PHILIP SHEPPARD: Page 24? >>CHUCK GOMES: Yeah. Okay. 24 sounds about right for the table in the document. Page 24. It's not on the list of tables. But it's also, then, in Appendix H. You can find the full report of the subgroup in Appendix H. And I didn't mention this yesterday, but you can see in the full report the people who actually made up the subgroup of this, and then of course their report was presented to the full group for consideration. So for top-level ASCII and IDN, here's the recommendation: In order to approve the introduction of new gTLDs using geographic identifiers, ICANN shall require the solicitation of input from GAC members and/or governments associated with the potential geographic string, whether it's ASCII or the IDN. And of course we were hoping to get that feedback from them this week. No. 2: Additionally, registries incorporated under the laws of those countries that have expressly supported the guidelines of the WIPO standing committee on the law of trademarks, industrial designs, and geographical indications, as adopted by the WIPO general assembly -- the member states -- or have other related applicable national laws must take appropriate action to comply with those guidelines and those national laws. Registries incorporated under the laws of those countries that have not expressly supported the guidelines of the WIPO standing committee, et cetera -- and I won't read all of that -- must take appropriate action to comply with any related applicable national laws. So the approach taken by the working group is basically to require compliance with the WIPO procedures, in case of those states that comply with WIPO, or that are member states in that and have agreed to that, and in other cases with local laws of their jurisdiction. >>BRUCE TONKIN: So Chuck, just to sort of translate that legalese, so let's take the country name "Australia," and maybe people who understand some of those laws could explain this to me a little bit further, but does that basically mean that in the United States you couldn't have a product called "Australia"? Is that effectively what that's talking about? Where does that come from, that -- You're saying that there's laws on trademark, industrial design, and geographical indications. >>CHUCK GOMES: No. That's all the title of that standing committee. >>BRUCE TONKIN: Right. But what's the actual underlying law on that? That's what I'm asking, I guess. >>CHUCK GOMES: Well, it's not not law, as I understand it. >>BRUCE TONKIN: Yeah. That's where I'm getting a bit lost here, because I don't understand why it's got anything to do with the guidelines of the WIPO standing committee. I mean, either there's treaty, like there's the Paris convention -- because that doesn't mean anything to me, I really must admit. >>CHUCK GOMES: Yeah. Let me go over to the report. >>BRUCE TONKIN: Because you're talking about guidelines of the committee, and then you're saying, "other related applicable national laws." A committee isn't law, and guidelines -- so basically, there must be some underlying law there that you're requiring to comply with, and my question is, I'm asking: What's that underlying law? >>CHUCK GOMES: No. I believe the only actual laws that are referenced in this is the alternative, if a country has not signed on board with the WIPO guidelines. >>BRUCE TONKIN: That's what I'm struggling with. I don't understand. A country wouldn't sign onto guidelines. There would be a treaty. Jon, can you elaborate on that? >>JON BING: Well, I'm not a specialist in this field, but as far as I understand, it is the WIPO treaty, on the recognition of geographical names as typical for certain products, and so on. >>BRUCE TONKIN: Typical for? >>JON BING: Certain products. >>BRUCE TONKIN: Yeah. I think that's what needs to be referenced, Chuck, the actual treaty. >>JON BING: Yeah. >>CHUCK GOMES: Okay. >>JON BING: So Australia probably won't be the main example, but Champagne would be a good example. And they're certainly thrashing this out, because many of these geographical names have become typical and used across borders. Like the Dutch [inaudible] which is no more protected under [inaudible], which is a town in Holland, but, on the other hand, [inaudible] is protected. >>BRUCE TONKIN: Right. So that's quite specific, isn't it. So you're talking -- yeah. So talking about the concept of champagne and -- >> [inaudible]. >>BRUCE TONKIN: Yeah. I think there just needs more work, that wording of that whole second section. >>CHUCK GOMES: Okay. Yeah. >>BRUCE TONKIN: And again, I think I'd refer to an actual treaty, rather than talking about guidelines of a committee, because countries wouldn't sign onto guidelines. They'd be signing onto a particular treaty, and we need to identify that. And then we need to give some examples of some of the things that are protected under that treaty. >>CHUCK GOMES: Okay. And you'll see that all of the recommendations follow this same pattern. This unfortunately was one that was completed late in the seven weeks or so that we met, and so it was kind of -- it was wrapped up in the very last week. >>BRUCE TONKIN: So if I kind of paraphrase that -- and I just want to sort of get the gist of it -- so there are some laws that either ICANN needs to obey, because it's in the U.S. and a court has jurisdiction over it, or where the registry is located it needs to obey the law, and that's kind of a status quo that's applying there. >>CHUCK GOMES: Uh-huh, right. Nothing revolutionary there. >>BRUCE TONKIN: Yeah, yeah. So really what we need to identify, from an ICANN perspective, is: Is there laws that are generally adopted by lots of countries and that it would make sense to have a dispute resolution process that we could use as part of a streamlined dispute process in terms of the introduction of a TLD, as opposed to something that we're just saying, okay, that's very specific to that particular country or law, and we're going to leave it to that law, but -- so we need to kind of -- yeah, that's why it's very important to sort of pull out what the actual underlying treaty is, and it's a treaty signed by a lots of countries, as the Madrid, Paris convention and the trademark stuff. >>CHUCK GOMES: Right. >>BRUCE TONKIN: So it's kind of a similar thing, and I'm not sure whether that's of the same standing or not. And then the other thing is then to try and translate that into what is our ICANN process going to be. So just taking no. 1, are you saying that's input that we receive to create a reserved names list, or you're saying that when we -- when somebody applies for a geographic name, we go and get advice after -- you know, after they've applied for it? Is it before application that we're getting this advice? >>CHUCK GOMES: I don't think it's -- I think it's up to the individual registry, is the way this is being written. >>BRUCE TONKIN: No. I'm talking about Recommendation 1. >>CHUCK GOMES: Oh, okay. Oh, this -- no, no. That is simply -- oh, I understand your question. We need to make that clear. My understanding on that -- now that I understand your question, I could be off base. I'll check this with the committee members. Avri will be in here in a minute. She's running a little bit late. And Mike Palage was the primary author here. And the -- my understanding was, that was consulting up front, like we're doing right now with the GAC. >>BRUCE TONKIN: Yeah. With the intention to form a reserved names list? So we're basically -- >>CHUCK GOMES: There's no intent to consult with the GAC on a particular application with regard to geographical identifiers. >>BRUCE TONKIN: Yeah. Okay. But if -- let me understand the process. Are you suggesting that ICANN says, "Okay, we're going to go ahead with new gTLDs, governments have got 30 days to submit names that they want to put on a reserved word list"? Is that the kind of process you're envisaging? I'm just trying to understand how you translate this. >>CHUCK GOMES: No, we're not. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: What we're suggesting is that the applicant that is going to apply for the gTLD will abide -- will be required to -- if they're from a country that has signed on to the WIPO requirements, then they would comply with those. If they haven't, then they're just responsible, like always, of complying with their local laws. So we're not -- we're not putting -- we're not looking at having a list of geographical, you know, reserved names. >>BRUCE TONKIN: Right. Because that's basically got to be the recommendation, then, because -- >>CHUCK GOMES: What's got to be the recommendation? >>BRUCE TONKIN: Well, that you're not having a list, because this is the working group for reserved names, and so -- >>ALISTAIR DIXON: Can I just help here? >>CHUCK GOMES: Yes, Alistair. Please do. >>ALISTAIR DIXON: My understanding was that it's not the applicant -- if an applicant is applying for a string that's a geographic name and that string relates to a country that has signed up under the WIPO convention, then they would have to -- basically, their application would have to comply with the convention. And equally, the applicant would have to ensure that they comply with relevant law. So it wouldn't be possible, for example, for somebody from the United States to go and seek, say, dot China unless they have the agreement of the government of China. That was my understanding of what was being proposed. >>CHUCK GOMES: And Alistair, just some clarification there. And Avri, feel free to jump in here. I know you're just coming in, but we're trying to clarify the recommendations on the geographic and geopolitical names. So if the U.S. is a country that supported the WIPO standing committee guidelines, and China is as well, then are you saying that it's your understanding that a registry operator from the U.S. would not submit a name dot China? Is that what you're saying? >>ALISTAIR DIXON: Well, they would have to submit -- they would have to comply with the requirements of the WIPO guidelines. >>CHUCK GOMES: Right. Okay. >>ALISTAIR DIXON: So if the WIPO guidelines allows them to submit a name dot China, then it would be fine. But if they didn't allow a non-Chinese entity to submit a dot China name, yeah, then they would be outside the guidelines. I mean -- >>CHUCK GOMES: Right. >>ALISTAIR DIXON: -- that was my understanding of what was proposed. >>BRUCE TONKIN: Yeah. I think -- because fundamentally, Alistair, I'm trying to identify, we have a process for dealing with applications, and there's the -- you know, they need to meet a set of string criteria, and then there's objections to that. So that's a process we have. And part of our process is, we have this reserved name list, and at the moment, at the second level, in some registry agreements there is some text relating to the second level. And can someone sort of just explain that a little bit? Maybe I've jumped to it, but currently a registry operator for a lot of the new TLDs is restricted at the second level, isn't it? Or it needs to get some approval from governments or something? What's the -- >>CHUCK GOMES: Right. Well, there are, what, a half a dozen or so agreements that have requirements for geographical identifiers or reserved names. >>BRUCE TONKIN: So let's just go to one of those. It might sort of help a bit. I'm sort of struggling to sort of translate what your recommendation is. >>ALISTAIR DIXON: Let's get through the difficulty of calling a name a reserved name, Bruce, because it's a reservation but it's not necessarily -- in not all cases with reserved names is the reservation absolute. >>BRUCE TONKIN: Right. >>ALISTAIR DIXON: Only in some cases, in terms of the recommendations, is the reservation absolute. There was some terminology -- and it's escaped me at the moment -- that people have come up with for dealing with names where the reservation might have restrictions but it would not be absolute, and in fact, an applicant could actually use the name, provided that they met the requirements of the policy. So it's not an absolute reservation like, for example, a single number at the top level or, for that matter, say a symbol at the top level. >>BRUCE TONKIN: Yeah. So if we look -- I'm just looking -- I've just displayed the text that's at the second level, just as a starting point. So it basically says that -- this is out of the dot mobi agreement. It says, "All geographic and geopolitical names contained in the ISO 3166-1 list shall initially be reserved," and then it says, "The registry operators shall reserve names of territories, distinct economies, and other geographic and geopolitical names as ICANN may direct from time to time." So that's effectively saying that ICANN creates this list and it's maintained -- >>CHUCK GOMES: Yeah. Let me interrupt just a second. If everyone wants to refer to Page 142 in the document, you'll see there a summary of the requirements, including what Bruce is reading right now, that are in registry agreements. Okay? And he's referring to the dot mobi one. >>BRUCE TONKIN: Yeah. And then it's saying that, "Upon determination by ICANN of appropriate standards for registration, following input from interested parties, such names may be approved for registration." So the way I would read that is, basically it's saying that as part of the string check process, we're going to say, is it a geographic or geopolitical name, yes or no, and it might be on a list that ICANN maintains, which would be effectively a reserved list of -- maybe it's a, you know, separate list. So in your flow, you'd be saying, is it a geographic or geopolitical name? And then you're saying, if so, then use this process. >>CHUCK GOMES: Yeah. And we're not talking about this process that's in the existing agreements. >>BRUCE TONKIN: No. But I'm just -- sorry. You're correct. >>CHUCK GOMES: Right, right. >>BRUCE TONKIN: So if I could just kind of map it, I think there's a flip chart down there. I think ultimately we've got to have something that's practical. >>CHUCK GOMES: Right. >>BRUCE TONKIN: So if we just think about the process we're using for string checks, we're basically saying that we have applications come in, those applications are posted, and then we go through a series of string checks, and some of the string checks, we're saying that if there are technical issues, is there sort of a moral issue, is there [inaudible] of rights [inaudible] >>CHUCK GOMES: Controversial and -- >>BRUCE TONKIN: [inaudible] moral [inaudible] [Phone beeps] >>BRUCE TONKIN: Just those things. If we say -- depending upon which ones of these, they go into different types of dispute processes effectively. >>CHUCK GOMES: Uh-huh. >>BRUCE TONKIN: So if you look at the way geopolitical names are handled at the second level, if you like, essentially what we're waying is, is it geopolitical, which really -- sorry. Is it on a reserved list? What it might be that we're trying to design here is maybe getting political names out on a reserved list, but then this thing [inaudible]. So you might say I have a reserved list and it has these categories as -- so that's [inaudible] categories like dot example, let's say, [inaudible] ICANN, IANA and we say, no, you can't have any of those names. And then we have another category, which is geopolitical, and we have some sort of list, preferably some ISO list that we can use, so that it basically says if it's on that list, then it's on the reserved list. And then we're saying if it's on that list, then there's a process for deciding whether to release it. And that, to me, is -- >>CHUCK GOMES: I'm not following you there. Go ahead. >>AVRI DORIA: That's specifically what the group decided not to recommend. >>CHUCK GOMES: Right. >>BRUCE TONKIN: Right. >>AVRI DORIA: And as it decided specifically not to recommend creating of such a list, it was basically saying this is something that is governed by national agreement and national law, signatories to, you know, the WIPO agreement, et cetera. This was not controlled by a list because different countries, different agreements, different whatevers might have different lists. So it's basically saying the rule is an implicit rule, not a explicit rule. You have an implicit list by virtue of what agreements you've made and what national laws you have. >>BRUCE TONKIN: So then, Avri, that is not in the reserved list so we take it off that category, but now we're talking about a new category here and we're saying one of the string checks is political and that's one of the grounds for objection, so then that becomes the objection process. >>AVRI DORIA: Exactly, yes. >>BRUCE TONKIN: Yes. So have I captured that correctly? >>AVRI DORIA: Yeah. >>BRUCE TONKIN: Yeah. So that then has implications for the new gTLD policy because unlike some of the other categories that you talked about early on yesterday -- >>CHUCK GOMES: Yeah. >>BRUCE TONKIN: -- we're actually saying we need a new type of string check, and this string check, basically -- it's a complaints process, effectively, and so a person would complain and they'd say, "because this string is protected under this law," and then we have a dispute process we'll have that's dealt with. And the reason why I'm saying "a dispute process," there are two ways you can do it. You could have -- I'm just trying to get the concept [inaudible], okay? >>AVRI DORIA: Yeah. >>BRUCE TONKIN: There are two options in the process. You have a check, a dispute resolution, which is called -- let's call it "fast," and then it goes in the root, and then after that, it could be pulled from the root. Okay? And this could happen at any time because there's laws in various countries that can do this at any time. And so what I'm trying to say is, rather than end up with a situation where we have a bunch of stuff that's in here that runs for some period of months and gets pulled out, what we're saying is, let's try and deal with most of these fairly efficiently in this ICANN approval process. And, you know, using courts of law is not a way of doing an application process. So we need to sort of identify what are the main categories, and then we have some sort of dispute mechanism, but fairly clearly defined. >>AVRI DORIA: Right. Which we called the slow path, when we were talking about it in the -- >>BRUCE TONKIN: Yeah. It's the slow path, that's right. But it's not years. It's a slow path, but it's not years. >>AVRI DORIA: Right. Yeah. The slow path is faster than that, right. >>BRUCE TONKIN: Yeah, yeah. And also, names that we haven't -- by the time it gets here, it's got a pretty good chance of [inaudible] if you like. >>AVRI DORIA: Yeah. >>BRUCE TONKIN: So I think what we're -- if I interpret the recommendation, it is that we're saying one of the checks or one of the areas of objection can be geographic. The basis for that objection is, you know, the text that Chuck was saying: It's part of this treaty or whatever it is. And therefore, we could have a dispute provider of some sort that basically says, you know, does this meet the treaty requirement or not, basically. Yeah, Jon. >>JON BING: Excuse me. Just for clarification, but does these geographical names also contain the lists which has been agreed under the WIPO convention as regional origins? Because they are, as you know, rather similar to trademarks, only they do not apply to a certain product but to their geographical origins of a product like Champagne or like [inaudible] and so on, and if they are not respected by countries which are not bound by them, you may have some sort of immigration of domains to -- >>BRUCE TONKIN: Exactly. So what I think we're saying here, if I get this correctly, let's identify specifically what the treaties are, rather than a WIPO committee; that we actually need to refer to the treaties. And what we're saying is because I'd like to see that these treaties are signed by more than just, you know, two countries or something -- because obviously you could have a bilateral agreement, but if this is a treaty that's pretty widespread, you know, has a lot of signatories in a broad range of countries, then I think what we're saying, just like we're doing with UDRP, we're saying that the applicant will be bound by a dispute process that's based on that. So we're -- let's say we have a dispute process -- So the applicant could live in the Cocos Islands or something and he's not a signatory, but what we're saying is ICANN is going to recognize the fact that that's an international treaty and is going to have a dispute process. And one of these areas that are -- just the way we sort of do it with trademarks, effectively, because not all countries are signatories to the trademark law either. >>JON BING: It will be interesting, will it not. For instance, one of the -- one of the issues now is "vodka," whether that should be reserved, and we might easily see that this process has become part of the sort of trade policies. >>BRUCE TONKIN: Yeah. And also, when you look at those trade things, I think, you know, this is where we've got to be careful with the law. And I agree, I think we need to identify specifically what the law -- >> [inaudible] joins. >>BRUCE TONKIN: -- but it might well be that you could have "champagne," if it wasn't referring to a drink, for example. Because "champagne" in some areas is a color. And, you know, you can see clothing that's, you know, [inaudible] but it's used as a color and maybe you have dot champagne [inaudible] interested in the color and nothing at all to do with the drink. It probably isn't in violation of, you know, that trademark, or whatever it's called. So I think you'd have to look at that as part of that dispute process that, you know, that's the sorts of elements that would be looked at. >>AVRI DORIA: I mean on the dispute resolution, I mean in the thing, that's one of the places where we said the work was yet to be done, indeed, of how that was done. I don't know that we made the jump that you made in the recommendations that everyone, even if not signatory, would be governed by the same rules as those that signed it, but -- >>BRUCE TONKIN: Yeah. Well, if you don't do that, so what? >>AVRI DORIA: Yes. Then if you don't do that, then you create havens. I understand. >>BRUCE TONKIN: I just want to be very clear what we're trying to do here. We're trying to design this. We're not dealing with that. That exists anyway. >>CHUCK GOMES: Right. >>BRUCE TONKIN: And that's where, obviously, if there's a law in Iraq or something that says you can't have something, then, you know, the law of -- the government of Iraq will do whatever it does, right? But we're trying to say, here's a process that's streamlined, applies to all applicants. They agree to it up front as part of their application, and whatever is in here should be a reasonable common denominator. In other words, it's something that is broadly supported internationally, picking up the sorts of concepts we're saying, yeah, international legal norms, you know, widely recognized international law. So all I'm saying in this area of the geopolitical, let's actually identify whether that is in that category. Is it widely recognized international law? Let's get the specific treaty. Let's see how many countries are signatories to it. Let's get a sense of that before we decide to put it in here versus down there. >>AVRI DORIA: No, that seems like a good idea for where the additional work needs to be done on this, yeah. >>BRUCE TONKIN: Yeah. >>PHILIP SHEPPARD: Bruce, just for clarification -- and we could probably do with some better expertise than I'm about to offer, but my understanding is that the 2002 WIPO general assembly -- so still talking only at the agency level, in United Nations terms -- passed a resolution which was resisted by certain countries related to country names, and they wanted reservation of country names. The decision there was specifically not to go for treaty, because they realized there was no support for a treaty and, indeed, the time scale for that was inappropriate. And the action that WIPO has since taken -- the WIPO secretariat has since taken has been overtures to ICANN to say, "Can you help us implement this?" >>BRUCE TONKIN: Yeah. And that's where I think we're -- >>PHILIP SHEPPARD: So, we're at the moment in danger of having a rather circular argument here. We're assuming something has happened that hasn't. >>BRUCE TONKIN: Yes. >>PHILIP SHEPPARD: And on geographical indicators -- the champagnes, et cetera, of this world -- the decision of that WIPO assembly, if I recall correctly -- and I just had a quick look at the text of it -- was to say to the lower trademark committee, "Have a look at that again and get back to us," and I don't think that "getting back to us" has yet happened. >>BRUCE TONKIN: Yeah. So -- >>PHILIP SHEPPARD: So that's where the status is, I believe. I may stand corrected, but that's where it is. >>BRUCE TONKIN: I think that's very important, the way you articulated that, and I don't think ICANN is the place to replace doing treaties. That's sort of saying "Because it's too hard ever here, we just want you to go and do it here in ICANN," and that's trying to make us an international legislator or an international law body. I think that's dangerous. I think if we stick to our principles there, and say, "You know, we will obey applicable international law" -- but to actually sort of say, "Oh, because it was hard to create this international law, ICANN why don't you just say yes," then that's -- where is that in our mandate? You know, that's not part of ICANN's mission, to be doing that. We're a technical coordinator. We abide by the laws of the land or the laws of the world. So I don't think we should be used as a repository, unless it's a technical issue, which is in our area. So I think, you know, whether we want to ban dot exe or something, I think that's entirely within ICANN's scope, if that's what the technical community thinks is important. But if we then sort of are saying, "Hey, we want to ban a word" or "We want to change a word" that's not supported by law, then where does that fit with our mission? You know, I think that's mission creep, essentially. But we just have to be careful what we're actually -- >>CHUCK GOMES: Yeah. Mike Palage has joined us and, Mike, you may want to jump in here. We're obviously talking about geographic and geopolitical names. And so, Mike, it might be helpful if you walked us through how the recommendation would work if an application came in with a geographic or geopolitical name. First of all, how would you identify whether it's geographic or geopolitical? And then secondly, what would happen in the application process with regard to this particular category? And the group has seen the recommendation for the top level. >>MICHAEL PALAGE: Okay. With regard to the top level -- There was, if you will, a lot of consensus at the second level. Regarding the top level, within the group we said -- if you will, we referenced it to the GAC members. That was the consensus statement that we had agreed upon. >>CHUCK GOMES: And explain what you mean by "referenced to the GAC members." >>MICHAEL PALAGE: Well, I'll sort of -- I'll let the words speak for themselves. >>CHUCK GOMES: We already went through the words, but -- >>BRUCE TONKIN: So essentially what we're saying, Mike, though, is, we're trying to design a process here. >>MICHAEL PALAGE: Uh-huh. >>BRUCE TONKIN: So we're saying it's part of a dispute process. We could create a category of geographic names as being an area where we could have a dispute, but it should be granted in international law. And so our question is: What is the international law in this area? Is there a treaty? Is there something that we can reference that -- where, like with trademark law, I can say "Here's the law, here's the treaty, you know, that applies in each country." >>MICHAEL PALAGE: Yeah. >>BRUCE TONKIN: If I didn't have ICANN there, I could actually go to a law, a court of law, and get a decision on a trademark. So my question is: What is the law in the geographic area that exists today that's protecting the geographic names? >>MICHAEL PALAGE: As Philip was articulating, the WIPO general assembly there was, I believe, 174 member states that agreed with the recommendations regarding the protection of country names. The four countries which did not adopt that were the United States, Canada, Australia, and a reservation by Japan. So one of the things -- >>BRUCE TONKIN: So then, Mike, is it then in the laws of those countries now? >>MICHAEL PALAGE: There are -- yes. If you read the WIPO II report, there are certain countries which do provide for the protection of geographical identifiers in national law. >>BRUCE TONKIN: In national law. >>MICHAEL PALAGE: In national law. >>BRUCE TONKIN: So that's what I think we need to try and identify, is what are those national laws that exist today. >>MICHAEL PALAGE: And if you look at our recommendation, one of the things that we tried to always do is look at the national law. And the key indicator that we tried to do was where the applicant was potentially incorporated under those national laws or -- >>BRUCE TONKIN: And one of the things I want to be clear on the national law, so within Australia, it may have some restrictions on the use of the word "Australia" within Australia, but do these national laws actually protect the names of other countries? In other words, if I was in Australia, is there an Australian law saying I can't use "United States"? Because I'm pretty sure there's not, but -- that's what I kind of wanted -- when you're clarifying by saying there's national laws -- there might be national laws protecting their own country name, the question is: Does it protect other country names in their country? >>MICHAEL PALAGE: Jon Bing had a question. >>BRUCE TONKIN: Jon? >>JON BING: Well, I certainly wouldn't know the nature of national laws around the world, but it is typical that national law will protect the state name of other states, as well with some -- >>BRUCE TONKIN: Of their own states, yeah. >>JON BING: Yeah. Some of the things like the call to arms and the other things. >>BRUCE TONKIN: Yeah, exactly. So the question we're trying to do here, Jon, is identify -- the concept here, I think, is basically saying that somehow a country name or geographic name is protected outside of that region, and I'm trying to say what -- what laws exist today that do that. Because obviously, a law will typically protect its own name within that region, so names of governments, names of states, whatever. But it's when you start to say, "I'm going to protect the law -- these names in these other parts of the world" is where there's a big jump. >>JON BING: And regrettably, it is not a unique name. There's a well-known fridge in the United States called Norge and Norge is a Norwegian form of our own country. >>BRUCE TONKIN: Yeah. Well, I believe there's a town called Nike as well. >>JON BING: Yeah. And there would be a rather larger number of towns, if you go down to that level. >>BRUCE TONKIN: Exactly, yeah. So clearly it's not protected in -- >>JON BING: But my point was that even if you're protecting the name of the country, that country may have several versions of the names. >>BRUCE TONKIN: Yeah. >>JON BING: Some of them which are not recognized, and some of them actually being part of a political struggle in what type of country it should be. >>BRUCE TONKIN: Yeah. So I think basically the extra work here, it sounds like it's not ready to be brought up to a new gTLD committee recommendation, because I think we need to identify the underlying laws here, because the default position basically, there's some legal processes that can occur after the fact, but what we're trying to do is to say does it need to be elevated into our dispute process as a streamlined way of -- of dealing with the issue, and then what I'm saying is the criteria for that is, can we identify some national laws or laws in multiple countries that are -- that are fairly similar that meet this concept or not. >>MICHAEL PALAGE: Bruce, one of the problems, though, that you will run into -- and before getting to that point, Paragraph 261 of the WIPO 2 report actually lists those laws of ccTLD operators that haven't acknowledged the protection of geographical identifiers. To my knowledge, though, I know of no country that provides protection for another geographical identifier. >>BRUCE TONKIN: Right. >>MICHAEL PALAGE: The only caveat to that, however, would be, for example, certain regions. For example, Champagne, stuff like that. Geographical identifiers. So there are -- >>BRUCE TONKIN: Yeah. And I think -- and that's what my guess would be, too. So in that case, that's why I'm treating that the same as saying, well, there's a particular word that means something in that country that's probably just going to be dealt with under the laws of that country, rather than an ICANN process. >>MICHAEL PALAGE: Correct. Now, the one potential shortcoming in our recommendation here where we tried to focus on looking at national law as being the guiding principle, a potential way of gaming the system with the guidelines that we have set forth here would be potentially someone who would want the name of South Africa, dot South Africa as a top-level domain, who would seek to incorporate in the U.S. -- >>BRUCE TONKIN: Yes, exactly. >>MICHAEL PALAGE: -- where that protection -- where they would not be barred from doing that. >>BRUCE TONKIN: So I think the way I'd deal with it under our current process -- and maybe we need to -- As I understand it, in our current recommendations, this would be covered under the one that came in since Marina del Rey, which is basically saying that if it's an established institution that relates to that name -- and a country would be an established institution -- then they would have standing to object to an applicant. So using your South Africa scenario, the way I'd work it through our current process is basically to say, someone applies for South Africa and they live in the United States. The South African government says, "Hey, we are the South African government and we are an established institution that relates to this name South Africa. We don't believe this person in the U.S. is representative of South Africa. Here's our evidence. Basically, we are the government." And that would be enough for that applicant then to be knocked out as part of that applicant criteria. So that's how I'd deal with that currently. >>AVRI DORIA: Bruce? And that's exactly the reason for, you asked before, the notification to the GAC of there being such a name in progress, to make sure that South Africa is aware that this is happening at that time. >>BRUCE TONKIN: Yeah. And so I -- I just want to be clear that our mechanism in the new gTLD currently is that that's dealt with as being an established institution that's related to that. So in other words, if the Cocos Islands say, "I don't like the fact that this guy in the United States wants South Africa," that wouldn't be enough. It would have to be the South African government who's actually complaining about that. Yeah, John. >> Thanks, Bruce. I mean I headed up, as you know, the WIPO II committee, and it was absolutely impossible to reach any kind of consensus, notwithstanding the involvement of half a dozen countries from the GAC, for the simple reason that trademark law, as some of you may know, would not only permit, but now you will find registration of country names as trademarks around the world. You'll find the names of various countries registered in -- the same mark registered in 50 countries right now. So it becomes very, very difficult to understand how you're now going to prevent that mark as a domain name simply because it contains a country name -- >>BRUCE TONKIN: Yeah. >> -- traveling around the world. So all I can tell you is after a year of working with people from every constituency in a whole cross-section of countries, we could reach zero consensus, and I think you're going down the same path. >>BRUCE TONKIN: Thanks, John. Okay. I think let's move on to the next area: Three character reserved names. >>CHUCK GOMES: All right. The three character reserved names -- now, you didn't want to go over the second level for geographic? >>BRUCE TONKIN: I think the principles are pretty -- >>CHUCK GOMES: Yeah, it's pretty similar, except for the GAC step there, so... >>BRUCE TONKIN: So, well, actually maybe I'll just try and clarify it. So is this -- are you recommending a change to the status quo at the second level? >>CHUCK GOMES: Well, there is no status quo for this category -- >>BRUCE TONKIN: Right. >>CHUCK GOMES: -- because there are some agreements that have a requirement for geographic reserved names and many that don't. >>BRUCE TONKIN: Right. Okay. >>CHUCK GOMES: Okay? So I don't think we can talk about status quo here. >>BRUCE TONKIN: That's fair. Yeah. >>CHUCK GOMES: So in the case of agreements that do have a geographic reserved name requirement, we are recommending a change. >>BRUCE TONKIN: And what's that? >>CHUCK GOMES: To the process we just talked about. You'll see the same language, with the exception of that first step. >>BRUCE TONKIN: Okay. But at the second level, it's a little different, so the process we're talking about is a process that happens before the name goes into the -- >>CHUCK GOMES: Uh-huh. >>BRUCE TONKIN: -- zone. For the second level, are you proposing -- just explain how that would work. Is there some way that that happens before it goes into the zone or -- >>CHUCK GOMES: Go ahead, Mike. >>BRUCE TONKIN: -- or is it an after-the-fact decision? >>CHUCK GOMES: Yeah. Let Mike jump in there. >>MICHAEL PALAGE: Yeah. Thanks, Chuck. What we're looking at here is, this recommendation would not only apply to new TLDs, but existing TLDs. This is the recommendation. >>BRUCE TONKIN: Yes. >>MICHAEL PALAGE: And what we are proposing to do here is to respect the sovereign laws and rights of those 174 member states that had, in fact, supported the recommendation of the WIPO general assembly. So what we were looking for would be WIPO would have to go back and come up with a dispute mechanism, based upon the principles set forth by the general assembly. >>BRUCE TONKIN: Yeah. But I think that's where you're going -- I think we'll have exactly the same comments as where I went before. I think we could use the same method we were talking about by the established institution thing, and we could have a -- I guess a dispute process around that. But if we're going to go down your path, I think basically it's got to be based on what's the underlying law there. >>MICHAEL PALAGE: Well, that's exactly it, Bruce. What we're looking at here is those companies -- so for example, if you look at the current gTLD registries that would potentially be bound by this recommendation, you'd be looking at Afilias.info located in Ireland, Mobi located in -- >>BRUCE TONKIN: But -- hang on. Tell me how -- I still don't understand this "bound" bit, because unless it's in the law of Ireland that it's part of the treaty, which I think you just basically said it's not, I think you basically said that it's -- the law of Ireland would only protect the word "Ireland." And so I don't see how -- if I'm in -- so Afilias is in Ireland, right? >>MICHAEL PALAGE: Correct. >>BRUCE TONKIN: And I apply for South Africa.info, how would the law of Ireland bind Aflias? >>MICHAEL PALAGE: Because what we're looking at is we're looking at the work that WIPO had done over the years and the recommendations that were adopted by the general assembly of WIPO did not make that distinction. They sat there and said that country names shall be protected. >>BRUCE TONKIN: Yeah, but that's WIPO. I'm saying what does the government -- what's the law say? What's the underlying law in Ireland? >>MICHAEL PALAGE: Uh-huh. >>BRUCE TONKIN: Because ultimately, that's what you're referring back to. You know, if it's a trademark dispute, there is a trademark law in Ireland, and that's what you're referring to. >>MICHAEL PALAGE: Okay. >>BRUCE TONKIN: Yeah. I think we just have to be careful how we word this, you know. Philip? >>PHILIP SHEPPARD: Bruce, if I can try again. We're, at the moment, talking about the creation of a -- ultimately, a creation of a reservation list, huh? To my mind, this is out of scope, is the simple answer, in relation to this particular work at the moment. Huh? >>BRUCE TONKIN: Yes. >>PHILIP SHEPPARD: What we've said, in terms of the top level, is that we believe one of our existing processes in the TLD process, as you said, a body with standing can object to a process. >>BRUCE TONKIN: Yes. >>PHILIP SHEPPARD: So essentially we're giving countries a veto, if anybody comes up with their name in a TLD, huh? >>BRUCE TONKIN: On the basis they're an established institution related to that name, yeah. >>PHILIP SHEPPARD: Yeah. At the second level and the third level, to my mind, we're back precisely where we have been for the last six years, with WIPO having made a request to ICANN and no action having been taken yet. >>BRUCE TONKIN: That's right. So the same with the pharmaceutical names and with other things, yeah. >>PHILIP SHEPPARD: Right. And WIPO, I think, are expecting at some point ICANN's policy body -- which sounds like us -- to be addressing that, in one way or the other. >>BRUCE TONKIN: Yeah. I think that's probably a good summary, yeah. >>MICHAEL PALAGE: But just to go back, the WIPO II, the guidelines adopted by the general assembly, was not a veto. And that's an important distinction. Because the GAC draft principles basically called for -- at least at the second level, they said they wanted the name blocked or they wanted a block, for fear of the right to register. That is different than what the general assembly said, and particularly, Point 2 said the protection should be operative against the registration or use of any name which is identical or misleadingly similar to the country name where the domain name holder has no right or legitimate interest in the domain name and is of the nature to likely mislead users into believing that there is some association between the domain name holder and the constitutional authorities of that country. Now, I agree that the potential application of that may result in a high probability where, if the South African government was to object, they would succeed, but those words do not say they get an automatic veto, and I think that's very important. And one of the things that we tried to, if you will, hone in on, in our work, is to focus the GAC on what the work of the general assembly had done over the many years that they've particularly looked at this topic. So that's what we were driving at. >>BRUCE TONKIN: Okay. Thanks, Mike. Let's try and move -- I want to get to the -- just hold on a second. >>CHUCK GOMES: Yeah. Okay. The -- >>BRUCE TONKIN: There was another controversial one or something, was there? >>CHUCK GOMES: Yeah. >>BRUCE TONKIN: I just want to sort of -- can you sort of move through the ones that are -- move through these ones rather quickly? >>CHUCK GOMES: Yeah. The three-character reserved names at the third level, we didn't recommend any changes in terms of the way those are handled. That's unique to one particular registry, right now, and we just tried to be inclusive of everything that came under this category. This one is so unique that we thought that the way it's handled on a contractual basis was fine. >>BRUCE TONKIN: Okay. Let's keep moving. This one? gTLD names? >>CHUCK GOMES: gTLD names. We didn't come to agreement on this one. In fact, when surveying multiple gTLD registries, we got quite a mixed view on whether this requirement is important or not. It becomes harder to manage as you go forward. And what it is, this is -- this has nothing to do with the top level. This is second level or third, if applicable, and it's basically requiring that gTLD registries can't register names for other TLDs at the second level. So biz can't do dot info -- info.biz, for example. Okay? There's not agreement, even among registries, whether this requirement is important or not. >>BRUCE TONKIN: Okay. Keep moving through, because you're not really making any recommendation on some of these, are you? >>CHUCK GOMES: Okay. >>BRUCE TONKIN: Okay. Now, this one? >>CHUCK GOMES: Okay. Now, controversial names is -- first of all, the -- and you notice we presented this very differently, in terms of the presentation. First of all, a definition is provided for what a controversial name is, and you can see the bullets here. First of all, the name has to qualify as a TLD under existing string criteria. Nothing big there. And it can't fall under another reserved name category. Third, it's disputed for reasons other than it falls under any other reserved name category and it infringes on the prior legal rights of others. So it's not going to -- we're not calling controversial names names that fall under those other -- those two categories. Go ahead and move forward. Now, so the recommendation -- and this is going to go over several slides because there's four parts to it. And this is for top-level ASCII, okay? And the proposal is to create a category called "controversial names" used for the top level only, and you'll see how that fits in with a totally different approach for the second level. A label that is applied for would be considered controversial if, during the public comment phase of the new gTLD application process, the label becomes disputed by a formal notice of a consensus position from an ICANN advisory committee or ICANN supporting organization and otherwise meets the definition of "controversial names" as defined above. >>BRUCE TONKIN: So what were some examples? >> Right. >>CHUCK GOMES: I'm sorry. What was that? >>BRUCE TONKIN: What's an example of a controversial name? >>CHUCK GOMES: Go ahead, Marilyn. Jump in. >>MARILYN CADE: So a controversial name, Bruce, might be the name of a country that has a law that prohibits the registration -- the use of its name except by express permission of the government. It might be -- >>BRUCE TONKIN: Right. But we covered that under the geopolitical, so give me another one. >>MARILYN CADE: But it could be also be, I guess, one of the -- you referenced yesterday perhaps the concept of a nasty word. It could -- >>BRUCE TONKIN: Right. But aren't we covering that under the other new gTLD process, under the sort of that there's laws and moral public order and we have some sort of dispute process for that? I'm not quite sure why this is in that reserved names category. >>MARILYN CADE: In proposing -- and I was one of the folks who worked on this. I see that Tim is not here. Right? So in proposing this, I think we were looking at this as a process by which you might take a name out of the active process and figure out a way to deal with the dispute and potentially put a name back in. So I'm -- I don't mean to pick on geocities as an example, but let's say that geotownships, for instance, is a category. >>BRUCE TONKIN: But that's a totally separate hot topic. We've talked about geo, so give me a -- I don't know -- bomb. Dot bomb. We're going to blow something up. >>MARILYN CADE: Okay. Or dot Mohammed. >>BRUCE TONKIN: Yeah. Okay. That's another one. >>MARILYN CADE: Or dot Nazi. >>BRUCE TONKIN: So those ones -- we're not trying to create a magic list of those words. >>MARILYN CADE: No. >>BRUCE TONKIN: So what we are doing, then, in our new gTLD process is we're saying that there is this category which is -- you know, whether it's public order or morality, so if you're creating a domain space entirely for, you know, Web sites for how to build bombs and blow things up, as generally would fit into that public order category, and then what we'd say is as an outcome of that process -- I think what we talked about in the new gTLD discussions on these things is, when something gets disputed like that, at that point the name gets reserved. So that it's not just a mechanism of saying, "Hey, I actually really want this name so I'm going to dispute this guy and then I'm going to apply for it in the next round myself." So that was kind of the context where we were talking about that. So if it was sufficient to be able to prove that it was in this category that one person couldn't have it, then effectively we're saying, well, no one else can have it either, unless there was some other -- as Avri gave the other example yesterday, that maybe someone is using that TLD solely for the purpose of, I don't know, something good about it -- how to dismantle bombs -- and that would then presumably be a contractual condition on being able to have that. >>MARILYN CADE: So you might take the phrase "cluster bombs" as an example of something that is very controversial. >>BRUCE TONKIN: Yeah. >>MARILYN CADE: There's a U.N. commission. If you were to register to put up a Web site on how to deal with cluster bombs, that might be a good use, but it might be highly disputed initially when you applied for the name. >>BRUCE TONKIN: Okay. So just sort of conscious that we keep the actual reserved names work fairly focused on things that, up front, you're telling the applicant "This is a name that you shouldn't have," and then there's other parts of our process to deal with objections or disputes and it could be, I guess, as part of our recommendations that names that are disputed and those disputes are successful, that they get added to a list. Maybe it's just the disputed names list or something. And names could be removed from that disputed names list via an appropriate process. But the default would be, as a new applicant, you check to see are my names on a disputed names list. That's probably not a good idea to apply for that. >>MARILYN CADE: Right. And actually, Bruce, in the discussion that the subgroup had, we toyed with changing the name to "disputed/controversial" because that was the very concept that we were thinking about. >>BRUCE TONKIN: Yeah, yeah. That might be a better way of using -- I'm just -- what I'm trying to do, the reason why I'm pushing on these things is I'm just trying to align it with we've done in the new gTLD work -- >>MARILYN CADE: Right, exactly. >>BRUCE TONKIN: -- and see how we can incorporate the ideas. Okay. Anything else, Chuck? >>CHUCK GOMES: Yeah. There are other steps there. Do you want to go through those, or do you want to -- >>BRUCE TONKIN: Probably not for now. I think -- >>CHUCK GOMES: Okay. >>BRUCE TONKIN: Yeah. I was just trying to get the concept. >>CHUCK GOMES: Now, let me get -- make sure I have the sense, Bruce, of what you're suggesting here. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: Is the sense that I'm getting that controversial names should be handled through the new gTLD process, rather than through the reserved name process? >>BRUCE TONKIN: Yes. In other words, unless you're going to create a list, which I'm assuming you're not -- >>CHUCK GOMES: Okay. Yeah. That's correct. >>BRUCE TONKIN: -- what we're saying is that the new gTLD process effectively creates a list on the fly, because as names are disputed and kicked out, that they then get added to this list of -- >>CHUCK GOMES: Yeah. >>BRUCE TONKIN: -- here's a list of ones that were rejected, if you like. >>CHUCK GOMES: No, no. I understand that. I just want to be very clear on that. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: And I don't have any problem with that. What we tried to do as a working group is work on every possible type of -- >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: -- reserved name that could exist, if you went that direction. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: And so that's why we covered this area here, because we knew that it was one that had been brought up. >>BRUCE TONKIN: Right. Yeah. No, I'm not criticizing the work. I'm just trying to -- >>CHUCK GOMES: Yeah. So this is really one, then, that the reserved name working group probably wouldn't need to pursue further. >>BRUCE TONKIN: Yeah, I think that's right. >>CHUCK GOMES: Yeah. Actually -- >>BRUCE TONKIN: Other than just in our guidelines in our new gTLD report, just indicating that as part of the guidelines when a dispute happens and a name is kicked out for that reason, it goes on a disputed names list and, you know, we -- >>CHUCK GOMES: And that kind of backs up to another question in the previous category. You don't need to roll back there. The other reserved names at the second level was one that was unique to particular registries, and I would -- and I'm trying to get your guidance in this regard. It's one that I think -- it doesn't apply to all registries. It was unique. Certain elements of it were unique to just particular registries in their negotiations. Premium names is an example. Some of the things like that. They really aren't on the reserved names list, and if I extend what you're saying to that, I would think also that that's probably not an issue for reserved names. >>BRUCE TONKIN: I think that's right, yeah. >>CHUCK GOMES: Okay. >>BRUCE TONKIN: Because it's not a global list. I mean, I think obviously a registry for the purposes of that TLD -- I mean, a classic example is dot jobs. There's probably some words you don't want in front of that, and -- starting with "b," potentially -- that, you know, might be something you want to reserve, because you're trying to create this TLD for the purposes of jobs or whatever. So I could see that an individual registry operator, for its own reasons, might want to prevent certain words. But that's not a contractual requirement coming from on high saying, you know, "You must" -- >>CHUCK GOMES: That's good. No, that's helpful direction. >>MARILYN CADE: But -- would you take a -- after Avri, would you put me in the queue to comment on that? >>AVRI DORIA: Okay. Yeah. I just wanted to go back to the one thing you were talking about before, of the disputed names, and I think that's not something that perhaps the RN group should be working on, but I think we have more to do with the whole getting on that list, getting off that list, living with that list. I think it's something that we're sort of hand-waving about, still, and -- >>BRUCE TONKIN: Yeah, I think so, although -- AVRI DORIA: -- and need to put some focus on it. >>BRUCE TONKIN: I think some of that will evolve. I'm not sure that we can get everything done at once, but I understand what you're saying. I think that's an area that needs to be thought through a bit more, yeah. But mostly from a staff implementation point of view, I think. >> May I just ask a question on this, Bruce? And thanks, everyone, for the discussion that has been going on. I've been taking detailed notes about where I think there could be agreement from recommendations from the group. But can I check that the next stage of the process is to include the reserved names working group agreed recommendations in the new TLDs report? >>BRUCE TONKIN: No, it's not. No. >> No. >>BRUCE TONKIN: What we need to do is -- >> Are you sure? >>BRUCE TONKIN: That's a separate, report, right? >>MARILYN CADE: Right. >>BRUCE TONKIN: And we then need to sort of say, "Okay, now that we've received that report, what conclusions do we want to actually -- or changes do we want to make to the new gld work?" And that's a decision made by that new gTLD committee. So the working -- this is effectively the equivalent of an issues report. It's basically saying "Here's a bunch of input and materials." We're now -- what -- and this is a meeting of the new gTLD committee here, and we're saying, "Okay, we've received this report from the working group. We're trying to say, okay, is this something we've already covered, or it fits into our existing process, or is it something we've missed, and we need to incorporate?" So I think a lot of the scenarios that Chuck has given -- especially, you know, going through them yesterday -- we're able to say, "Yeah, that fits into this flow of our existing process, so basically no change. You know, we acknowledge this and no change to the new gTLD report." >> Yeah. Got it. >>BRUCE TONKIN: Because we acknowledge that this is what it is. The only thing I would do in the discussion in the new gTLD report is refer back, and then you can say, "The issue raised by the" -- >> By the group. >>BRUCE TONKIN: -- "by the working group for geopolitical names fits in here in our process," effectively. So that's kind of -- >> Sure. >>BRUCE TONKIN: It's an edit of the content -- >> Yeah. >>BRUCE TONKIN: -- it's not a grab this and just chuck it in. >> Just in that case -- I'm sorry to ask a supplementary question. Chuck, is it your intention to do any further amendments to the report, and -- because I need that to be stable. That report needs to be finished. And so the logical question then to ask is: Is there any more work that's going be done, and then when will the report be final so it becomes an input into this process and then I can use it to determine where things would change and how things would change and if they would change, and then use it as a reference document, just like Bruce has referred to? >>BRUCE TONKIN: I think what we -- that's probably a discussion for the council, but -- >> Okay. >>BRUCE TONKIN: -- essentially what I'd be saying is -- and, you know, let's seek the agreement of the council on Wednesday. But I think it is worth doing one more edit of the document, based on the discussions the last couple of days. >>CHUCK GOMES: Yeah, right. That's exactly what I was going to say, yeah. If we're extended for another 30 days, then there would be some more edits, more input into the report. >> Super. Thanks. >>BRUCE TONKIN: Yeah. Okay. I think we've -- >>CHUCK GOMES: Marilyn wanted -- has been trying to get in here. >>BRUCE TONKIN: Sorry. Go ahead, Marilyn. >>MARILYN CADE: I -- my comment is -- so I support everything you've said so far, but my comment goes back to the discussion about registries, reserving names, and making it very clear that when a registry reserves a name, that is a reserved name; it is not a form of parking a name and releasing it later without notice to the community. So the idea of premium names is a marketing strategy; that's not a reserved name category. >>BRUCE TONKIN: Yeah, right. >>MARILYN CADE: And I think we've all agreed with that. >>BRUCE TONKIN: Yeah. >>MARILYN CADE: But there is an issue where I see that a registry might register 5,000 names. Many of those names are names that are suitable to be released and used, and I -- I'm -- you know, I guess the question I have is: Let's be careful that the reserved name process is not creating a harbor for names that are then later going to be released by the registry without some public process to release them and allocate them. So I think we were -- this idea that there may be names just stored was a topic of discussion among the working group. So making the distinction that when a -- if a registry has a business model that creates a premium name strategy, that's a part of their initial launch, it's public, it's open to public comment, et cetera, et cetera. That's not reserving -- that's not a reserved name category; that's a marketing -- that's a part of their contractual conditions, including getting agreement at the time of launch on how that's going to happen. >>BRUCE TONKIN: Are there contractual conditions currently around first come, first served? Is that something that's -- I suppose it partly comes under the framework of the agreement, but is that -- is there actual rules about allocation in the contracts? >>CHUCK GOMES: That varies by the contract. >>BRUCE TONKIN: By the contract, yeah. >>CHUCK GOMES: And keep in mind we're only talking about a small subset of the gTLDs that have these kind of provisions. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: And it's all, you know, described in the report. >>BRUCE TONKIN: I guess what I'm trying to understand is, I hear there is -- I agree with you -- a distinction, Marilyn. I'm just questioning what role do we have necessarily in that. You know, like if a gTLD has a -- this is part of the diversity, if you like -- but wants to try something different, I'm not sure what the policy implication of that is, I guess. Why would we need to be involved? >>MARILYN CADE: I'm just saying -- I'm focused on: What is the definition of a reserved name and what can one do with a reserved name, and what is the process to -- So, you know, I don't think reserved name ought to become something other than it is a prohibited name -- >>BRUCE TONKIN: Right. >>MARILYN CADE: -- and that's -- >>BRUCE TONKIN: Right. I understand. Okay. If that's the point, I agree with you. I think we -- in terms of our terminology, we're actually effectively creating a framework agreement here, and two things happen. One, we could be reserving names at the top level, so that's obviously an ICANN issue. But in terms of our framework agreement, we may reserve other names, and an example at the second level, the word "example" is an example. [Laughter] >>BRUCE TONKIN: So basically, what we're saying is, it doesn't matter what registry it is, you can't have example dot whatever, and that sets a mandated reserved name. The things you're talking about is different business models. That's not reserved names, I agree with you. That might be their release strategy or whatever. >>MARILYN CADE: Right. >>BRUCE TONKIN: It's not the same thing. >>MARILYN CADE: Right. >>BRUCE TONKIN: Yeah. Okay. >> Marilyn, just on that one, in that case, the reserved word in the contract is an existing definition within the existing contracts, and I will include that. If we -- there's a distinction there between the contractual definitions and what you've actually just described, and I think that needs a bit further discussion in the document. >>BRUCE TONKIN: I think what it needs is -- yeah. That's probably worth putting that description in the reserved names section of the document. From a framework agreement point of view, I guess what we're saying is the framework agreement should clearly perhaps redefine that or improve the definition of "reserved word" or something. >>MARILYN CADE: Yeah. So today, in the Annex 6, Appendix 6, whichever one it is. Appendix 6? >> Appendix 6. >>MARILYN CADE: Okay. In Appendix 6, there are categories of names that are prohibited, and then there are categories of names that are prohibited but can be released if you step through four hoops, so to speak. >>BRUCE TONKIN: So this is -- I'm just putting it up on the screen now. This is the Appendix 6 of mobi, so it's got reserved at all levels, which is the dot example I was talking about, then the things about single-character labels and things. And then at the bottom is that category. So this is an example that hasn't really reserved anything specific here. Which is interesting, actually. So the dot mobi premium names isn't in this appendix, obviously. >>CHUCK GOMES: No. In fact, that was an issue that was discussed in the working group is that, again, we tried to be really comprehensive in our first cut at all of the things, and that's how some of these got in there. There certainly were those in the group that thought that this did not fit in the same category as the others -- >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: -- as has been pointed out here. >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: But again, we tried to cover all bases that we thought might come up, and then we can -- you know, later then we can trim it down to what really fits. >>BRUCE TONKIN: Yeah. So essentially, what we need to do from the gTLD report is have some specific guidelines about what are reserved words and what are the categories we've agreed to so far. And I think, you know, a lot of the work that we talked about yesterday, the -- you know, the dot examples and things like that, we're saying we've got enough, effectively, to create an Appendix 6, I think, based on the report, and we should probably create that, and then people can review that as part of the -- you know, the review. So I think we need to create an Appendix 6, basically. >> Sure. That will also serve two purposes. One, it's an instruction to applicants about what not to apply for, and we've discussed this previously, because that gets us out of some of the string contention issues. You know, don't bother putting this in. In addition to providing guidance for potential new registry operators about what they might be able to do when they're up and running. Because that's where I thought the Appendix 6 actually made sense. That could be a contractual condition. >>BRUCE TONKIN: That's right. That's how I explained it to the GAC yesterday: This is a contractual condition. >> Yes, exactly. >>BRUCE TONKIN: So we are creating that contractual condition at the second level, and we're also separately creating a list, which is not Appendix 6, which is the -- I don't know, the top-level reserved list or something. We can call it what we like. All right. I'm conscious of time, so let's perhaps conclude this discussion and thank Chuck and his working group colleagues for obviously a huge amount of work in a short period of time, so that's great. >> Bruce, one question I would have in regard to that: Has there been any work conducted in regard to how to get a name that is on a reserved list off that list again? I mean, times are changing, so after maybe 50 years, you know, you might want to register that name, and rightly so. >>CHUCK GOMES: Right. No. And just time. Just plain time. It was one of the possible topics that was listed on the statement of work, and we actually have a section in there of issues that we did not have time to get to. And there's also another section that actually we added in there that Tim Denton, the consultant who supported us, added in there that talks about that very issue; that some -- it would be good for some work to be done on that. But the group did not have time to do that. >>BRUCE TONKIN: Yeah. An example of something that has dropped off is DNSO, for example. So in older agreements, that was there; in new agreements, it's not. But, yeah, I don't think there was a process for that, though. That just happened. [Laughter] >>BRUCE TONKIN: And I guess that's your point. [Laughter] >>BRUCE TONKIN: We don't really have a process for managing those things. Okay. Thanks, Chuck. I'd suggest we now enter into a discussion on IDN working groups, so if Ram is available. Do you have a presentation, Ram? >>RAM MOHAN: Yes, I do. >>BRUCE TONKIN: Do you want to run it off my machine or your machine or... >>RAM MOHAN: You should have it in your e-mail. >>BRUCE TONKIN: In my e-mail. >>RAM MOHAN: You should have it in your e-mail as well. >>BRUCE TONKIN: When did you send it, Ram? >> How are you? >>BRUCE TONKIN: "My slides for today's presentation." >>RAM MOHAN: There you go. >>BRUCE TONKIN: Okay. I'm thinking it's probably worth doing a bit of a roll call around the room, since we've filled in a bit more. Do we have a roving mic at all? >>GLEN de SAINT GERY: We should have one. >>BRUCE TONKIN: So if we can perhaps -- we're just starting a new topic, which is the report from the GNSO IDN working group. This is a meeting of the new gTLDs committee, which I'm chair of. Bruce Tonkin. Jon, do you want to just, at the corner there, introduce yourself? Or Norbert? I just want to do it for the purposes of the recording, if people could just state their name. Just work up, Jonathan, next to you. >>NORBERT KLEIN: My name is Norbert Klein. I'm a GNSO Council member and I'm in the noncommercial users constituency. >>BRUCE TONKIN: So we're -- just for everyone in the room's purposes, this is a recorded meeting, and so for the purpose of the recording, we're just stating who is actually present for this meeting. >>WERNER STAUB: My name is Werner Staub. I'm a member of the IDN working group. I work for Core. >>GREG RUTH: Greg Ruth, GNSO Council rep of the ISPCPs. >>JON BING: Jon Bing, NonCom appointee to the GNSO Council. >>AVRI DORIA: Avri Doria, NonCom appointee to the GNSO Council and member of the IDN working group. >>CARY KARP: Cary Karp, registry constituency representative on the GNSO Council and member of both the working group and the whatever-it-is other group. >>STUART DUNCAN: Stuart Duncan, ICM registry, observer. >>TOM KELLER: Tom Keller from the registrar constituency, member of the council. >>MARIA FARRELL: Maria Farrell, ICANN staff. >>KURT PRITZ: Kurt Pritz, ICANN staff. >>GLEN de SAINT GERY: Glen de Saint Gery, GNSO secretariat. >>DAN HALLORAN: Dan Halloran, ICANN staff. >>RAM MOHAN: Ram Mohan, Afilias, and chair of the IDN working group. >>LIZ WILLIAMS: Liz Williams, ICANN senior policy counselor. >>OLOF NORDLING: Olof Nordling, ICANN staff. >>KRISTINA ROSETTE: Kristina Rosette, GNSO Council, IPC. >>MIKE RODENBAUGH: I'm Mike Rodenbaugh, GNSO Council, from the business constituency and member of the IDN working group. >> BAHER ESMAT: Baher Esmat, ICANN staff. >>PHILIP SHEPPARD: Philip Sheppard, GNSO Council, BC. >>CRAIG SCHWARTZ: Craig Schwartz, ICANN staff. >>PATRICK JONES: Patrick Jones, ICANN staff. >>TINA DAM: Tina Dam, ICANN staff. >>DAVID MAHER: David Maher, registry constituency, observer. >>DIRK KRISCHENOWSKI: Dirk Krischenowski, dot Berlin, business constituency, observer. >>JONATHAN COHEN: Jonathan Cohen, IDN working group, IPC. >>BRUCE TONKIN: Thanks, Jonathan. And could we just those around the room just stand up and announce yourself? We're trying to organize a mic, but just speak loudly for the moment. >> [inaudible], ICANN staff. >> [inaudible], VeriSign >>STEVE CROCKER: Steve Crocker, SSAC. >> [inaudible] >> [inaudible] Mexico. >>ROSS RADER: Ross Rader, Council, [inaudible] >> [inaudible] >> [inaudible] >> [inaudible] >> [inaudible] >> [inaudible] Free Speech Coalition. >> JEREMY DOUGLAS: Jeremy Douglas, Free Speech Coalition. >> [inaudible] >> [inaudible] >> [inaudible] >>BRUCE TONKIN: Thank you. Thank you all. Go ahead, Ram. >>RAM MOHAN: Thank you. I'm Ram Mohan, and thank you for giving me the opportunity to share the outcomes of the IDN working group's work with you. I wanted to take just a few minutes to talk about what it is we were chartered to do and how we went about doing it. Our mission was to identify and explore policy issues related to IDNs, internationalized domain names, at the top level, that should be considered by the GNSO for policy development for the creation of a PDP. Now, we had specific tasks. They're on the slides in front of you. But we had four specific documents to review: The new gTLD draft recommendations, the lab test outcomes, the ICANN staff issues report, and the IAB document, which we did. We were also due to research what policy implications might exist for IDN gTLDs, and finally come out with a report. Now, the team itself was quite diverse. We had participation from over 30 members. Liaisons included liaisons from the ALAC and the SSAC, and there were five observers. There were 37 to 40 participants in the working group, and at -- if memory serves me right, the longest -- or the most number of people on a single conference call was almost 20 to 22 people sitting on a single conference call. Our method of working, the methodology was to have some face-to-face meetings. We've held 14 teleconferences, there was a robust e-mail discussion list, and we created a Wiki. There was a draft issue list that got sent out from the first working group meeting that was held in Sao Paulo. I was not at that meeting. And issues were reorganized. There was a list of issues, about 14 or 15 issues that got together, and we reorganized them into seven general issue areas, and what we did was, among -- in our first calls, we prioritized these issues. Not in terms of importance, but in terms of which topics needed more time to be allocated. And the first five bullets that you see on the screen in front of you -- introduction of new IDN gTLDs, geopolitical details, existing strings, existing SLDs, second-level domain name holders, and techno and policy details -- were the major areas of our attention. We did not spend a great time of time on privacy, WHOIS, or other legal aspects. Now, what we did was we -- one of the first things we did was to actually get together and say, "Let's create a working definitions list because we found that the same words were being used in multiple different ways by multiple different people, so we came to agreement on a set of definitions, so when you see -- in this report, when you see the working group outcomes report talk about the word "variants" or you hear us talk about IDN strings, you should refer to the glossary which is in the outcomes report. It is used specifically with that context, rather than any other context that may exist outside of what the working group actually did. Now, we adopted the following conventions to express views. We said that we were going to categorize views that had broad agreement within the working group. There was almost no dissenting view, or if there were, they were very minor dissenting views. We categorized them as agreement, and, in general, we equated them to the concept of rough consensus as used in the IETF. We also -- at a second level, if you will, we categorized another set of views as "support." Now, support views do not represent the views of the entire working group, but they represent the views of a set of individuals in the working group, some of whom spoke for themselves and some of whom spoke on behalf of their constituencies, but we were not able to arrive at broad agreement without any dissent. And alternative views are -- consider them as they could be support if only they had more support. So that's really what an alternative view is, and you will find those represented as well. The focus for today's discussions with you, I'm going to try and spend a little bit more time on the areas of agreement than on the areas of support. We have about 10 areas of agreement, and the plan is the following: Where the IDN working group has come together and said, "We agree," those would be probably the prime areas for the GNSO Council to then consider whether existing policy already covers these areas of agreement or whether new policy has to be created. In the areas of support, we certainly suggest that the council review all the areas of support, not only the ones that are presented here, because of the vast number of statements of support. There are almost 25 or 30 statements there. I've only chosen to bring a few experts here in front of you, but please keep in mind that when you see something that says "support," that means that there is some gathering of positive opinion, but there are competing positions. They either have been stated or they may not be stated, but we certainly were not able to arrive at broad agreement, and therefore, are potentially still areas that require further discussion and thought and certainly no concept of agreement is there for those areas, as yet. So with that said, I'm going to move on to a summarization of the main areas of agreement. The first area that we agreed upon was what we're calling the avoidance of ASCII squatting. What this really means is that where applications for new non-IDN gTLD strings, if they're accepted for insertion in the root at an earlier stage than IDN gTLDs, to ensure that these non-IDN gTLDs do not preempt later applications for IDN gTLDs, then we have an example -- for example, the non-IDN gTLD dot caxap, if accepted, would prohibit the acceptance of a later application for an IDN gTLD also dot caxap which in Cyrillic script means sugar in Russian. So the idea here is that when looking to apply and agree to accept new gTLD strings, to ensure that they don't -- these new strings don't squat, if you will, on equivalent IDN strings. >>BRUCE TONKIN: So one of the things that's going to be our challenge, Ram, is how we incorporate these ideas into our current process. So taking that -- and I like the fact you're using a specific example. So you're saying there is a string -- just run that example by us again. So dot c -- >>RAM MOHAN: Dot caxap. >>BRUCE TONKIN: So if I -- let me just try and bring something up to display then. >>RAM MOHAN: Go to Slide 12 and you'll see it. >>BRUCE TONKIN: Oh, okay. Yeah. I guess it's how you want to go through these. So, are you going to go through each one in more detail or -- >>RAM MOHAN: I'm happy to go through more detail. I figured I'd run through the main agreements and -- 12 is where you want to be. You're on 15. >>BRUCE TONKIN: Oh, Slide 12. >>RAM MOHAN: There you go. That's the first one. >>BRUCE TONKIN: So you're saying dot caxap means sugar in Russian. RAM MOHAN: So what we're saying is that if you have a string like that -- now, clearly there is going to be a public, you know, consultation process when a new TLD comes in. We're not saying take it away from that public consultation process, but what we're saying is that when a new gTLD string is being applied for, to take into consideration that should such a string that is applied for as, quote-unquote, non-IDN, should it have something that -- a direct equivalent, if you will, in IDN then such a non-IDN application, you should try and avoid. >>PHILIP SHEPPARD: Ram, did you discuss how that determination would be made? >>BRUCE TONKIN: Yeah. I can't see how -- >>PHILIP SHEPPARD: Because at the moment, our process would be very happy to have caxap and there would be no connection made to dot (speaking in Russian) which would be the Russian equivalent, huh? >>BRUCE TONKIN: So I think my -- yeah. Go ahead, Olof. >>OLOF NORDLING: Well, first of all, this is in the situation when there is a first round which doesn't include IDN top-level domains. That's sort of the framework for what -- for this statement, really. If they're on a par -- Well, and all IDNs and non-IDN gTLD applications are accepted at the same time, well, this would -- well, there is first come, first served. But, well, if there is first ASCII -- or non-IDN gTLD round, well, at least it could be considered that if objections are raised from the IDN community, if you like, that this particular string would preempt a later IDN string, that would be a valid ground for objection. I think that's the way -- a way to approach it, for the first round. >>BRUCE TONKIN: Yeah. But that's -- but that's like -- if I take IDNs out of that, I'm going to apply for ASCII in Round 2, and someone applies for the name I want in Round 1, and I say that's preempted me, you know. I don't -- I just don't understand the logic. >>CHUCK GOMES: Could I jump in here, because I think -- >>BRUCE TONKIN: Yeah. >>CHUCK GOMES: Again, I think Olof said it very well, in that this particular recommendation only applies if ASCII names are introduced in a round prior to the first IDN round. Correct? >>RAM MOHAN: That's correct. >>CHUCK GOMES: Okay. If they're introduced together, our string contention process will deal with it. >>BRUCE TONKIN: Yes. >>CHUCK GOMES: Okay. If they're not, I think the point's well taken that the ASCII players have an advantage, in cases where there might be a contention over the IDN. Couldn't a fairly simple challenge process be put in, like we're doing in other ways, if this particular situation exists, so that somebody could say, "Hey, that would preempt me," so we make sure that the contention's dealt with later, and not -- and then not giving the advantage to the ASCIIs over the IDN? >>BRUCE TONKIN: But why would you use an IDN script if you can represent it in ASCII? I mean, that's where I'm losing in this argument. So surely, using that one you've just given as an example, why wouldn't I actually apply for dot caxap? It's going to be used in a lot more software than the Cyrillic version. I mean, as a decision that -- if that's generally what you want, and that generally is the issue, you don't actually need IDNs. You might as well just use the ASCII. >>OLOF NORDLING: No. Because I mean you're talking about a user here. The user is sitting with a Cyrillic keyboard, and I mean there's not -- it's not easy for him to -- >>BRUCE TONKIN: To enter the ASCII. OLOF NORDLING: -- make the ASCII caxap. >>BRUCE TONKIN: Right. >>OLOF NORDLING: So it's a user convenience. Well, the main reason for introducing IDN in the first place. >>BRUCE TONKIN: So you're saying at the new gTLD level, we add a grounds for complaint -- if we are having an IDN round coming, you know, at a different time, that a grounds for complaint is that it may interfere with an IDN application? And so if someone has paid a hundred thousand dollars to be in the round and they get knocked out at that point -- >> Because someone may apply. >>BRUCE TONKIN: Someone may apply in the future. >>CARY KARP: And that's the concern. >>BRUCE TONKIN: Yeah. >>CARY KARP: I mean, the concern is that there is speculative potential in understanding the fact that if I get this ASCII label, some entity at some future point may so wish to have the IDN correlate to it, that I will be able to turn a profit. >>BRUCE TONKIN: Yeah. >>CARY KARP: I mean that's where the squatting comes into this. >>BRUCE TONKIN: No, I understand, yeah. Yeah. >>CARY KARP: And don't on focus what we're using in exemplification there because we could easily have manana and manana or banana and banana. >>BRUCE TONKIN: Yeah. >>CARY KARP: I mean, the concern has nothing to do with the way we're trying to exemplify it. >>BRUCE TONKIN: So one of the ways of dealing with that, I suppose, is to say -- I think we had some discussions about this in the new gTLD committee -- that what is the issue? Is it a release state of the IDNs or is it a process issue? You -- you may well allow people to apply for the IDN TLD in the first round, in terms of getting the string contention issues sorted out, but it may be that the date of release is different into the root, depending on the -- on other matters. >>CARY KARP: Right. >>BRUCE TONKIN: But I just sort of -- I'm very wary of something where you're sort of able to complain about something you may or may not do in the future, but your -- and I understand -- I'm just giving the opposite of your view, I guess, Cary, and I -- yours is equally valid that someone can cyber squat, but I'm also just trying to look at it from a process point of view that I think you obligate both parties to put in and pay their fee, and if there's contention, there's a way of dealing with that contention. And then the introduction of IDNs, if for some reason, you know, the technical community's chosen a different launch date for inserting in the root, would be different to the application process. >>CARY KARP: Right. >>RAM MOHAN: Yeah. There was support in the working group to ensure that a hostage situation would not occur; that new gTLDs that are non-IDNs would not get prioritized in the application process; to really consider all applications together -- >>BRUCE TONKIN: Together, yeah. >>RAM MOHAN: -- rather than, say, you know, exclude IDNs at the start of the application process. As to when they get prioritized and get into the root, that's kind of a different issue altogether. >>BRUCE TONKIN: It's a different issue, yeah. >>RAM MOHAN: But if there was to be a case where IDN TLD strings were not allowed to be applied at all, then you have this issue here. >>BRUCE TONKIN: Yeah. Yeah. So I think our objective is to try and at least be able to apply -- you know, I think the timing that I'm envisaging here -- and I don't know whether the IDN people in the technical community can comment, but I think from a new gTLD process point of view, it's unlikely to be launched before first quarter of '08, and so the question is: Is the technical testing and stuff likely to be complete by then, that it would align, or are you talking, you know, '09, if you like, for IDNs? >>RAM MOHAN: Well, I mean here we really didn't consider implementation and launch considerations. What we did consider was application and consideration of applications, rather than actual implementations. >>BRUCE TONKIN: So let me just give me a bit of a queue, since there's a few comments on this. So one of the -- what we did with the reserved name working group is we -- each time someone was putting in a recommendation, we're trying to just test how we'd actually incorporate it into the work that we've done, so that's kind of why I'm questioning these things. I'm trying to see how we'd implement them. Okay. So there were a few hands up before. There's Avri. I think I saw Subbiah. Anyone else? Werner? Tom? Anyone else? Okay. Go ahead, Avri. >>AVRI DORIA: Thanks. I think in some ways, it's almost covered in some of the new gTLD, because -- but it's an extension in concept. What you've got is communities being able to challenge something. So let's say sugar was a community. The caxap comes through, and then it's challenged by the sugar growers, who say, "That is in an IDN." So what we're really adding is not so much that somebody may want to apply for -- okay. That's one criterion. I'm not saying it's invalid. But someone can actually say, "When you look at that as if it were an IDN, that does belong to a community and, therefore, it could fall under that basis." It's already been sort of cleared out within the gTLDs, similar to "bank." In other words, it's sort of very similar to that category, but a slight extension of it. >>BRUCE TONKIN: Right. Okay. Subbiah? >>SUBBIAH S.: [Speaker is off microphone] >>GLEN de SAINT GERY: Switch it on. >>SUBBIAH S.: [Speaker is off microphone]. I just wanted to add a point that it's actually a little bit more complicated than that. [inaudible] but I think the best way to think about this is, just like [inaudible] address this problem [inaudible] actual complication because it's [inaudible] whatever [inaudible] every single aspect of IDN, and it all stems from probably this thinking. I think the general thinking is that there are two languages, English and non-English, and that doesn't work. And I'll give you an example right here, which is that if two language -- if, initially, some Unicode tables, some script tables are not ready, some community is not ready, so we launch some languages first. I mean, ASCII and then in another round we launch some ready languages first. Then you launch another round, other ready languages. Well, you know, the conflict that would happen between two languages that are non-ASCII. The similar type of thing we've talked about. I mean, so this could be an ongoing thing and it's not just an initial round thing followed by the next thing. I'm just pointing out complications. But that's going to be how it's going to be with almost every issue because we're not talking about just ASCII and non-ASCII. We really are talking about lots of languages and it just -- you know, I just wanted to point that out. I mean, this would be some -- this extra point I pointed out in context with this -- and it can be quite easily covered by adding some extension to what we're discussing right now, but that may not be so easy in things that come up later, so... >>BRUCE TONKIN: Okay. Werner? >>WERNER STAUB: Okay. I think it's actually important to have this requirement as an agreement [inaudible] separately, even though we may probably have a process that will address it almost entirely, thanks to what was just explained in terms of a cycle where IDN could even apply if the introduction date were supposed to be later, pending some clearing of technical or other things. However, it will not be totally sufficient because there could be cases, for instance, of a link to ccTLDs. I can give you an example. If somebody applied for dot moh, m-o-h, that could probably be a string that Mongolia, m-o-n -- and the Cyrillic H looks exactly the same as our -- no. The Cyrillic N looks exactly the same as our N. H. Sorry. [Laughter] >>BRUCE TONKIN: Point taken. >>WERNER STAUB: The problem is that dot mon in Cyrillic looks like dot moh in ASCII. So it would be confusingly similar if dot mon in Cyrillic came later than dot moh in ASCII. So there would probably have to be some ability to challenge it just, you know, even though they'd probably design a process that would avoid the thing in the first place. >>BRUCE TONKIN: Okay. Tom? >>TOM KELLER: Thank you. Well, I have some kind of a problem with that notion you made that the two applications could be at the same time, but it's -- it depends on, you know, what kind of TLD is it when it is put to the root. I think it is a bad and unfair business practice for people kind of applying for a TLD, paying the money, but getting a promise to get it sometime somewhere. Right? So I'm just saying it would be a very [inaudible] thing that would kind of tick off maybe the IDN community, you know, if you would -- kind of telling them that everything is starting, but only to a certain point, and then they have to wait for another couple of years, which isn't closely described. I don't think that would be a way to go. >>BRUCE TONKIN: Yeah. I think -- certainly, I'm not -- I think the clarity we can get at the end of this meeting, I guess, on the timetable for IDNs would be very helpful, I think, in terms of trying to synchronize the timing. But I think I agree with what Subbiah and others are saying, that once you start ending up with things happening at different times, it, you know, adds a lot of complexity. And I hadn't even thought about the language issue, the fact that you're introducing scripts at different times as well, rather than aligned all at once, yeah. Okay. Anyone else wanting to talk on this particular one? Okay. Next one, Ram? >>RAM MOHAN: If we could go to Slide 5, Bruce. The second area of general agreement was that -- was to recommend consultation with the GAC on areas of geopolitical impact. The specific statement that the working group came out with was agreement that within the process for new gTLD consideration, the process for determining whether a string has geopolitical impact is a challenge, and that GAC consultation may be necessary but may not provide comprehensive responses. So what we're saying here is that especially for strings with geopolitical impact, there is a -- this is not something that is -- this is probably merely a superset of an application that has come in in normal just ASCII application, rather than an IDN application. The differences are not dramatic here, but what we're saying is that especially when it comes to the name of a country or a region, et cetera, that has geographic or geopolitical impact, as represented in a local script or in multiple local scripts, some consultation with the GAC might be necessary. But we also underline that you may not get the answers you want or you may not get to a final resolution on this area. >>TOM KELLER: Okay. Ram, just one question. In what respect do you think it is different to make a judgment on an IDN TLD string in regard to an ASCII TLD string? I mean, it should be the same problem, right? >>RAM MOHAN: Yeah. I think the principle is the same, Tom. The difference is that you may have a given string that may be represented -- that you may have a government, for example, saying that a string ought to be represented more than one way; that there is not -- I think the difference is that in IDNs, you don't -- you often will not have a one-to-one mapping, while you probably more likely have a one-to-one mapping in ASCII. >>BRUCE TONKIN: Yeah. So the way -- just picking up on what Tom has said, and we've just discussed geographic names in the context of new TLDs, that the way they're currently going to be handled, you know, as, you know, current recommendations, is that one of the criteria relating to the applicant and one of the mechanisms for objection is, if there are established institutions that relate to the name -- or let's call it "relate to the string" -- then those established institutions can file a complaint, saying that they don't believe the applicant represents that established group. So, for example -- and we talked about some of these last night -- but we're saying that if the string is in use as representing that established institution, which could be a country or geographic region, then that would be grounds for -- you know, if some entrepreneur, you know, small country somewhere was applying for it. What you wouldn't be allowed to be would be -- and we talked about the example of something like the word "OPoC" and saying, well, some -- if, in your particular country, you're not using that in any other script, that wouldn't be grounds because you're saying in your country you're not using the script in that language to represent that word, and someone else has applied for it and you can't show, "Look, I've got -- this is what -- all my government documents, you know, use that word in that way, and I'm the institution representing that." So that's how that would be handled as a complaint process. So as Tom says, it is no different whether it's an IDN or ASCII. The process is the same. But you'd have to show that you are the established body associated with that particular string, written in whatever script that is. >>RAM MOHAN: Right. And I don't -- I think from the working group's perspective, we're not recommending treating it as unique or different from ASCII. >>BRUCE TONKIN: Yeah. Just pointing out it's more complex. Yeah. >>RAM MOHAN: It's more complex than just a one-to-one mapping that often exists in ASCII. >>BRUCE TONKIN: Yeah. Yeah. >>CHUCK GOMES: Bruce? >>BRUCE TONKIN: Chuck, yeah. >>CHUCK GOMES: Yeah. I'd like to call attention to a statement made -- I think it was by Bill Dee -- in the GAC GNSO meeting we had at the end of the Sao Paulo meetings, and it relates to the suggestion here of consulting the GAC on a particular string. As I recall, Bill said pretty clearly -- and we know that the IDN -- or that the GAC guidelines for new TLDs aren't finished yet, but the GAC did not expect to have an operational role, and I think this gives them an operational role in it. And we also know that the GAC -- it's very challenging for the GAC to respond in a timely manner. So it's my opinion that we probably don't want to go down a direction where we consult the GAC. Not that their input is not important. It just operationally won't work and they don't want to have an operational role. >>BRUCE TONKIN: Yeah. So the way to handle that, Chuck, I think -- and I've, you know, had some further discussions with the GAC over lunch yesterday and also yesterday afternoon, but basically I think we're both aligned, in the sense of the GNSO and the GAC, in that the GAC's input should be on the broader policy principles at the front, not sort of commenting on whatever the TLD is, after the fact, as the GAC. So the consultation we're taking is what we're doing here. This is the consultation at this meeting. And basically, we have sort of -- I think in our session tomorrow, I will elaborate a bit more on the geographical stuff in the context of what we were talking about earlier this morning, but how we're currently dealing with the geographical things and how we propose to deal with it and then get GAC input on that process proposal, or how we're going to handle it. And if that matches their current principle or they have some suggestions, that's how to deal with it. But we're not asking for the GAC to, as part of the process, say, "Hey, have a look at these strings and come back with a GAC consensus on whether you like the string or not." What we are saying is that as part of our process, an established institution -- which could be one of the GAC members -- of the country can complain about their string, but it's only their string. They can't complain about someone else's string. Yeah. Philip? >>PHILIP SHEPPARD: Bruce, I think both the earlier point we had on ASCII squatting and this same one here I think probably underlines that we have a belief in our existing process, which is objection by the relevant community, but I think it probably underlines that we need to make more specific reference to that in our existing Recommendation 14A, because at the moment, all we're saying is that a process will be put in place to enable efficient resolution, and then we mention, later on in notes, we've had discussion about this community, [inaudible] community support. So I think if we are now talking around also the IDN issue being factored into that, we need to be very explicit that that is exactly what we mean, because we haven't actually said that yet in our report. >>BRUCE TONKIN: Yeah. And this is the sort of thing I was talking about before, that what we need to now do is almost have a -- it's a bit similar to the way the IETF writes its documents, is they normally have a section on security, which is sort of a part of every IETF RFC. It's, you know, one of the security implications. And so, Avri, what we probably need to do with discussion, at least, and possibly some of the guidelines, is almost have what's the IDN implication here, or what's the bit that adds a bit more complexity, just so people are aware that we've taken into account there is some issues here and this is how we're dealing with it. Let me just find that one you talked about. This is the one here I'm thinking of, 14C. Based on -- >> 14A is -- >> A. >>BRUCE TONKIN: And what's -- that's to do with contention, though. >> Yeah. >>BRUCE TONKIN: Contention is when two people apply for the same string. So 14C is where we're talking about someone complaining about an applicant not being the appropriate body to run that string, and that is there substantial opposition to it from among significant established institutions of an economic sector, cultural or language community. What we should probably add there is geographic. >> Yeah. >>BRUCE TONKIN: I'm not exactly sure of the word, but at least the geo something. "Geo" followed by some other letters. >> The cultural or linguistic risk community might cut it. >>BRUCE TONKIN: It could, but I don't think people necessarily -- I think we need to be more explicit. I agree you can read it that way, but I think I'd be more explicit in there and add geographic. It has to be an established institution representing that geography, essentially. >>PHILIP SHEPPARD: Yeah, but you also need to -- the reference -- I was happy with that wording for the basic objection to the name, per se, although our process has actually taken that off the list, which then presupposes the question "How do you get it back on again," but the reference I was making to 14A was the potential for contention. >>BRUCE TONKIN: So this is two parties wanting the same string. >>PHILIP SHEPPARD: Yes, exactly. >>BRUCE TONKIN: Yeah. >>PHILIP SHEPPARD: And it may be that the grounds then -- one grounds for awarding it may be the fact that it has an IDN equivalence and that can be based on the idea of the community's vote for that. >>BRUCE TONKIN: Yeah. And that's where the comparative -- so basically, what you're saying is, we need to clean this section up, obviously, but effectively we're taking this concept on the significant established institutions, and I was going to go through, later today -- I've worked with Liz on a process diagram for explaining this a lot more clearly, but essentially what we're saying is one of the triggers is, when you've got contention, one of the triggers in the process is, does it fit in this category, and if it does, it triggers a comparative evaluation process, and part of that evaluation process would incorporate the elements you're talking about. And we talked about this a little bit. I can't remember whether it was yesterday or last night. But you might start looking in the comparative evaluation on, you know, the language community aspects and the degree of support there and experience and all that sort of things, yeah. >>LIZ WILLIAMS: Bruce, I think the other interesting piece of this -- even through, Philip, we just add a layer of complexity to an application process -- it seems to me that there is no reason for -- yeah, thanks very much for that. There's no reason for an IDN applicant to be subject to two different dispute resolution procedures, and I think again, it is likely that we need to instruct applicants that they are likely to receive an opposition, and this is the way in which it would be resolved -- >>BRUCE TONKIN: Yeah. >>LIZ WILLIAMS: -- and the publication, the paying of a fee -- and we'll go through it later, but it's very important that we establish the same systems for dealing with contention between applicants for the same string, because one wants them to -- one wants to operate, but doesn't want the other person to do it. So that's going to require some very significant thinking because it's very, very political and contentious. And we have to have evaluators that can make those decisions. >>BRUCE TONKIN: Okay. No. 3? >>RAM MOHAN: Thank you. The third area of agreement was that a suitable process for consultation including with relevant language communities is needed when considering IDN -- new IDN gTLD strings. The -- again, the concept isn't far different from what you have in an ASCII TLD application, in a non-IDN TLD application. The difference here -- or the addition here that is being suggested is that when evaluating whether an IDN string is appropriate, et cetera, do not forget the language community that the -- that that string is written in. So if it is written in a particular script that represents a language, then to make sure that community gets an opportunity to provide input. This might very well be through the already-established common processes and other processes. So we're not suggesting a new process. In this case, we're simply underscoring the fact that the language community has a specific interest because it is represented in that string used by that community. >>BRUCE TONKIN: So one of the things we talked about in Marina del Rey and we had some of the ICANN staff present, including Paul Twomey, we are talking about what constitutes enough notice to an affected community. And kind of what he was suggesting, which I thought was sensible, was who say that as part of the standard application fee, ICANN would undertake a certain degree of outreach, and that might be advertising in major newspapers around the world, the "Wall Street Journal" in the U.S., the "Times," whatever it is, some sort of publications that are widely read in different parts of the world. Obviously, ICANN can't afford to bring every single person in the world to tell them about a new TLD. The concept was where it was a specific language community that would not potentially receive those communications -- let's say it is on some specific script in some part of Africa -- that there would be additional outreach done. And it is quite likely that ICANN would charge a fee to the applicant for actually doing that outreach because there is a standard fee that covers just a broad brush -- as much publication as you can. But for a particular language community, there might be an additional fee and ICANN would then advertise, pay the government, put notices in the newspaper of that particular community; and that language community might be distributed, too. It might be in multiple countries. But there is a real outreach effort to inform the community of that string. That's some of the concepts that have been talked about. >>RAM MOHAN: I have two comments. I think the concept has a tremendous amount of value. However, I worry about the slippery slope of have you had adequate consultation because no real standard exists for what is the language community and do you actually cover the entire diaspora. I would suggest that -- certainly, further thought has to be given here. I think it is an excellent idea to have some funding that allows for a broader outreach into the language community. Just so -- as long as ICANN doesn't get itself into a bind of saying we've adequately consulted the community because you then open yourself up to saying -- >>BRUCE TONKIN: I don't think that's what you'd do. I think What you're saying our standard process is we give notice, and I think what we are doing in terms of fairness is some additional effort in some of those communities. You're right, we have to be careful you are not exposing to liability what you are doing there. Kurt, are you pointing? >>KURT PRITZ: Somebody over there. >>BRUCE TONKIN: Let me take a queue then. Anyone else? I have got you, Werner. >>SUBBIAH S.: I just wanted to stress that the challenges that will be faced in this -- because I look around, even in this committee meeting, which isn't talking for the first time a lot about IDN TLDs. I think mostly about IDN TLDs now, I think, we are not talking really about the Latin script in particular because a lot of that has been taken care of previous rounds of IDN.ASCII, for the most part does solve that problem in the past. Really we are talking about the really different scripts, IDN TLD scripts. From that perspective, if you look around the room, pretty much I can see, except for a German masquerading -- sorry, an Mongolian masquerading as a German over there, there are very few non-Latin people in the room. It will be a challenge to communicate with them, to get them to participate. As for the notion that Bruce suggested that, perhaps, you add the fee itself, to add to the 50 or $100,000 -- I heard $100,000. Most communities -- one of the things we did discuss -- There was no agreement on this, is that financial -- the cost of applying should be reduced. In fact, one of our committee meetings, one of the Russian people that is part of the RuNIC, which is a TLD that has been run for many years by Russians, dot RU, it that has several hundred thousand names, they claim they only spend 40, $50,000 a year running it. Whereas, application fees -- So, you know, as it is there is a talk about the application fees being too high, otherwise, you will not get participation from the communities themselves. I think the GAC also made a recommendation that there should be more diversity in registries that open up in general. So this would be a way to do that. But if the fees are so high and now you want to talk about adding more fees to advertise and so on and so forth, I think it is going the wrong way. >>BRUCE TONKIN: Chuck? >>CHUCK GOMES: First of all, I think we need to look at the operational issue again. I really don't think this makes operational sense in terms of the process of approving new TLDs. It be would be terribly time consuming and expensive and so forth. At the same time -- >>BRUCE TONKIN: I'm not understanding. Sorry? >>CHUCK GOMES: What I am getting at, if part of the process for an IDN TLD is to have to go out after the application has come in and consult with a language community -- >>BRUCE TONKIN: No, that's not what I suggesting. >>CHUCK GOMES: I know that's not what you are suggesting, but that's what I am reading into the recommendation. By the way, I think consulting with the language community is a very good idea, but I think it should be the responsibility of the applicant to do that and that we could in the application process encourage applicants applying for new TLDs to consult with language experts for the particular script that they are applying for much better than having this as part of the evaluation process after it's been submitted. >>BRUCE TONKIN: So, Chuck, the suggestion I was making, context, is purely the notice part, which is something that happens in seven days or whatever it is. That's just advertising in appropriate publications. It is not a timely process. It is just saying that ICANN will do a certain degree of effort to publish a notice of strings. We are saying if it is a particular language community, it should also identify some publications in that community and publish them. That's not a time-consuming process. It is just posting and giving notice. >>WERNER STAUB: Chuck said most of what I wanted to say about the applicant being in the best position to consult the language, academies and so on. I might want to add that in terms of can we trust this, a good-faith applicant is going to do a good job certainly in doing that. And the bad-faith applicant would have a very hard job to fake this. It is almost impossible immediately. I don't think it would be possible for an applicant to kind of pretend that they have the support of a fake language academy. This would be visible immediately. >>BRUCE TONKIN: Yeah. But not all languages or scripts have a structured academy, though. >>WERNER STAUB: Indeed. This depends for every country. English doesn't have something like that. Whereas, especially weaker languages usually got somehow their act together and start to regulate it because it is needed for the strength of the language. But, still, if there was none and somebody pretends -- I just created a committee, you would immediately see it if you contacted other people in the context of the country, these people will be unknown. It will come up immediately. >>BRUCE TONKIN: Clarify where this fits into the process. You're saying -- I was referring to notice and now we are talking about something that's in the application giving evidence of consultation with the language community. And then you are asking the staff to evaluate that or just giving advice to applicants to do so? >>WERNER STAUB: If you look at one process that is similar that has existed which is dot cat, it was not an IDN but it was culturally linguistic. The Cultural Language Authority, which was the capital of the CAT languages was part of the application -- the organization that supported it, submitted it. But the applicant was asked by ICANN to submit the address of the ministry to consult basically. ICANN didn't find which ministry to consult, but ICANN asked the applicant to provide the address, and then the ledger was sent by ICANN to receive the response. >>BRUCE TONKIN: Is that under the category then -- that's coming back to this, I gather. It is basically saying that if you're going for something that has a lot of meaning in that language community, in effect, the name of the country or something like that, in that language, then it is going through this. I am just trying to make clear that we are reasonably consistent with ASCII, so I can have all sorts of different strings and I am not consulting some English language community as to whether I can have dot red or dot green in that language. But I am saying if I go for dot bank or dot police or dot government or dot Australia where there are established institutions in ASCII, they have the ability to challenge, if you like; and part of that challenge could then be that the -- both the claimant and the applicant would go into a dispute process. And the applicant as part of the dispute process will say, actually, I do have the support of this community for this string and, therefore, I should have it. It is actually part of the dispute process where you are requiring this additional work. I just want to understand. >>WERNER STAUB: I think it is good for the applicant to submit people -- submit addresses of the ministries and whatever, authorities, that he says -- they support this today. They know what this is about. The applicant is the best place to do this homework and much faster. Whereas, if it is after, the you have to find an objective way to identify the correct people to talk to. That will be almost impossible. >>BRUCE TONKIN: From an application process, that's the equivalent of providing references really. If I'm applying for a job, I provide references of my (inaudible). >> Indeed. >>BRUCE TONKIN: So what you're saying is you're applying for this string in this language and then you sort of have some references, which can be administrative, blah, blah, blah. Which ICANN can then communicate. >>WERNER STAUB: Indeed. >>SUBBIAH S.: I just wanted to add (inaudible). There is a lot of precedent for this. 22 Arab countries have done an experimental system. They worked together on the Arabic script. The Chinese, the (inaudible) gentleman over here, they were -- the different China -- four groups here, (inaudible) China and Taiwan. They worked it out and they got their language tables squared, and they got it squared with the Japanese and Koreans. So there is a lot of precedent of language communities coming together in the domain name space exactly in the last eight, nine years since IDN has been around. There is precedent. The other thing I would also suggest is not only should the applicant be charged with bringing the references and so on and so forth, but on the evaluation side, on the committee itself that actually awards, I think there should be some representation from the community if -- there should be an ideal situation if somebody maybe even speaks that language or something, so at least some representation from that -- >>BRUCE TONKIN: As part of the evaluation? >>SUBBIAH S.: As part of the evaluation. It is an issue of legitimacy. >>RAM MOHAN: I wanted to underscore we did cover this specific topic in the IDN working group. Although there was some support for that, we did not reach agreement on having a committee per TLD application or having a specific language expert for every single script that came in. We had some support but not agreement. >>BRUCE TONKIN: I think what Subbiah is saying, it is not uncommon as part of your evaluation process -- this is an issue, I think, that gets exaggerated with IDNs because in a number of areas, we are saying in a number of applications, the staff take the application and review it against a number of things. If it is in a script that none of the staff knows anything about, it would make sense for them to get advice. It doesn't mean they are a standing member of some huge community. It basically means they've given advice as part of that process, which seems to make sense, yeah. Kristina, Tom. Just hold on one second. >>KRISTINA ROSETTE: I was thinking as an implementation matter, just picking up an idea that I think Philip posed yesterday with regard to requiring the applicant to set out in the application their measures of success, that this might be one way to incorporate this idea in the sense of -- to the extent that the applicant is seeking the TLD string in a particular language script. That measure of success section would have to also discuss and incorporate the extent to which the relevant language communities have been consulted. Having said that, it seems to me that one area in which that idea would not work is if the TLD string is sought in ASCII but kind of in an inadvertent ASCII squatting example. In the sense that if the applicant is for whatever reason seeking caxasap, not realizing, for example, in Cyrillic, it is sugar, you will have a gap there; but I don't know realistically to what extent, how often that will happen. >>BRUCE TONKIN: Right, okay. Tom? >>TOM KELLER: Yeah. One thing we have to be careful about is we cannot keep fear in the whole game. What I am hearing is that, if you want to apply for Indian.all or whatever, what we are trying to do is to make these guys jump through many hoops and show notices, show that you have feedback from the language community and so on and so on. >>BRUCE TONKIN: You have to be careful how you balance that. >>TOM KELLER: It is hard because it is all India. It is hard to comprehend. We probably don't even understand. I wouldn't even understand all the consultation that would have to take place if it is Chinese script. I am certainly not an expert. I don't even know that script. I don't know the language. And the other thing is that that might imply certain costs on the process. But you can't say that only because something is more difficult and not streamlined to the English language and to the ICANN processes that it has to be a higher fee. Yes. (Multiple speakers). >>BRUCE TONKIN: You have to be careful with more headings and hoops. I think that's Subbiah's point as well. Alan? >>ALAN GREENBERG: I think I would like to support the concept that if we are going to handle different strings in different languages, someone has to be involved in the process on the ICANN side whether it is a standing committee or someone ad hoc who at least understands it and knows something about the community. As an example, if you are going to get an IDN in Singhalese, it is not at all clear you have to advertise in the "New York Times" to see if there is a conflict. The cost to advertise in Sri Lanka may be a lot cheaper than advertising everywhere else in the Roman character world. But without someone who at least speaks the language and understands what the word is saying -- >>BRUCE TONKIN: Or even understands what's newspaper is in that community. >>ALAN GREENBERG: And what the community is and should be consulted, I think we are completely in the dark and will stumble badly. As was pointed out, we have a fair amount of experience in IDNs in those communities but it runs by those communities who actually speak the language. We need that component. >>BRUCE TONKIN: The difference between consultation and posting and giving notice. I think ICANN has a responsibility to really give notice, and I think that's perhaps a fair point that Subbiah has made, that we should add an additional fee for that. As you pointed out, it may be cheaper to advertise in some of those. >>ALAN GREENBERG: It would be a negative fee. >>BRUCE TONKIN: You could get the front page, but it is appropriate, I think, that ICANN is doing enough diligence to at least post notice as opposed to let's have six weeks of meetings. Their obligation is to post notice and that community can then go to the normal part of the process. >>ALAN GREENBERG: Part of that due diligence has to be someone who at least can read the script, has seen it once. >>BRUCE TONKIN: Yes, yes. Philip? >>PHILIP SHEPPARD: I was going to make a similar point to Alan. I think we all agree on the concept of giving notice. I would like to push back on the concept that the particular applications may require additional expense on behalf of ICANN to give notice, very much for the same reasons. All we are talking about is actually, in all cases, making sure the notice is targeted in a relevant way. >>BRUCE TONKIN: Yes. >>PHILIP SHEPPARD: That is a trivially easy job done by public relations and other consultancies around the world everyday. It may not be an expertise that ICANN currently has, but it is an expertise that is dead easy to get ahold of, and I don't think it is particularly expensive. >>BRUCE TONKIN: We are being equivalent with the ASCII world. The equivalent of advertising in the English papers is essentially targeting that community and equivalent in other language communities, which may not be newspapers. It could just be stick a few posters up on the nearest tree, whatever, whatever is appropriate for that community. >>PHILIP SHEPPARD: I think the idea of differential fees or additional fees, I think, is something that we should not be recommending because I don't think it is relevant and I think it is terribly easy to actually identify relevant notice. It is just a question of consultation. >>BRUCE TONKIN: Yes. I like that terminology "relevant notice for that community." >>LIZ WILLIAMS: Philip, a quick clarification question because I'm taking detailed notes. What's possible to do, what's reasonable to do and what's equivalent between types of applicants because we don't want to be unfair in our process. Is something like a shareholder notice -- you know those big advertisements that take place in the big papers, we are going to give you a billion bucks. We are notifying you, this is at press. It is a very generic notice. I think I need some help around suggestions about how that might look but not now. >>BRUCE TONKIN: Comes down to relevant communities. That's relevant to the share market, for example. May not be relevant to other people. Mike? >>MIKE RODENBAUGH: Just real quick. I find it pretty funny we keep talking about publishing notice in newspapers and things. Let's remember we could pretty much target any language community we want through online advertising. It's much cheaper and probably a more effective way. >> If you have got an Internet connection. >>MIKE RODENBAUGH: Come on. [ Laughter ] We are talking about TLD strings. People that are going to be interested in it are going to have Internet connections, right? You don't need to really give notice to people who are not on the Internet, in my opinion. >>BRUCE TONKIN: Not sure I buy that argument because you are actually one of the objectives of introducing new TLDs is to get more people on the Internet from that community. I accept your point that is one form of advertising that doesn't have to be purely newspaper. Okay. Next topic. Ram? >>RAM MOHAN: Thank you. The next key areas are probably areas you've heard about before and so I might end up (inaudible) through them. Agreement No. 4 was that there should be one string per new IDN gTLD. The more detail of this is that the approach of the new gTLD PDP says one string for each IDN gTLD. We believe it is relevant except in the rare cases where there is a need to cover script-specific character variance of an IDN gTLD string. We expect this to be very rare, but it is something that you have to consider. But, in general, the concept and the principle of one string per IDN gTLD is sufficient, and there is broad agreement within the working group that that is an appropriate approach to take. >>CHUCK GOMES: Does that mean that an applicant that wants to apply for a gTLD in multiple string -- multiple scripts would have to submit a separate application for each script? >>RAM MOHAN: Yeah, I think that is the implication that each string that you want to apply for is considered a new IDN gTLD and, therefore, you apply for it using the normal process. In other words, we're not saying one string may be considered a semantic equivalent of another and, therefore, they should be considered as one. We're saying if you are applying for an IDN gTLD as represented by a given string, that string you apply for constitutes all of your application. >>CHUCK GOMES: So, for example, if dot museum wanted to apply for IDN TLDs in several different scripts, they would have to submit a separate application for each script? >>RAM MOHAN: That's the general implication. >>CHUCK GOMES: So, in other words, we're not really trying to provide a multilingual experience across -- on a global basis but rather on a very restricted basis for one particular language group. That seems to be very different than the way the Internet works. >>RAM MOHAN: I think the problem we were encountering is that there is no good way -- or a good principle to say what should be bundled when you apply. And, therefore, the approach we took and the discussions we had inside of the working group was to go for really the principle of least confusion, which is when you are applying for a string, the evaluation is for that string, not for that string bundled with a set of other strings that may mean the same -- that is considered to be the same label as represented in other strings. In other words, if you want to apply for something in the Han script, that you wouldn't also in the same application say that this should be considered in an Indic script. >>CHUCK GOMES: That's a very localized approach to IDN TLDs rather than a global approach, which is the way that the Internet works. >>RAM MOHAN: I don't disagree. >>PHILIP SHEPPARD: Ram, I agree with the thrust of the main recommendation here. I just want to understand better the rare exception. Is the need you're addressing there one of confusion or one where you might have something like keyboard variants where the user will actually think there is equivalents and, therefore, you want to make them equivalent? >>RAM MOHAN: It is the latter, not the former. In other words, it is a specific and -- the applicant will have to establish this rather than something that the evaluators have to figure out. But it will be a case where Representation A is identical -- is considered exactly the equivalent of Representation B and that is established and provable in that particular character set. >>BRUCE TONKIN: Cary and then Werner. >>CARY KARP: I think it is probably true that the notion of bundling is going to demand greater consideration on all levels. I mean, if it is a TLD operation consideration, it is going to be a root operation consideration. And although it is true that we did not figure out some clear way to address that in our present study, I'm not entirely certain that in our present study, I'm not entirely certain that we are going to be able to survive all the way through implementation without getting through this position. >>RAM MOHAN: Let me just add something more to what Cary is saying. I think that's exactly right. The approach In the working group, what we were able to come to agreement was this very localized approach but when it comes to implementing it, I think many parts of this are going to fall apart because you will find applicants -- >>BRUCE TONKIN: That's not what I want to hear. >>RAM MOHAN: I'm sorry. But I think you are going to find two things. One is that there is a very heavy burden placed on applicants who do want to -- who represent a particular string, particularly strings that have meaning associated with it. You were talking about bank, for example. This poses a heavy burden on them to depict scripts and to represent them one application each, especially if there is a $100,000 fee associated with it. The second thing is that in the evaluation itself from the ICANN end, I think the burden is very high to take a given string and then look at it across multiple languages. So, Chuck, your point is well made. In the committee, we did not come to a solution for how to handle a globalized way when the principles elsewhere talk about one string per IDN. >>BRUCE TONKIN: So one of the ways to handle that, I think we've had some discussion about this in the new gTLD committee but you could decide to -- I think you're right in terms of that recommendation. And then the issue on the implementation side particularly regarding cost, et cetera, is obviously, there are economies for one applicant that is applying for -- let's say they are applying for four strings. And so it would seem one of our principles is that the application fees should in some way be related to cost and cost evaluation and so forth. So you could say there is a cost for putting in one string and then a lower cost for putting in a second related string. But I think the criteria for that -- I'm not sure whether you have talked about this in the group much, but you could say the criteria for that lower fee is that the registry is doing something about effectively aliasing the registrations in those two strings. In other words, you're not applying for two strings where it is a completely independent set of registrars. You are saying we have got these two strings which are both valid ways of representing this concept. If you submit a registration for one string, you automatically get the registration for the second string. >>RAM MOHAN: I think that's an excellent way to cover the implementation issue. We did cover aliasing inside of the working group, and we had some robust discussion with absolutely no agreement whatsoever. You will see in the final report we have completely opposing points of view on aliasing. But the net of what we did actually on aliasing was effectively to punt in the working group. We said it should only be -- aliasing, when it is being discussed, it should -- we should be discussed from a policy perspective rather than from a technology implementation perspective. >> (inaudible). >>RAM MOHAN: Right, and we don't care about implementation. >>BRUCE TONKIN: So the concept is just simply that for -- "aliasing" might be the right word because it is a loaded term given the debate in the IDNs over the last several years. The concept is essentially saying if I had example.stream, I would also get example.stream2 if they're bundled together. >>RAM MOHAN: I think that's a good -- one good way to approach this issue of localization versus treating in the global way. >>BRUCE TONKIN: Yep, Mike. >>MIKE RODENBAUGH: But then I'm curious. Does that mean, for example, with dot bank that someone can apply for dot bank with a C at the end or just how it is spelled in some languages and different translated versions of the same word? That would seem to make as much sense to me as allowing strings that have similar characters in it, the variants. >>BRUCE TONKIN: You're saying that they would be confusingly similar? >>MIKE RODENBAUGH: Kind of essentially the same word or concept but in different languages. >>BRUCE TONKIN: Yes. Essentially the idea there, if we take, say, the Indian example where there is a number of scripts, the word "India" might be represented in a number of different ways and it could be -- there are competition issues and that might be something that's considered here as well. It may be that the operator of dot India wants actually to represent that in the four or five scripts of that country. So what we are saying is we are treating -- they are each new TLDs in the root. What we're saying is -- one way of what, I think, the concern is that you are then making them pay five times as much if they want five languages. You might say, You pay a fee for the first string and then maybe 30% for the second string and 50% for the third string or whatever. But the criteria on that is they have to be run effectively as one set of registrants. You can't say, I will make twice as much money out of this because I have now got two strings and I can sell that string to that person and this string to someone else. >>MIKE RODENBAUGH: I think that makes sense. Essentially, you're saying dot bank and it could be represented in Chinese characters, Korean characters, whatever the applicant wants. >>BRUCE TONKIN: And then you would have to have a standard that you would generally -- this is where the established institution people come in. If you are replying to dot bank in ASCII and dot bank in Chinese, you need to support the Chinese banking community to do that, if that makes sense. It is not carte blanche. It still goes through all the other checks of the -- >>MIKE RODENBAUGH: I can envision for generic terms many people would want to lock up essentially many major languages, and this could be quite a confusing evaluation process, complex. >>BRUCE TONKIN: Then they would have to be related. You can't just go you want dot flowers, dot shop. >>MIKE RODENBAUGH: No, no, but it could be dot bank in ten different languages. >>BRUCE TONKIN: Yeah. And in each of those -- because "bank" because you're picking a term that's related to established institutions, it has a particular flow. Part of that flow is that if you were you might well have the support of that, let's call it, the English speaking language community for dot bank, and then you decide you want Chinese characters and the Chinese banking community says, "we don't agree with that," it is not an automatic that you are going to get that other string. >>MIKE RODENBAUGH: I could also foresee, for example, dot Yahoo. We might want dot Yahu. We might want dot Yahoo with the two Chinese characters that we have registered and a whole list of things. >>BRUCE TONKIN: (inaudible.) As long as they relate it to that work. All I am talking about is not changing any of the approval process. It is just saying there could be a discount at the application fee level to not pose a burden in doing that, but you're not going to get them for free. They all still have to go through -- each application is considered on its own merits in terms of all of the qualifications. >>MIKE RODENBAUGH: Okay. >> There is absolutely nothing that would prevent half a dozen independent applications for dot bank, and three more dot banque and two for a half a dozen variant spellings bundled, our recommendations notwithstanding. Yes, when you turn 26 available letters into 26,000 available letters, it does get more complicated, yeah. >>BRUCE TONKIN: The principles are still the same. >>PHILIP SHEPPARD: Just a point of order. We can't seem to be debating something that is actually not a supported recommendation. I can't quite see the merit of that, given the time constraints we have. >>ALISTAIR DIXON: Bruce, can I just buzz in here because I don't think we are actually quite getting to the point that the working group got to. It was actually quite an IDN specific issue, as I recall. I recall there was an example of Farsi in Arabic. In some languages, there are particular characters that can be confused but are actually quite relevant representations in that particular language. And it is not like banque versus bank. Those are two different communities. We talking about a single community situation and quite limited situations. Others in the working group may have a better recollection, but I don't think we are actually talking about the issue that the working group actually addressed. >>BRUCE TONKIN: Yes. I think all we're saying is -- I'm just commenting, and I feel it is a fair point that you make. I am just sort of making the comment that it is not changing the new gTLD policy in any way, it is just that there could be a way at the application process level -- Maybe it is not something you do in the first round because one of the things we are trying to do in the first round, I suppose, is to not have something that's totally unmanageable. It may be that you don't give any discount at all; but in later rounds, you could allow some ability to do that, if they're related. Werner. Anyone else? I had Alan on there. >>SHAHRAM: Excuse me, do you hear me? >>BRUCE TONKIN: Who is that? >>SHAHRAM: Anybody hear me? >>BRUCE TONKIN: Yes, we can hear you. Can you please state your name? >>SHAHRAM: Hi, I'm Shahram. Can you hear me? >>BRUCE TONKIN: Go ahead and comment, yeah. >>SHAHRAM: Sorry. I talked. You can't hear me. I tried to have my point on the issue on 4.1.3. Can I do this right? >>BRUCE TONKIN: Go ahead. I don't know what 4.1.3 is but go ahead. >>SHAHRAM: I think it is related to the third issue, too. Related to the language in a community, I think (inaudible) I think these language communities should be specific communities, specific for the language that are related to each other. For example, the outreach and the (inaudible), yes? This comment can be in the first maybe some decisions and the decisions can done by this. It is the one community. Another community -- another greater community can be up (inaudible) communities. Again, do you understand? >>BRUCE TONKIN: Okay. Thank you. >>SHAHRAM: I mean the decision can be done in a two step (inaudible). One is a specific language and the other can be (inaudible). >>BRUCE TONKIN: Okay. Alan Greenberg. Thank you, Shahram. >>SHAHRAM: Okay, thank you. >>ALAN GREENBERG: My only comment is I agree with the concept that we may want to have multiple strings mapping to the same registry. We're going to have to be very, very careful in wording it. In my case, Quebec with and without an accented E may well be a reasonable example of two strings mapped to the same thing. In Canada, bank and banque, Q-U-E, may be but depending who is applying for it, they may actually be applying for two completely different strings. And, semantically, you cannot tell the difference. We have to be really careful on the wording, if and when we get to that stage. >>BRUCE TONKIN: That has to be dealt with. Two people are applying for two strings that are confusingly similar, that's dealt with under the contention process. Cary, I've got you. Werner. >>WERNER STAUB: The agreement lies in the single string per new IDN TLD was actually the initial agreement. It then turned out that it was quite a bit more difficult, specifically in the case of character alias and so on. So the concept was basically still there because it expected to start at least with one TLD, albeit forever, whether -- you know, how many TLDs should be part of the same string. However, even in the first round, it would probably be good if the applicant could state their related strings formally, that the applicant would think required from the operation of the TLD in the future. The applicant will probably be happy to start just with one of them, even if more than one are required. They should be able to state that formally. >>BRUCE TONKIN: Okay. Cary. >>CARY KARP: There are obviously certain issues that we just keep getting stuck -- bogged down in. They are recurrent and we do have to figure out what we are going to do about it. All right. I apply for bank.Quebec. And because Quebec with and without an accent load the exact same zone, fine. That's it. Bank and the other one gives them banque. There is no mechanism that ensures that I then delegate on the third level in the same identical manner or anyone to whom I have delegated on the third level delegates in the same manner on the fourth level. There is no mechanism available to us that allows to map an entire name tree into two different top-level domains. >>BRUCE TONKIN: Correct, yeah, because the tree goes down that way and then that way. Yeah. Ram? >>RAM MOHAN: The general agreement was pretty simple: When you're applying, consider one string per new IDN gTLD and that the bundling and the variants that we're talking about in the IDN working group, the primary focus was on the linguistic determination of what a variant is based on a script focus rather than semantic equivalents or spelling equivalents. So we really did not consider that a great deal. And I think that you have some commonalities in the non-IDN area that might be useful to consider. If somebody applied for dot color and someone else applied for dot colour, you might consider them semantically the same but today at the second level, you can certainly apply for color.TLD and colour.TLD and they can go to completely different applicants. At the top level, you have a larger issue of confusion but, in general, the principle is not vastly different. So my perspective is that the concept that was presented here which is one string per IDN TLD with, perhaps, bundling allowed with the lower application fee has some relevance rather than trying to figure out bank and banque, et cetera, and trying to somehow link everything together. >>BRUCE TONKIN: Subbiah. >>SUBBIAH S.: I just wanted to say that again to emphasize, to give concrete examples for the exception that was produced in this particular point, 4.1.4, the simplest way to think about the exceptions is simply that in a given script there happens to be two ways to type the same character. That's really what this is more or less driving towards. It happens in Chinese. It happens in Arabic and the Persian and possibly other places where basically it is two alphabet locations, pretty much pronounced the same way or something. That's a way to think about the very particular exceptions that were set forth here. Returning to the main issue is also the question of if you are looking for semantic equivalents, it gets -- as Mike Rodenbaugh said, it gets actually more complicated than that. There could be many different ways of how to translate a word into different languages. The word "bank", as I was -- for me, I know this, if I would say "I love you" in my language, I get slapped, okay, if I were to say that. Whereas, in English, I could get away with it because semantic equivalent doesn't necessarily mean the term. They are different words. On top of that, from the perspective of examples like Yahoo, they are sounds ultimately; so there are many different ways of pronouncing them or transliterating them and make sounds work. It gets pretty complicated whichever way you look at it. There are both levels of complication. There is no getting around it. It is a complex subject. It is complex because we've got lots of people speaking different languages. It's taken 2,000 years to get here, and they live on different borders and this is what it takes. It is again -- I emphasize it is not English and non-english. It is English with lots of other languages that are all different. The last point I would like to make is if flexibility -- Bruce, if flexibility can be made towards tiering the application fee, then I would imagine that there is room for flexibility for allowing applicants from the regions -- different types of pricing. I am just saying if there is flexibility for a particular issue, then one would imagine there is flexibility for adjusting application entry fees for different types of groups to get diversity. I would think that you couldn't do one without the other. I am just pointing that fact out, that's all. >>BRUCE TONKIN: Thanks, Subbiah. Next one, Ram. >>RAM MOHAN: Thank you. In fact, I am going to skip here and go to Number 6, which is limit confusingly similar strings. There is already a great deal of discussion that has happened. What we've said in the IDN working group is that confusing similar strings ought to be limited when it comes to the application process and we've really not -- we didn't spend a great deal of time in defining "confusingly similar" other than when we worked on it at the very start. Now, the Number 5 has limit variant confusion and collision. Five and six are, in some ways, are linked. What we are saying there is that measures must be taken, and I would say that the measures must first be taken by the applicant of the IDN string itself. But then it is something that ICANN in the evaluation process has to confirm that processes have been taken to limit confusion and collision due to variants. What we are talking about is substitutable characters or symbols within a script that represents a language. It is a lightweight recommendation that says when you are looking at applications, really the onus is on the applicant should be to ensure they don't apply for strings that are confusingly similar and they also limit the amount of confusion and collision within variants themselves. If you can move to the next slide. Chuck, you had a comment? >>CHUCK GOMES: I have a question because I thought I was clear in terms of the difference between five and six. I am not sure now. Is the IDN working group recommending that "confusingly similar" only applies to variants or is it broader than that? >>RAM MOHAN: It's broader than that. >>CHUCK GOMES: Oh, it is. >>RAM MOHAN: It is similar -- in fact, what we are saying in six, limit confusingly similar strings, is we are saying it should be treated in analogy with the current practice for IDN SLD labels. >>CHUCK GOMES: So "confusingly similar" isn't just restricted to variants? >>RAM MOHAN: Right. >>CHUCK GOMES: Okay. >>BRUCE TONKIN: Olof? >>OLOF NORDLING: I think we need to qualify that. I think this is a subset on "confusingly similar" as we are talking about in five and six. It is a subset. It is not a definition of "confusingly similar" from an IDN perspective, but it's specifically dealing with variants and that they be -- >>BRUCE TONKIN: Use examples. >>OLOF NORDLING: Yes, all right. If a character is totally exchangeable within a script, we're back to where we were before actually, with the specific exception where we have, for example, a string in Chinese and where you have a string with simplified Chinese characters instead of the full-fledged Chinese characters. That's where you have the variants. At least there will be measures taken within the process here that they be regarded as confusingly similar to the extent that they cannot be taken by any other applicants. That's really where we are. So it is just adding precision to what's already there in the new gTLD process, Adding one little item. >>BRUCE TONKIN: This is just takes we can incorporate into the discussion under the recommendation we already have under "confusingly similar" for the new gTLD process. >>RAM MOHAN: Just to clarify, Chuck, we are talking in both five and six specifically about variants rather than generically across an entire string. >>BRUCE TONKIN: Cary? >>CARY KARP: There are a confusingly similar number of different ways to define what's confusingly similar, and I think we got confused on some aspects of that similarity. Ultimately, every single requested string is going to need to be assessed on the merit of the application -- >>BRUCE TONKIN: Exactly. >>CARY KARP: -- in light of whatever else it needs to be differentiated from. >>BRUCE TONKIN: Yes. >>CARY KARP: Some absolute definition of what constitutes adequate differences between two strings is only defined in light of the full crop of strings that need to be compared. >>BRUCE TONKIN: And also the relevant public is one of the concepts we have as well. Two Chinese strings might be completely confusing to me because to me I just say they are Chinese strings. I don't understand the difference between them, right? Whereas, someone in China can say, yep, that's a completely different character to them and it is not confusing to them. >>CARY KARP: I think we can expect that subtle difference to be -- we can be hoodwinked by it, that there can be degrees of subtly, however diligent we are in assessing these things, that we will ultimately discover, whoops, we didn't differentiate adequately. So yeah. >>BRUCE TONKIN: Alan? >>ALAN GREENBERG: I agree in principle. I wonder how implementable it is. If there are 30 Chinese strings, you can easily run down and say does this one have the same meaning as some one but using a simplified character string. When there is 30,000 of them, it is not clear there will be an automated way. >>BRUCE TONKIN: It is not an automatic method. >>ALAN GREENBERG: The question is -- >>BRUCE TONKIN: It is a complaints process. So we are basically saying -- It's posted and you go, Gee, that to our community is confusingly similar to that and then basically you would have to explain and provide enough evidence to merit -- >>ALAN GREENBERG: If it is complaint driven, it is acceptable. If we have an obligation to verify first, it is impossible. >>BRUCE TONKIN: Olof? >>OLOF NORDLING: Add a little flavor to that, because the applicant himself, being very cognizant of the script he is using for his particular string and knowing what character variants are applicable here, that at least as he will indicate those variants in the application. I think that's useful, in order to make certain they're not being, by oversight, handed to someone else. >> Unless the applicant has a vested interest in us not noticing the similarity. >>OLOF NORDLING: He might have, of course, overstate his claim so, hence, the need for some kind of checking of the -- >>BRUCE TONKIN: of the claim. I know what you are saying there. What you are effectively -- it is a method of blocking, I suppose. You are saying, I don't want these other ones to be registered so I'm going to claim that they are confusingly similar. That wouldn't be binding in any way. That's just information. Okay. How are we going? Ram? >>RAM MOHAN: Thank you. I think I will need to speed some of these up. But you are actually going to hit a few others areas that is going to spark -- >>BRUCE TONKIN: Hold on one second. Yes, go ahead. >> (inaudible). >>BRUCE TONKIN: Okay. So the methodology for "confusingly similar" would be a complaints process and we would use a dispute resolution provider that engages appropriate expertise to do that. So we would basically have people from that language community on that dispute resolution provider, just not ICANN. It is typically saying we go with a dispute resolution provider and that provider says, Okay, these are a Chinese language characters and the panel would be full of Chinese speakers basically. >>RAM MOHAN: Thank you. Number 7, it was discussion and agreement on priority rights for new gTLD strings and new domain names. There are really three agreements in there, and I have within parentheses there -- what we are saying there are three things. First, agreement that priority rights for new strings at the top level to not derive from existing strings at the top level. Second, that applications for IDN gTLDs may face challenges or objections. For instance, based on claims of intellectual property rights, that may not be the only way they are challenged. And, third, priority rights for new domain names do not derive from existing domain name strings as such but may, for instance, derive from established intellectual property rights. So, in general, what we're saying is that just because you have a name in a non-IDN TLD doesn't automatically give you the right to that name in an IDN TLD at any level of the strings. >>CHUCK GOMES: Question on that. How does the issue of -- if there are no priority rights, it seems to me that the issue of confusingly similar is going to come into play in the new TLD process. >>RAM MOHAN: Right. This does not obviate the confusingly similar. That still stays in place. We're just saying that so long as all the others exist, the issue of -- just because you have a given domain name in ASCII or TLD doesn't automatically assign you any priority to that equivalent, if you will, in an IDN string. You certainly can apply. You can certainly go through the process that is established there. And if there is confusing similarities, then the current process that already exists take care of it. >>BRUCE TONKIN: Okay, next. Sorry. Kind hard to see because I am looking through Tom at the moment. Go ahead, Subbiah. >>SUBBIAH S.: At the risk of revisiting something -- maybe I don't know enough on the note on 4.1.6 where it says "confusingly similar strings foreseen in the new gTLD recommendations", I'm not as familiar as I could be with the new gTLD recommendations except what I read. But what does it foresee to be specific as to what is confusingly similar? >>BRUCE TONKIN: Examples of confusingly similar? >>SUBBIAH S.: Yes, there are several levels. Are we talking about variants? >>BRUCE TONKIN: That's right. We are using "confusingly similar" in the way it is typically used in the international community. So in our report, we basically referenced a number of laws in different countries and how that's interpreted and the conclusion we've come to is that term, "confusingly similar," is widely used in a number of countries on this issue. And then if you read the report, there is quite a bit of detail in the discussion part. In fact, if you talk to Liz after this meeting, she can point to the relevant -- >>SUBBIAH S.: It is over and above just visually confusing? >>BRUCE TONKIN: Yes, it is. >>SUBBIAH S.: It is semantic. >>BRUCE TONKIN: I will not try to paraphrase it. If you have a look at the report, there is extensive text that gives you some guidance. >>LIZ WILLIAMS: I will answer your question. >>RAM MOHAN: Thank you. Number 8 was to approach aliasing as a policy matter. We have spoken about this just briefly before. But the specifics inside the working group was to suggest to the council and to others in the community to stop addressing aliasing in terms of a specific technical implementation or a specific technical approach because that gets, you know -- sometimes you get lost in the details, but to really focus on aliasing as a policy matter and to work towards any discussions on aliasing as a policy issue. The next recommendation or the agreement that we came to was to adhere to a single script when there is applications coming in for IDN gTLDs. And clearly we made a couple of exceptions that seem to be pretty standard. There is an exception that some script mixing may be okay with ASCII, and there are also other restrictions in some languages that use scripts. Script mixing might be a requirement and, therefore, you might need to add some restrictions. The actual text of this agreement is fairly long, but the summarization is, in general, following the IDN guidelines when you are applying and when you are awarded the IDN string and, in general, adhere to a single script unless you have a real good reason for not doing so. >>BRUCE TONKIN: So, basically, at the moment -- I just want to understand where this fits. At the moment, we are basically referring to the IDN guidelines and I would probably prefer to leave it at that. In other words, if you want to edit the IDN guidelines, you edit those rather than trying to incorporate those into our report. Is that fair? >>RAM MOHAN: I think that's fair. What we are saying here is that -- The IDN guidelines in some areas do not have the extra language that we've actually developed here in terms of where you might have exceptions and restrictions may come in. >>BRUCE TONKIN: That's fair. What I am saying is this work that you're doing, is it appropriate to go and do -- because the IDN guidelines don't really clearly deal with the top level either. I am sort of saying why don't we have a process to update those IDN guidelines rather than -- because that seems to be the appropriate document to capture all that, and then we just reference that. >>RAM MOHAN: Fair enough. >>CARY KARP: Point of clarification here. There are two action lines in the IDN guidelines queue that are both waiting to be informed from the present context and the IDF context. The one is seeing to it that the guidelines which are supposed to be applicable on all levels of the DNS are, in fact, applicable on all levels. We have been looking from the top level downwards. And the need for looking from the top level upwards, as it were, is recognized, and there is specific guidelines in the queue again to be put forward once this process has been concluded. And the other is second-guessing what the intellectual property revision is likely to entail and, if nothing else, recommending registries not to continue doing things that are likely to cause difficulty and to start gearing up for things that will become easier. >>BRUCE TONKIN: In terms of a process point of view, Cary, does this working group -- who is the editor, if you'd like, of the IDN guidelines? >>CARY KARP: Moi. >>BRUCE TONKIN: So you will send this report to Cary. I am just sort of trying to see. Someone has to update that document. I don't want to do that as GNSO. >>RAM MOHAN: I am a member of that guidelines group as well, happy to make sure it gets updated. >>CARY KARP: Preemptively, one of the things that needs to be clear, the guidelines maintenance group is IDN registries, sanctioned registries. And we are in this very awkward situation where ICANN has imposed a contractual obligation on its gTLDs to subscribe to the guidelines. The only thing we can do to bring the CCs on board is to make sure the guidelines are inherently appealing. The more GNSO authority that is behind that action, the more ccNSO resistance we are going to see. So this has to be the registries acting in tandem to create documentation that is compelling to registries. >>BRUCE TONKIN: when you are Using "registries", you are using it in the general sense? >>CARY KARP: The IDN registries. Well, TLD registries. >>BRUCE TONKIN: TLD registries. >>CARY KARP: TLD registries that support IDN are welcomed to participate in the development of the guidelines, and one of the key objectives in this is mooting this ICANN -- We can force it down the throats of the Gs, but we can't say anything to the Cs. I am waiting for some ICANN staffer to chime in with the litany here. >>BRUCE TONKIN: It is a little bit more complicated than that because at the moment -- I'll accept that argument at the second level. At the top level, I would say certainly these things like the IDN guidelines, in anything that you add to the root, is a new TLD essentially. I think if we are basically saying to add something to the root, you need to adhere to those guidelines, I think that's a reasonable recommendation from the GNSO essentially. >>CARY KARP: We're waiting to incorporate this into the guidelines because we know the ccNSO/GAC is busy considering this issue, and we know the GNSO is busy considering this issue. And the last thing -- literally, the last thing you want to do is make it seem as though we are preempting that process. >>BRUCE TONKIN: Yeah, exactly. >>CARY KARP: This is just a point of information. We are fully cognizant of the need for doing this, and I am explaining why it is that we haven't done it yet. >>BRUCE TONKIN: Yeah, okay. So you agree with the process. It is just the timing of it. >>CARY KARP: Yeah, absolutely so. We cannot, as I say, appear be to in any way assuming that we have policy ascendency over the policy development processes. >>BRUCE TONKIN: Understand. Okay. Ten? >>RAM MOHAN: Ten is pretty straightforward. What we agreed to was that we feel the UDRP that exists today is sufficient to handle new IDN gTLDs, and new dispute resolution procedures and legal procedures are not likely to be needed in considering IDN gTLDs. So that concludes the set of agreements that may lead to policy development for the council. I have a couple more slides, and what I wanted to do in those slides was to merely point out a few areas where topics got discussed. We likely don't have a great deal of time here to discuss every one of those topics, Bruce. I think it is relevant -- >>BRUCE TONKIN: So where do you want to go? >>RAM MOHAN: I think it is relevant for this group just to hear some of the other areas of thought that got discussed. I am just going to go through all of these one by one and then, perhaps, you can do one set of questions at the end. So area of support, promote public awareness of IDN gTLD applications. You already talked about that. There be some sort of an advertisement, if you will, of the fact that there are -- there is a process for the application. there was also support for a concept to prioritize scripts or languages in the IDN gTLD launch according to the demand or need and one notion would be distance to ASCII. For example, give priority of right-to-left scripts. There is also a significant amount of support to avoid further entrenchment of the usage of keyword solutions. In other words, solutions where a single string under the wraps then translates to a real ASCII string, but the string that is represented is called a keyword and it is just in the local script. There is also support to treat existing gTLD registries equally in cases when they apply for IDN gTLD strings. And there was an alternative view presented, which is to consider preferential rules for existing sponsored gTLD registries, particularly because they -- in the sponsorship agreements, they had to establish global relevance and global support. On to the next slide. The support for providing preferential treatment of applications for particular communities in need of IDN gTLDs. And one example might be to lower entry barriers such as financial barriers, but there was clear agreement across the board that adequate levels of service to the relevant communities should be maintained. There was some discussion in the working group that not only should -- that lowered entry barriers should not be merely financial entry barriers, but also technical barriers or technical performance standards should also be lowered in some these communities. There were two -- three alternative views, which is to prioritize according to number of potential users of the gTLD in IDN, to resolve policy before developing any priority criteria or to just follow the approach of new gTLD recommendations and have no priority provisions whatsoever. Finally, we had some other areas of support. We had support that said that "confusingly similar" should really be considered as visually confusingly similar or typographically confusingly similar, not phonetic or how it sounds or things like that but to really limit confusingly similar to how it looks or how the typographic representation is. There was also support for considering IDN issues for the extension of reserved names list by introducing a new notion of reserved concepts. So the example that was used was the fact that today in a number of -- in fact, in every gTLD registry agreement with ICANN, the word "example" is reserved even though it doesn't have necessarily an intellectual property right associated with it, but there is real relevance there. And I think, Chuck, in your reserved names working group, you have already covered this. As I had mentioned before, there were two quite polar points of view on aliasing. One was that aliasing provides protection of and reduces confusion for existing domain name holders. There is also recognition that there may be disadvantages of using aliasing, and there was a polar point of view which is aliasing in no way eliminates any confusion and aliasing as such should be completely struck from any set of potential solutions in introduction of confusion. So these are some extracts. There are many -- there are about 15 more support statements that are in the report that I will just direct you to, but what I have done here is pull out some of the major areas where there was significant -- there was definitely a lot of heat and, in some areas, some light as well. >>BRUCE TONKIN: So I just wanted to take comments on those generally. Chuck? >>CHUCK GOMES: This is a pretty broad comment, but as I was going through these in your report and, again, listening to you now, one question popped up many times and that's how. A lot of these things really seem very challenging to accomplish in an objective way. Did you pursue that at all in some of these things? We don't have time, I think, of the specific ones I have questions for; but maybe at a high level, could you respond to that in terms of did you really talk about -- are some of these things even implementable? >>RAM MOHAN: Yeah. In some of these areas, we actually did come up with some implementation methodologies; but in many of these cases, we did not include them in the report because, A, we ran out of time and, B, we were trying to keep it brief. But in a number of areas, we did come up with specific ways of implementing some of these areas of support. One of the problems, Chuck, was that almost none of these areas actually -- there was at least one significant set of individuals, members of the working group, who were completely opposed or who did not feel sufficiently moved to support this and take it up -- elevate it to an agreement. >>BRUCE TONKIN: (inaudible). >>RAM MOHAN: Thank you. I understand we are short of time and have a whole long list of items we have to cover. Surely, I think it should be important enough for this IDN working group, of which I am one of the representatives, to seriously consider those IDN TLDs that have already been implemented, preexisting for a fairly long time. Some of you may know, some of these deployments date all the way back to nearly ten years ago when we first started. (inaudible) will know. He is seated over there. It is nearly ten years now that we first -- when I first launched the first IDN deployment in the Asia-Pacific. And, suddenly, last year China sort of came out, and be glad they actually have been implementing preexisting IDN TLDs for a long time. So surely the IDN working group should address this key point because we are coming out with our recommendations. If we don't consider this point, as at least an alternative view, then we are going to run into some international, furore if this goes out any higher. So I think we should spend some time on discussing what are we going to do with preexisting TLD. Last year I did a survey and we looked at all the countries that are known to have deployed IDN TLDs and assess them on how long they have been doing this and what sort of strings they have been registering, test beting, whatever you want to call it and whatever they want to call it. It is interesting to see that there were not that much IDN TLDs that were confusingly similar because, more or less, all of these different groups in different countries like the (inaudible) Arabic group or the Japanese -- sorry, the Koreans or the Chinese, all understood they should not put out strings that were confusingly similar to others. Especially of note is the Chinese/Japanese/Koreans share a single script, and that script is the Han Unicode, unified Unicode character set. Therefore, they have been very careful in the past, especially -- we knew about this because the unified code for Chinese has been around for some time. I mean, Chinese Han characters, which are also used in Kanji and Hanja. And they have carefully avoided this by making sure they group together in language communities that actually address the use of avoiding the collisions at TLD levels. I think all of these preexisting TLD deployments should also be taken in consideration before any report goes up any higher. Thank you. >>CHUCK GOMES: Bruce, can I respond to that or at least ask a question? >>BRUCE TONKIN: Just let me -- just let me -- I saw Marilyn's hand up as well. Anyone else wanted to comment? >>CHUCK GOMES: Okay. You got another couple other hands, too. To do this, it seems to me we have to go back to the history of introduction of new TLDs in the very first round. The very same issue was raised with regard to ASCII gTLDs because there were some proposals submitted where they already had a TLD in existence and an alternative root or whatever. And I think this is going to be a very complicated area. It is probably going to come down to general counsel advice with regard to this. But how do you do it for IDN -- existing IDN TLDs when it was rejected -- any priority was rejected for bidders in the ASCII world? I don't have an answer, but it is a serious issue that I think we will confront in this regard. >>BRUCE TONKIN: Marilyn? >>MARILYN CADE: I have an interest, I think, in being sure that we are trying to do what is technologically feasible and reasonable in understanding any legacy situation as we move forward at ICANN. But I think there also -- it is very important for us to be realistic about what can be accommodated and what might present just too many technical barriers, even though there are political issues to -- I'm not exactly sure that I see the ability to be completely compatible in a backward way to legacy systems. So I need to have a better understanding of what the suggestion is and what the -- and whether there are not only technical solutions but political solutions. By "political solutions" there, I mean to use the term to include the need to continue to educate and broaden and deepen the understanding of what's technically feasible and realistic and pragmatic to accomplish. I'm not sure right now that I feel like I completely have that. >>BRUCE TONKIN: Subbiah. >>SUBBIAH S.: To address Marilyn's point of view, I think a number of people in the room can suggest that pretty much all prior -- other deployments very much follow the IDNA standard. There are minor differences, but pretty much everyone follows the IDNA standard. I think that's a reasonably fair statement, 99%, 98%. Whatever changes are minimal. I mean, One example is -- even the Chinese didn't know for a long time when they launched their system over 100 million people essentially can resolve these things in China, Internet users today. And it turned out that sometime after they had launched a few years ago, Tisculli (phonetic), which is a European ISP, one of the larger ISPs, maybe 10, 15 millions users -- I don't know -- has already been resolving it, pointing to the Chinese one and doing it. That's all possible only because even the Chinese have been pretty responsible and have launched it using, more or less, the same set of IDNAs pretty much everyone had. I think in 4.2.8, I think, one of the support statements a group of people supported was for the view to consider input from local, regional preexisting developments regarding IDN at the top level and it does mention, for example, the system supported by 22 Arab League countries that have actually patched their monopoly ISP -- several countries have patched a number of years ago their monopoly ISPs. These are the only ISPs in the country, and they have been patched and also the ccTLDs. The ASCIIs, they've patched it and been operational for a number of years in experimental systems. So they are all following, more or less, the same thing. The point here is that what is being suggested is that at the time that particular gTLDs, at least of this support group -- suggest that they should be considered that you should at the time of applying for gTLDs, one should consider what has already happened in the communities or wherever it is and take that into account before a decision is made about moving forward. Of course, if it so turned out that people had done it before, so it turns out -- there are accommodations so this can happen. At that point, there is a (inaudible) 1% different or 2% different, of course, they will think they will get it in the end or whatever. Through an application process, they'll have to switch Whatever minimal thing they are not following. I think that's one thing. And the last thing I wanted to bring up is, as Chuck says, this is a complicated issue because people have already done it. And the reason people have done it is that ICANN did not spend a lot of time the last eight, nine years actually dealing with it. That's why we're here. So I think it is the responsibility of whoever is going to coordinate this thing so finally everybody is working peaceably. Whoever steps up to do that has to take into account what happens and make up a deficiency from the task. Otherwise, you will see things like -- I understand -- if I had my own involvement in this way, Korean government essentially made a suggestion that they wanted to be to able to some day to put in the gTLD process, approving the strings. That's an alternative in this. But people have (inaudible) coming to the meetings. The point is that if you want to move forward (inaudible), one has to take into account what happened before and will have some solution in moving forward. It won't be easy. It has to be addressed. >>BRUCE TONKIN: Okay. Werner Staub. >>WERNER STAUB: I think in this context, the primary concern is not to extend the duration that it already has taken for a given patched IDN solution that is uncontroversial in the respective community to become one that actually resolves universally. Not in the sense that there should be additional controversy about who should get a string, even though in some cases, for instance, the Chinese case of the Chinese.net and the Chinese.com, which would be (inaudible), the two of them, of course, of course, it would be unconceivable-, inconceivable to say, somebody else than this very large number of registrants would be able to take this because it is -- it has a relative importance that is so great. And it is essentially just is a matter of making it something that works out because the community has needed it. In the case of the Arabic domain names, the same thing. I think it is a debilitating situation when the national language cannot be really comfortably used in the -- for domain names. When we have a process that would actually further impose unnecessary process on them, then, of course, that's even more unfair than what they have already had. It should be in the sense of making things faster for the resolution of things that have a priority. >>BRUCE TONKIN: Ram? >>RAM MOHAN: Thank you, Bruce. The working group had some robust discussions on this topic. These have been called experimental systems here. They are also commonly called alternate root systems, proxy systems. Two specific areas came up for discussion. One was to find a way to consider input from these experimental alternate IDN root operators. The secondary that came up for discussion was to find a way to not penalize; in other words, to incorporate or, perhaps, even grandfather alternate IDN root systems into the current system which, as you all know, has implications from the TLD root level through to the registrar and registrant level. We know today some of these strings offered in other languages or scripts in these experimental or alternate systems, they result in users thinking that they're offered -- that these strings are offered by the current ASCII gTLD registry and they have asked that current ASCII gTLD registry for support. I think there is some demonstrable user confusion and, perhaps, even user harm. As for conforming to standards, I would suggest that we not -- we should not look at the narrow -- at a narrow interpretation of conformance as whether a given representation by an operator conforms to IDNA. Rather, I suggest that we should look at the broader and perhaps more important issue, which is does an IDN gTLD or an IDN TLD resolve globally, uniquely everywhere without some DNS tweak, without some ISP involvement or some software that has to be downloaded onto software applications. I think that is really the responsibility that we have to the Internet community and to the users, and I think that is where we have the requirement to ensure that some real harm doesn't get done. Thanks. >> Forgive the question that maybe was addressed long ago. Is there any statement anywhere saying our intent is to try to get rid of the alternate roots? That is, to facilitate incorporation of them? Or do we honestly believe they will live forever? >>RAM MOHAN: In fact, in the working group, we had strong discussion on this and what we actually came down to were multiple sets of perspectives that have all been faithfully -- attempted to be faithfully reproduced in the document. There is no recommendation coming into the council or to ICANN on this front. >>BRUCE TONKIN: Marilyn. >>MARILYN CADE: Thank you, Ram, for that discussion. I am going to actually refer to what I think is the mission of ICANN, but thank God there is an expert in the room that I can turn to and I am looking at him now. [ Laughter ] If I don't like your answer, then I will go to him. Sorry, for those on the phone, we were having a little exchange of whether I was talking to Dan Halloran, the assistant general counsel, or to Bruce Tonkin. I was referencing Dan. I believe -- and, perhaps, that's because I've just reviewed and renewed my recollection of ICANN's mission as a member of the President's Strategy Committee that actually ICANN has a mission to support a single authoritative root. But not to -- I don't think that we would be suggesting that intentionally this working group is doing anything else, but that we do have a mission at ICANN. And I think we have to examine what's within our scope at ICANN and what might exceed that scope in terms of our ability to extend into other areas. Dan, might I ask you to comment on ICANN's mission maybe? >> Dan Halloran: One thing I would point to -- I haven't been through the whole report. I hate to just go off the 4.2, 8 which seems pretty harmless. It says we should consider taking input. Of course, we will take input or we will take into consideration anything. We are not going to refuse to take into consideration. But we do have, going back to the mission, we have an ICP3 -- I don't know if it was referenced in your report, but it is a statement of ICANN's approach to that -- or a statement of ICANN's policy. It, I think, says in black and white we have no current policy that allows us to give preferential treatment -- it goes into experimentation and all different reasons why people might be introducing alternate roots. The current policy is there is no way to grant preference to those experiments or whatever they are. And so that's the current policy. And if you are just saying, We will take these into consideration, that's fine. If you are intending to change the current policy, that's something that should be called out. Whatever it is you are doing in the report should be clear about that. >>MARILYN CADE: I'm just going to make a follow-up comment. When you use the word "policy" there, you are talking about ICANN meta policy as opposed to GNSO policy. Is that not right? >> Dan Halloran: Correct. >>RAM MOHAN: Dan, from the working group, what you will find is a reproduction of the discussion that has happened. I think the important thing for ICANN and the council to take in mind is that what has often been referred to as the elephant in the room is actually there in the room. >>BRUCE TONKIN: Tina. >>TINA DAM: Actually, Marilyn and Dan kind of said together what it was that I wanted to say. Maybe just one addition to it, and that is just because ICANN has that mission, it doesn't mean that we can't take a look at what has happened other places. It just means there is no preferential treatment of it. We're open -- the ICANN community is open in pretty much all of their Supporting Organizations and working groups, and so participation can take place. And one of the reasons why we didn't have IDNs ten years ago was, for example, there was no policy. There was no technical standard from the IETF. All of that, of course, is being worked on and it is something we all should work on it together to make it work the best way possible for everybody >>BRUCE TONKIN: Just comment where I see this fitting into our current process. There is two approaches here. The first approach is that somebody that was operating an experimental root chooses to apply for a string that matches that. That would go through the normal application process. And if that were the only applicant, and assuming it get through all the steps, that would be fine. If, however, two people applied for exactly the same string, then it goes into our contention resolution process. And one of the elements of that contention resolution process can be some comparative evaluation, I guess of the relative merits between the two applicants. It wouldn't be a merit based on the fact that they technically have an alternative root. It would be based presumably on technical competence and a whole range of other things that could choose between those two contending parties. The other approach that can be taken is if one element applies -- and so it is just the one application -- this is not a contention issue -- but the operators of a substantial part of the Internet infrastructure in a particular region or application providers in a particular area believe that there would significant technical impacts on their system, that's dealt with by the technical stability clause. It is fairly similar to the examples I was giving yesterday under technical stability. Like, if I applied for dot doc or dot exe, they are offering proprietary file formats of particular operating systems. But when you look at the number of users and the impact and creating something like dot exe, there is no Internet standard on dot exe but it is used by a lot of software in a lot of systems. That could be a reason not to add it to the root, which is a very different thing to giving some kind of preferential status of adding it in. You are basically just meaning that on that basis, it would become reserved. It would not end up being added to the root because the issue is it would cause stability with widespread other systems. I am just giving some alternative flows through our current process, but I am not hearing anything that, I guess, inclines me at the new gTLD level to change our current processes. We are not giving preference to anything, but we are taking into account via either the comparative evaluation process, the relative merits based on that process if there is contention; or if there is a sufficient claim made that something would cause a technical instability on the Internet, then that would be evaluated on its merits as well. That's how our existing process would deal with that situation. Alan? >>ALAN GREENBERG: Just as a point of information, does anyone have a number of how many alternate root TLDs there are? Are we talking about five Chinese and six Arabic or 2,000? >>BRUCE TONKIN: Also, you are talking IDNs or ASCII? There are already thousands of ASCII. >>ALAN GREENBERG: IDNs is what I am talking about at this point. >> The answer is there are many. I can respond to that as well. >>BRUCE TONKIN: Go ahead, Subbiah. >>SUBBIAH S.: (inaudible). They were not able to make it because there were time changes on the meeting last minute. (Inaudible). >>BRUCE TONKIN: So, Subbiah, if you can go to some of those specific examples, are they typically names representing countries or are they basically trying to copy the existing hierarchy? What are sort of examples? >>SUBBIAH S.: (inaudible). >>BRUCE TONKIN: So there is no common element there? >>SUBBIAH S.: I think there is a common element. They have got the Chinese equivalent of the country, and they also have TLDs as they mentioned. >>BRUCE TONKIN: What's examples of ones? >>SUBBIAH S.: Chinese (inaudible). >>BRUCE TONKIN: I am asking for the examples. What I am trying to understand, is it just basically copying the hierarchy we already have? So you're basically -- the hierarchy we already have is com, net all, biz, info. >>SUBBIAH S.: I believe -- for instance, I believe there some that have been others. Not necessarily -- >>BRUCE TONKIN: But the equivalent of dot sport or something? >>SUBBIAH S.: Yeah, but I think there have even been ones that in the past -- I don't know how successful, that were now that were not actually any string -- a string that would make sense for that community but not something that was (inaudible). >>BRUCE TONKIN: But would it be a true statement that in terms of volumes of registrations -- >>SUBBIAH S.: They would defer dramatically. >>BRUCE TONKIN: Hang on. Listen to the question. In terms of registrations, would you say they are predominantly related to the name of the country? >>SUBBIAH S.: No, not necessarily. Not necessarily at all. I think it is just a hodgepodge. In the case of -- but then it is also who is backing it. In the case of the Arab countries, it is the Arab League and the monopoly ISPs that are attached to that country. Even if there are not too many registrations in small countries and the authority behind it. >>BRUCE TONKIN: I am trying to understanding what the potential constraint conflict is because some of this is going to come through -- the country bit is most likely to come through the ccNSO process, I think, and they will obviously look at some ideas around that. If it is around existing TLDs, like com, net, org, et cetera, then that is dealt with in a couple of levels. There is confusingly similar. There's the technical problems and there's evaluating two applications. I think basically it has to flow through our pipe. >>SUBBIAH S.: I do not disagree with that. My issue, my point is simply if we are, finally, going to do something about this and make it a global coordinated thing for the betterment of mankind -- really that's what it is here -- then we do need to address -- we need to be in a position where if this is the group of people that are going to decide simple answers like who has done it before or whatever, right, it should be known by people making that decision. As Demi just pointed out, last year he made a survey. He was on the Web. It was presented at ITU. That's why he did it. They called him to give a speech and he did it. So the fact is a lot of work has gone before. What you must ask yourself, what happened to Chinese here? They used to be here all the time. They used to be here, 2002, 2003. Bruce, you know that. They were here all the time. Why are they not here? They are not here because they've got what they wanted. There is nothing more to speak about, right? So the reality is if we want to solve this -- Some of us have been here for ten years, we invented it. We're all here. We're here -- Chuck is still here after having lost millions of dollars back in 2000, okay, with IDN.ASCII launches and so on. We're all still here. We want to -- we wouldn't be here if we didn't think this would be a process to make it happen. The other thing is after having -- Like Werner, I want to get this as soon as possible out. I want to get it out of my hair. I spent too much of my life on this personally, okay? (inaudible). A lot of these people have just walked away. One of the engineers who came on board for one of the companies, I won't mention -- happens to be one of our students. He got on to the IDN way recently because he is (inaudible) in the new company. His first comment to us privately was, I thought we had all these discussions in Asia and thousands of people running around, hundreds of people back in 2000, 2001, 2002 and there was a lot of interest, but now it is all western voices. Where are the voices (inaudible). Not here. It was somebody else on the GNSO council. Today we are nodding again. This is not what we should be doing. We should involve these people. Here is an opportunity to make it happen. I, as much as Werner, want to do this as fast as possible. But then we hear a comment that we are not able to reach these conclusions or we couldn't discuss a few things because we had a 10-week period to quickly make a decision and move forward very quickly. I understand we do want to work through all these issues and get it done. We don't want another ten years. We still -- we are not trying to do it too fast as well, perhaps. We need the participation because without the participation, there is no legitimacy. That's the fundamental thing here And, unfortunately, it falls on a couple of guys who helped invent this back in the past to stand up here and talk about it. The communities themselves either have done it or don't know are not here at some level or have done it, whatever. Why is it for us to be here? We're here because we invented the damn thing and we thought it would help the poor people of the world. That's why we invented it. We didn't invent it because we thought it would help sort of the Western world first in some ways. That's not why we invented it. We wanted these language things to be in the countries themselves. Applicants come from the countries. The country themselves come up to apply, registries and so on and it is the developed world assisting them to get control of their own languages. I think that's why we did this. That's why we're here. If it doesn't work out that way, well, then, too bad. We wasted part of our lives and that's that. >>BRUCE TONKIN: Tina? >>TINA DAM: Thanks. Just really short, Subbiah, I hope you recognize and realize that some of the new Latin voices that you refer to that are here compared to who was here ten years ago, I was not here ten years ago so I must be one of the new ones at least. And there are more people in the room that are new as well. Are here also because they believe IDN implementation has not happened fast enough, and that's what we are working and trying to do. >>SUBBIAH S.: (inaudible). >>TINA DAM: I want as many people involved as possible, anybody who is interested to be involved as possible in all the different sessions. That's what we have been trying to do with the workshops and the working groups and so forth. I don't think there is anybody in the room who disagrees with that at all. I think it is generally understood. I at least know from ICANN staff, that that's understood. >>BRUCE TONKIN: Okay. So for the final word on this, I will hand it over to Ram and then I want to start the WHOIS discussions. >>RAM MOHAN: Thank you, Bruce. I guess there are three parting thoughts that I have for you on the council and everybody who is observing. First, clearly, the IDN working group, its work is complete now. We have published a report, and there are specific items for you to consider and for you to go forward on. Clearly, IDNs themselves are important and have relevance going forward and that's something all of you already know. The second part I would like to leave you with is that -- is to exhort you to not look at IDNs as a Western versus Eastern versus Oriental-type of a thing but to really understand and to really incorporate into all of our minds that what we are trying to do is to internationalize the domain name system. And in so doing, we need to be as representative as possible and consider inputs from as many places as possible. But I would exhort all of you to look at this in a collaborative way, in a cooperative way, and really not to try to frame IDNs and the implementation of IDNs as an East versus West or, you know, left versus right-type of a divide. I actually don't think such a divide exists. When you bring together people who are interested in implementing IDNs and you put them in a room, pretty much everybody is pulling in the same direction. Everybody is trying to find a way to get IDNs implemented. So let's keep that higher goal in mind rather than talking about who was there or who was on first base or who is going to be there at the very end. In fact, at the end, we all want to be together in implementing a solution that is globally responsive, that actually is unique, that doesn't cause confusion and that is a system that adequately represents the peoples and the languages of the world. The last point, and the last thought, I had for all of you is on the technical side, much of the work has been completed. There is some little pieces of work that still remain but much of the work has been completed. There are a few other areas where IDNs are going to be studied. The Security and Stability Committee is about to undertake a study on IDNs to focus on what, if any, are security and stability impacts for the implementation of IDNs. There is not a presupposition that there is an impact but, in fact, there is a need to actually perform such a study and ensure that there is not a security and stability impact. So the last piece of advice and some thought is please work together to develop policies that are implementable, take into consideration some of the areas of agreement and support, read all of the areas of support. Not all of them are invalid. But let's move forward together as a planet that speaks multiple languages and, yet, attempts to communicate to one another and let's work together with that as a basis. Thank you. >>BRUCE TONKIN: Thank you, Ram. Okay. Yes, Sophia? >>SOPHIA BEKELE: Thank you. I just wanted to add something on what Ram said. I completely agree with you, Ram, on your last thought about giving advice for the council regarding looking at IDNs as sort of a blanket implementation of sort of a technology and a concept versus actually I don't believe in it being divisive from the perspective east, west and developed it and so forth. I really think the policy -- the reason we are developing policy for IDNs is to actually service the people who speak more than one language. It is a language community we are looking at. That's usually in the developing economy as well as, of course, there is the (inaudible) in the developed economy. I really think the mind-set should also be in a position to sympathize, empathize with the group that are actually going to be benefitting from here. That includes, for example, things like the financial and technical criteria as we develop policy. So we can't treat IDNs as a product, as a technology that is going to be implemented by the group that has the capability to implement. So this is not a chip they're we're developing at Intel that is going to be implemented in various PCs to service thousands of people. This is not an invention of technology. This is a technology that is supposed to provide benefit to third-world countries, people who speak more than one language. You know, there is even a saying, this is not -- you know, as a humor, tell me who speaks one language. It is an American, okay? So I don't think we should frame policymakers' minds to think of IDNs as a technology. That's what I am saying. I think we need to think of it benefitting the other group. That's the only way we could structure policy properly. Otherwise, we don't need to do policy. We just develop a technology and implement it for who can develop the technology and give it to the people. Thank you. >>RAM MOHAN: Thank you, Sophia. Actually, I am an American and I speak about seven languages. What I was really saying -- I think the general concept is let's try and make sure that when we talk about IDNs that we debate about inclusivity across the board, not -- Certainly, I think third world and developing nations need a place here, especially because they have been underrepresented. But I just want to make sure that we don't skew the debate towards only thinking of those populations because really our job is to look at IDNs as a worldwide, global thing that we have to do for all language communities across the world, rich or poor, West or East. Thanks. >>BRUCE TONKIN: Thanks, Ram. I would like to -- >>SHAHRAM: May I have a comment? >>BRUCE TONKIN: One final comment. Go ahead. >>SHAHRAM: Thank you. Regarding what Ram says, I want to clarify that I agree with him. There is no wall between the West and East and other things that he says. But please note that what we want to do is to prepare a good infrastructure for the IDNs. This infrastructure can be done only if we look at all the aspects that can be responsive -- that can be -- that can offset the IDNs. And I think much of this aspects are the linguistic -- very little issues that only linguistic (inaudible) officialists can do this. So what we are going to do right now is not to decide for all the people in the world. We are not (inaudible) with all the languages. What I want to say is that we should hear everyone. We should hear every specialist in the world in his own language. This is what I wanted to do -- to say. Thank you. >>BRUCE TONKIN: Okay, thank you. I would like to thank all the members of the IDN working group for all the work they've done in this short space of time and for Ram's efforts in chairing that working group. And just make a comment that I'm an engineer and I barely speak English. [ Laughter ] What I would suggest we do is reconvene at 12:30 to talk about WHOIS, so allow people a chance for a bit of a break. Reconvene here at 12:30 for the WHOIS discussion. |
GNSO Working Group Transcript
Last Updated:
Date