IDN Workshop - New Delhi

From Wiki
Jump to: navigation, search
  • Reformatted from here

IDN Workshop
Monday 11 February 2008
ICANN Meeting
New Delhi, India

CHRIS DISSPAIN Ladies and gentlemen, the next session is the IDN ccTLD seminar. We're going to start in about five minutes. Ladies and gentlemen, please take your seats. We're about to start. Not loud enough. Yeah. Ladies and gentlemen, please take your seats. We're about to start. Thank you.
MANAL ISMAIL Good afternoon, everyone.
YOUNG EUM LEE Yes. Good afternoon. We are about to start. And Manal here will be starting the session. Thank you.
MANAL ISMAIL Okay. Good afternoon and welcome to the workshop. My name is Manal Ismail. I work at the telecom regulatory authority of Egypt. I'm the GAC representative of Egypt, and I also cochair the IDNC working group with my colleague, young Eum.
YOUNG EUM LEE Yes. I'm currently the cc representative, and the CC chair of the IDNC working group and today we are going to have a session on what the working group is doing, where we have -- where we are, and we would like to introduce you to the draft, the contents of the draft, and maybe have an open discussion about the draft.
MANAL ISMAIL Okay. As you may all know, the IDNC work group was created as per a board resolution in L.A. to develop and report on feasible methods that would enable the introduction of a limited number of IDN ccTLDs while the overall policy is being developed. The purpose of today's workshop, it's more of an open microphone public consultation to receive input from all relevant stakeholders on topics that need to be dealt with under the fast-track approach. I would like to stress the fact that your input and feedback during this consultation is most welcome and will definitely assist the IDNC working group to define the topics that need to be addressed during the first -- the fast-track approach. I think it's time to get into substance.
YOUNG EUM LEE Let me just tell you how the working group was formed, what it has been up to. The working group was formed in October of 2007 because the cc's were going through a PDP with IDNs, and it was realized that the formal PDP process would take an extraordinarily long amount of time which would not be acceptable to most of the ICANN community, and so we've decided to come up with a working group to work on a fast-track approach to the IDNCs. Our working group is composed of members of -- from the cc community, some from GAC, GNSO, ALAC, SSAC, and the technical community. And as you all know, we have published an initial draft for public comment in the 1st of February, and we would very much like your input on the content of it, and to help you speak your mind about it I think Bart would like to -- would be introducing you to some of it, and to introduce Bart to you here is Chris. Thank you.
CHRIS DISSPAIN Thank you, Young Eum. Good afternoon, everybody. No, there's no power here. Okay. I'll use this one. I would if it was turned on. Yeah. Thank you. Hello. Ah! Excellent. Good afternoon, everybody. I feel like a game show host! My name is Chris Disspain. For those of you that don't know me, I am the chair of the Country Code Name Supporting Organization, ccNSO, and the working group chairs, Manal and young Eum, asked me if I would facilitate this workshop, which I'm happy to do. For those of you who -- for whom English is not your first language, there is a translation of this -- of the draft initial report, which is what we are discussing into a number of languages, and it's available at The agenda for today is fairly simple. We're going to introduce and explain the purpose of the initial report. We're going to highlight the individual topics or issues in the draft report. Everybody will have an opportunity to raise any additional issues and topics that they think should be included. And we're going to canvass opinion about possible answers or methods for dealing with each of the topics. But no one up here, apart from me reading out the basic questions in the report, is going to be doing very much talking. Hopefully you are going to be doing most of the talking because this is part of the public consultation process that the initial report goes through before becoming a final report. You'll see up on the slide that it says we're going to talk about individual topics or issues and there will be an opportunity to raise additional ones. If you have a problem with a particular word in a question or if it you think a different word should be used or it should say "and" instead of "if," et cetera, those inputs are very relevant but can I ask that you do those by e-mail. Because if we spend all of our time this afternoon discussing whether there should be an "and" or an "if" or a "but," we wouldn't actually get to any substantive issues. So if you have textual -- if you have changes that you want to make that are about the use of particular words, et cetera, please make those by comment by e-mail. Before we start with the initial report, the chair of the Government Advisory Committee, Janis Karklins, has -- would like to read a statement. No? After the introduction? Okay. Fair enough. He will do that later. Okay. What's the purpose of this report? Like all processes in ICANN, we have designed one that is extremely difficult to understand and has lots of words beginning with "I" in it. Initial reports, interim reports, et cetera, et cetera. The purpose of the initial report, of which this is the first draft, is to inform and report on the topics and issues as identified by the working group that need to be considered in developing each of the two mechanisms which I'm going to talk about in a minute, and to seek input and comment on them. However, please be aware that the working group itself is still commenting on this draft. So this draft does not come signed off as a document by the working group. It comes as a first draft for everyone's comment, including members of the working group, and I expect that we'll be hearing from a number of members of the working group this afternoon. The final initial report, which will be put together after comments from the community, will hopefully solidify the topics that need to be dealt with in the fast track and will also explain their relationship to the policy development process. Just so that everybody is clear, what we are discussing today in this initial report is a fast-track approach to see whether it is possible to introduce a small number of IDN ccTLDs whilst at the same time there is a full-blown policy development process running to work out what the policy for IDN ccTLDs should be. The next steps are that the interim report will propose potential mechanisms, so we're going to go from this report and a final version of this report to an interim report, and in that interim report we're going to propose potential mechanisms. We hope to have that report out for consultation by the 28th of March, and we hope to have a final interim report by the 16th of May. And then we leap to the final report, which is where the working group will actually make -- hopefully make some recommendations. And the goal is to publish that by the 4th of June, and to discuss it and finalize it in the Paris meeting of ICANN. The way it works is that the working group will make -- hopefully will reach some conclusions and make a series of recommendations. Those recommendations in its report will go to the ccNSO and to the GAC, and only if the ccNSO and the GAC both reach consensus that the recommendations are workable and acceptable will they go to the board. Okay. The overarching principles under which this working group operates, that we have a requirement to preserve the security and stability of the DNS, so nothing that we recommend, nothing that this working group recommends should interfere with the security and stability of the DNS. Secondly, we have to ensure that any recommendations that we make complies with the IDNA protocols. Thirdly, we have to take input and advice from the technical community in respect to the implementation of IDNs, and, indeed, we have a representative of the technical community on the working group. And finally, we have to take into account current practices for the delegation of ccTLDs. We cannot come up with some sort of mechanism that is completely against the current way that ccTLDs are delegated. The fast track relates closely to the policy development process because the fast track cannot be allowed to preempt the outcome of the policy development process, so what we have to try and do is to design a fast-track mechanism that allows for IDN -- a small number of IDN ccTLDs to be delegated in IDN scripts, but does not, by doing that, create assumptions about what the final policy will be. All of the issues and topics raised in respect to the fast track are also raised under the PDP. And solutions reached have, of necessity, to be as limited as possible because if you -- if we were to -- the best example I can use -- and I just want to say this is just an example at this stage -- if you accept that a thing called an IDN ccTLD can exist, then clearly the minimum number of IDN ccTLDs that a territory could have is one. Any more than one may create difficulties because it starts to interfere with the full-blown policy development process, which has the attitude aside how many IDN ccTLDs a territory can have. So by definition, the fast-track mechanism has to be -- I'm not sure whether it's best to call it the lowest common denominator or the highest common denominator but it must not interfere with the policy development process. Janis, I'm about to start talking about the mechanisms. Would you like to -- still not yet. Okay. You let me know then, huh? Okay. There is a microphone here [indicating] and we're going to take questions as we go, and I'm happy to stop at any time and discuss anything that is relevant to this. Steve.
STEVE CROCKER Thank you. So I'm focused on this question of numbers. And you've said that the minimum number of IDN ccTLDs would be one per country, per territory.
CHRIS DISSPAIN That was eligible, yes.
CHRIS DISSPAIN That was eligible, yes.
STEVE CROCKER That was eligible.
STEVE CROCKER Let me ask the other end of the spectrum. PDP goes to completion. What is the maximum number of IDN-based ccTLDs that envisioned in totality? Is there an upper limit?
CHRIS DISSPAIN I have no idea. To an extent, it is a function -- to some degree, it's a function of the policy. So to take a really simple example again -- again, just a simple example -- if you were to say that -- if the policy were to say that one IDN ccTLD be allowed per territory -- not per script; per territory -- then clearly the maximum number would be the number of territories.
CHRIS DISSPAIN If you were to say that one IDN ccTLD is allowed per territory, provided that the script is an official language of that territory, that might reduce it from one per territory to a smaller number. So I -- I have no clue yet as to how the policy will shape the maximum number of IDN ccTLDs. However, that obviously is one of the questions that needs to be talked about, in the policy development process.
STEVE CROCKER Yeah. The -- if I might, just -- the -- just I might understand sort of what the delta is between the fast track and the -- and the -- whether or not there really is that much room. Some countries will want multiple scripts. We presume.
STEVE CROCKER Okay. But there's only so many scripts. There's a lot of scripts but there's not millions and millions of scripts. There's scores of them, or maybe -- maybe more. So per country, we're in a country that has 11 different scripts, 12 different scripts. Is there -- does it come out to be an upper bound of, say, 10 per country or is there some reason why it might get to be very much larger than that.
CHRIS DISSPAIN Well, again, to use -- to take specific examples -- and again, just as examples -- to a degree it depends on how you define the status of the language that uses a particular script in the country. If you have no definition and you simply say, "An IDN ccTLD in Cyrillic is available to every territory," so Australia could apply for a meaningful representation of "Australia" in Cyrillic --
CHRIS DISSPAIN Notwithstanding the fact that it's an official language, et cetera, et cetera.
CHRIS DISSPAIN Then that creates one set of parameters. If you say that a language has to have a particular status in the territory, that creates another set of parameters.
STEVE CROCKER It's the other element of what you said. If we are representing the name of the country --
STEVE CROCKER -- as opposed to multiple names that are appealing, then the multiplier effect is related to the number of scripts or languages --
STEVE CROCKER -- but you don't get a different multiplier effect that says, in addition to Australia, you can call it the land down under and you can call it the Oz and you can do each of those in every script that you like.
CHRIS DISSPAIN So before we go any further, just so that everyone in the room is clear, although we're having this conversation using words that are English and use ASCII characters, we are not actually discussing ASCII because the current situation is that there are -- every territory has one ASCII ccTLD --
CHRIS DISSPAIN -- and there is no -- and this policy development process has nothing to do with ASCII. It only has to do with IDNs. So just so that we're clear.
CHRIS DISSPAIN The -- we have not -- we -- the policy development -- one of the questions that the policy development process will be answering is how many per territory per script and how many per territory across script -- across scripts, and what status does the script need to be anyway in order for it to be dealt with.
CHRIS DISSPAIN However, if you look at a -- what a ccTLD currently is, it is a string. Forget the fact that it's two letters. It is a string that provides the ability to meaningfully represent the territory on the -- on the Internet, and if you apply that through to IDNs, then you probably already start to build some borders around the fact that -- I mean, I used the example in the earlier -- in the workshop earlier on this afternoon, you know, if -- no one is suggesting that the Australian government should be entitled to apply for dot Skippy as a ccTLD. It's a meaningful representation of the name of the territory.
CHRIS DISSPAIN No problem. Can I just -- Edmon, I'm happy obviously for you to -- can I just ask that we -- we need to be a little careful we don't get too much tied up in the policy development process. I appreciate the clarification, Steve. That was very important.
STEVE CROCKER I realize that most of what I asked was related to what sounded like policy development. The under -- the reason why I intruded in that is because there is a difficulty, a fundamental kind of difficulty at saying, "Well, we'll make some choices and we'll try not to interfere with what the eventual policy development," but, in fact, the first step, no matter what it is, determines and limits some of the choices that you might have made if you hadn't made that step. I'm not suggesting not to do that, but just that you can't be pure -- you can't be guaranteed that some of the early choices made in the fast track won't interfere.
STEVE CROCKER And that then launched a thought process about So what is the distance between the first step and the last step?
CHRIS DISSPAIN We can simply do our best. There's nothing else we can do. Edmon?
EDMON CHUNG Yeah. Chris, you mentioned that it seems like there is a presumption in what you mentioned that one per ccTLD doesn't require any policy development, and I think that, in itself, is a policy decision.
CHRIS DISSPAIN No, that's not the presumption at all. The presumption is that if you are able to have an IDN ccTLD, the least you could have is one.
EDMON CHUNG So I guess, okay. I think that's an important clarification, that if we do decide on an arbitrary number like one, it is still a particular decision that the IDNC will have to make. And if -- even though, if you say that the minimum is one, I think there is another way to look at it. For example, what you have on the -- on right now, which is the two mechanism to derive -- you know, go through -- which carries criteria and the process for which to deploy, if we leave it up to the mechanisms, we leave it up to the criteria and avoid using the -- an arbitrary number, whether it's minimum or maximum, that is a possibility, so I just don't want to -- I don't think we should rule out that particular potential.
CHRIS DISSPAIN I haven't. I specifically said "This is just an example."
EDMON CHUNG Right, right.
CHRIS DISSPAIN And so absolutely. I agree.
EDMON CHUNG But it came across it's sort of like a starting point and I just want to, I guess, point out that it shouldn't be the starting point, perhaps.
CHRIS DISSPAIN Okay. Thank you. Okay. So what the working group has established, it thinks, so far is that we actually need to recommend two mechanisms. The first mechanism is a mechanism for the selection of the actual string itself, the IDN string. And the second is a mechanism to designate an IDN ccTLD manager. Now, there's been some discussion in the working group about whether there are maybe some sub-mechanisms, et cetera, but I think we're relatively comfortable -- does anybody from the working group or anyone else, for that matter, want to comment on the principle of these two mechanisms and whether there's anything missing? Bruce.
BRUCE TONKIN Thank you, Chris. Is this live? One thing that seemed to be missing, if we looked at the equivalent of the new gTLD policy, we had essentially a string selection process. Then we had an allocation part of the process. But then we also considered what the contractual or the agreement framework would be.
BRUCE TONKIN That, to me, would be a third point that I think is part of a method of allocation, essentially. That there be some consideration given to whatever form of obligation or mutual agreement, however you want to phrase it, would be used after its assignment.
CHRIS DISSPAIN I agree with that. I think to a degree -- to some extent, it's actually covered by some of the subpoints under designation of the ccTLD manager, so when we get there, let's have a look at that and then if it's -- we can come back if it's not -- if it doesn't deal with what you want it to deal with. We also to some extent got to be very careful about scope. It's not this working group's job to draft a contract or an accountability framework.
BRUCE TONKIN [Speaker is off microphone]
CHRIS DISSPAIN The principle that there should -- the principle that there should be one. Yes. Sir?
ERIC BRUNNER-WILLIAMS Thank you, Chris. Eric Brunner-Williams. Is the mic on.
CHRIS DISSPAIN You're on now.
ERIC BRUNNER-WILLIAMS Okay. Good. I know you asked to have little prepositions sent by e-mail but there's one in the second sentence which suggests that there's a singular and unique outcome in the quest for the second mechanism. That is a mechanism to designate an IDN ccTLD manager. That suggests that there won't be multiple -- that there will be a single unique manager of an equivalence class of IDNs for a particular ccTLD, and I don't think that's an outcome that you want to commit to.
CHRIS DISSPAIN I think I understand. You're saying that this would imply that if you had more than one IDN ccTLD --
CHRIS DISSPAIN -- in different scripts you still have to have the same manager.
CHRIS DISSPAIN Okay. That's certainly not the intention. The mechanisms are -- in the same way that it says "the ccTLD string" implying that that -- doesn't mean that there would only necessarily be one.
CHRIS DISSPAIN But I take your point. Thank you. Okay. All right. So if there's nothing else right now, we're going to move on to the topics. And the first one is relating to the string selection mechanism. So what we've done is we've broken these down into a number of subpoints, (a), (b), (c). And then each of those, which has a title underneath, has a series of questions that we think needs to be answered. We do not guarantee, by any stretch of the imagination, that we have thought of anything, and part of this is for people to actually tell us what we've missed. But also, we're interested to hear what the answers might be. Or at least what people think what the answers might be. But what we're going to try and do is whiz through these as quickly as we can, and then go back to each one and actually see if people would like to come and talk about possible alternatives and possible answers. So in respect to script selection, the first one is Is it necessary to limit the number of scripts for which a territory can have an IDN ccTLD under the fast track? Simple question. Is it necessary? So we need to decide if it's necessary. If it is necessary to limit, then what is that limit to be? And is it necessary for the language represented by the IDN script to have a particular status within the territory? Again, just so everyone is clear, this is just for the fast track, so I'm not talking about in the future. Is it necessary that the language has a particular status? And if so, what is that status? And one of the reasons why the answer to that question might be "yes" -- might be "yes" -- is because that makes it easier to reduce the number of applicants for fast track that would be -- that would be out there. Again, I said this this morning in another workshop The intention of the fast track was not to create a mechanism for every ccTLD to grab an IDN ccTLD as quickly as possible. That was not the intention. The intention was to create a mechanism that allowed for some territories who had a pressing need for a TLD in a particular script to get it now, rather than have to wait two or three years while the policy development process was completed. So those are the first set of questions. We'll come back to them. Second, (b), part (b), relates to string selection. Are there any additional criteria for a string to be acceptable under the fast track? Overarching requirements to meet the IDNA protocols and other IDN technical requirements is one thing. But are there any other additional criteria? So we've got an example here. Should we actually say that the string selected must be a meaningful representation of the name of the territory or an abbreviation of the name in the relevant script? Because again, we don't yet know what the final policy is going to be. The final policy might be anyone can have anything. But for now, we need to have some restrictions in place. Second question, does a selected string need to be evaluated against the requirements and criteria? And if it does, then by who does it need to be evaluated? C is string proposal. Who are the actors from the stair tore who need to be involved in making a proposal for the string under the fast-track? And how is the involvement of those actors demonstrated? For those of you who are not familiar with the world of ccTLD delegations, the -- obviously a proposed ccTLD manager is an actor. The government is an actor, and so is the local Internet community. And under the various guidelines and rules that exist in respects to delegations for ccTLDs, those three actors need to be involved. So one assumes the same -- will the same apply for the fast-track, or are there more? Yeah, and how is the involvement of those people demonstrated? And, D, objection procedure. Once a string has been selected in accordance with the requirements -- whatever they may be -- and the criteria, should objections be allowed? And if so, who can object and on what grounds? And if an objection is lodged, what happens then? Now -- so those are the four, A, B, C, D, sections under string selection. So if we go back to Number 1 or Number A, rather, let's see if we have any comments either in respects to additional questions or in respects to any answers that people might like to suggest. Is it necessary to limit the number of scripts under the fast-track approach? If so, what's the limit? Amadeu.
AMADEU ABRIL i ABRIL My opinion here, we are trying to do something simple, which is allow people to use domain names in their languages when the script is not ASCII. In the ASCII world, we don't have the names of the countries or territories in all possible languages. That is, we have dot DE to represent Germany. Even if dot DE says nothing to a Spanish-speaking or a Russian-speaking that call that name or an Italian-speaking person that calls that name with very different names, that doesn't start with dot DE or end or even contain dot DE. But this is not the question. So here, I would say that the limit would be we are not trying to discover how Norway is written in Amharic. We are trying to make sure that people in Ethiopia are able to use IDNs, that is, able to use the DNS in their own languages and, therefore, they need an IDN for that. So the question is what was the limit and what is the number? The limit and number will depend on the situation, and it is as simple as at least one or more in case there is more than one script that's a local language. And when you refer to the status, the problem here is we don't know what's that. There are many countries that don't have any official language at all. Some of them as small as United States; some others more relevant, right? Then you have countries like Australia, that in Melbourne, lots of different languages have regulated status. Even Catalonia can have the right to -- writing to Catalonia, to the city hall, and they will look to someone to answer that in my language which is fascinating, but it's probably besides the point in IDNs. You don't have uniform status. It is your duty to use a linguistic concept of local languages. It is something the language can tell you quite easily and solve most of the problems. That's the purpose, and this situation is different in India and in Russia and in Canada. So we cannot have one solution for it. It is simply -- the scripts that are used by the local languages, whatever the linguist tells us is the local language or the indigenous language, if you prefer.
CHRIS DISSPAIN Bertrand, are you heading to the microphone? Yes? No?
BERTRAND DE LA CHAPELLE Sorry. Just one comment. Each of these questions can lead to endless discussions. We had the wonderful experience in the last two days in the GAC. I won't betray any secret here. We can spend an incredible amount of time on each and every one of these single questions. The more I dig into this issue and I learn about it, there seems to be a very simple image that comes to my mind. You get a list of 200 and whatever name of countries. You get a colon that is the Roman script today. And you get, as far as I understand, 11 or 13 scripts. In some cases, we might have to expand because of their languages. What we are talking in the fast-track is, basically, filling whenever possible, when there is no contention and we can do it fast, a string in each of the little boxes.
BERTRAND DE LA CHAPELLE In that respect, there are obvious cases where there will be only one box with one country, one string and one script, period. I mean, Greece, I'm not sure they will rush to have their name of their country in Chinese and I don't think any other country will rush to have their name in Greek. One script is almost sold. At the other extreme, we know that India is a very complex case and the more I dig into it, the more it seems complex. What I don't understand is whether -- is why in the whole discussion this table is not presented and we're just discussing whether some boxes are so easy to cross that the solution is over and we focus on the complex ones. I see all those processes in this. My final point, ICANN in its processes has an incredible capacity to make complex simple questions and not addressing the complex ones and making them simple.
CHRIS DISSPAIN Absolutely. [ applause ] Two things, Bertrand. First of all, the idea of a table is an excellent one, thank you, and we'll work on that. Secondly, I think the challenge has been that because policy development process -- because no one knows yet what the answers are to the big questions in the policy development process, it is actually quite hard to ensure that we maintain the integrity of that process whilst issuing a name in the fast-track. So the countries like status of language and so on and so forth have to be asked, even if the answer is "no" or "it doesn't matter," they still need to be asked. Because otherwise what happens is you end up effectively a fast-track that delivers all the names and the policies are relevant, which may well be the answer, in fact. Steve?
STEVE GOLDSTEIN I'm Steve Goldstein from the board. I certainly don't want to presuppose a solution, but I would like to review some like pragmatic constraints, the first one is that I do have within ICANN an automated processing capability. If we were able to think of processing, perhaps, something of the order of 100 fast-track IDN ccTLDs, that would undoubtedly constrain our capability to the maximum. In the first year, we may not even be able to accommodate that. So there is a natural limit to our ability to be able to handle things until the system and our capabilities are much more automated. Also, under our present rules, the board has to approve of each and every delegation. That also place as natural limit on the number that we could process. In addition, it is probably quite likely that there would have to be a contractual relation established for each and every delegation, creating contracts, signing contracts, ratifying contracts that, too, places a natural limit on the number that can be processed. My guess is that under situations like that, it is quite likely that for a fast-track -- not for the ultimate but for a fast-track -- we'd be lucky to be able to handle all the countries that need one with just one script per country. That's just a personal observation, that is not an owe official pronouncement of the board.
CHRIS DISSPAIN I understand. Can I just comment that we could discuss the why's and wherefore's backwards and forwards for a very long time. I accept what you say, however, I am assuming that you're not suggesting that we should set our mechanisms based on an administrative -- the mechanism we come up with needs to be a pure mechanism. If there is an administrative problem that arises, then we need to deal with that outside of the mechanism. It is a reality check is what you're saying.
STEVE GOLDSTEIN Just be realistic.
CHRIS DISSPAIN Understood. Dennis?
DENNIS JENNINGS Dennis Jennings, also a member of the board and, of course, not speaking for the board in this matter. The question "is it necessary to limit the number of scripts" as posed there, I would like to address specifically. I think it is not necessary, but I think it is prudent to limit the number of scripts, and probably prudent in the fast-track to limit it to one, unless there are special circumstances. And it is this prudence that I really want to raise. It has taken ten years of ICANN to begin to discuss the processes for opening up the gTLDs. And as Paul Twomey said in the opening session this morning, it is very, very complicated. It, in my view, is impossible to imagine that we will rapidly introduce many cc and gTLDs in new scripts without developing some experience and expertise, particularly in the communities which are not now involved in ICANN but communities that we're trying to serve. So it seems to me very prudent that we would select a small number of scripts, which isn't is a question that has been posed, a small number of script also, in small number of languages or territories in those scripts to get some reasonable experience in the scripts before we rush to do anything else. So I think it would be prudent to gain some experience and, therefore, to keep the numbers as small as it politically practical. Thank you.
MICHAEL PALAGE Thanks. Steve, to comment on your question, just -- I'd like to -- with the number of 100, as a baseline back in 2000 when ICANN was a nice little infant organization with a budget of only around $2 million, ICANN met in Yokohama. They said, We are going to do a RFP for new TLDs. Three months later they issued the RFP. About two months later, 47 applicants came forward and ICANN with a single-digit staff, would outside consultants reviewed them and made a selection of seven and then -- you know, so the ability for ICANN to come to action a do things when it really needs to when they had a very modest $2 million budget not the $60 million which has been proposed for the upcoming year, the ability to do action and make something happen is there. Again, not to disagree with what Steve was saying, I don't think that number of 100 should be, oh, so scary with the resources that ICANN has in place today.
WERNER STAUB My name is Werner Staub. I am speaking in a personal capacity. I am always struck when I hear people wanting to limit the number of scripts and be cautious about introduction of IDNs, ccTLDs. These people tend to be people that write only in Latin script during their personal lives. Just imagine for a second that Internet had been developed in Arabic and that all the domain names that we have used are in Arabic, that Dennis Jennings who just spoke is, of course, fluent in Arabic has an educated person, as everybody is supposed to be and we were holding this conversation in Arabic. When we stood here and wanted to use our own script, being Swiss or British or whatever we are, wanting to use our own script rather than Arabic on the Internet, would it feel like this is a gave-away? We get another TLD which is doing what we always needed to do. Wouldn't we feel that there is a sense of urgency? Wouldn't we feel that it is an easy decision? It is not something that requires a lot of committees, it would simply be a decision of the panel. By the time you must be satisfied, you would have about 50 or 70, not more. Good point. Let me -- just so we are clear, I am conscious as people in this room who have not necessarily been involved in this debate for as long as we have, we are specifically talking about the fast-track here. So we're asking the question about the limitation of numbers, not from a policy point of view as to whether there should be a limitation of Numbers which is a different question but whether to make a fast-track mechanism work in the very short-term is it necessary to limit the number. I just wanted to make that point.
WERNER STAUB Sorry, I wasn't clear about my answer to that question. It is going to cost us more time to discuss that question than to simply go ahead without limitation and make the decision case-by-case.
BILL SEMICH I have a related question or comment to Werner's comment. We've -- in the meeting this morning and now today, I'm finally understanding that we're only talking about non-Latin characters as a fast track.
BILL SEMICH But we haven't really said that in any of the documents that we've prepared as a limiting factor and I'm just wondering if we need to pin that down in the documents. For example, is Icelandic a Latin character set? There are a lot of Latin characters in Icelandic but there are a lot of non-Latin characters. So I think we need to sort of pin down the limits of what isn't going to be --
CHRIS DISSPAIN I understand, yeah. I think we had --
BILL SEMICH -- eligible for this.
CHRIS DISSPAIN I think we actually have somewhere, but not -- I don't think in this document.
BILL SEMICH I don't think I've read it anywhere.
CHRIS DISSPAIN I think we're talking about -- I think the definition of IDNs is IDN scripts plus ASCII --
BILL SEMICH Definition where?
CHRIS DISSPAIN I can't remember. It's a very good point. We've made a note of it. We'll work on it.
KHALED FATTAL Thank you, Chris. I was actually trying not to come up to the microphone to at least give my --
CHRIS DISSPAIN I had a feeling you weren't.
KHALED FATTAL Well, because the subject matter is really -- you know, if the subject matter is fast tracking let me just address the issue here. Before every ICANN, I go and see my therapist and I go and try --
KHALED FATTAL -- my antidepressant filled so that I'm really ready for the event and I'll tell you why this addresses -- on a lighter note, but seriously, tell you why this addresses the fast track and I think your point to redefine and redirect is very valid. We are in 2008. In 2003, the world -- the international community out of WSIS had already agreed on an action plan and a declaration of principles which ICANN is a signatory to as well. On the Internet becoming multilingual. Why are we today discussing whether it should or should not be -- whether we should or should not discuss language? I mean anybody here would know that language is fundamental. If we're going to do anything to do with local languages and IDNs with local countries and local territories -- if you want to call them that -- language is already, you know -- it's got to be a factor. But --
KHALED FATTAL -- we have not been discussing it for the last five years. What we've done is we've already looked at mechanisms that actually avoid issues that may be controversial but we don't know the answers. I don't claim that I have the answer, by the way, but I think it is imperative to put the issues on the table that need to be discussed because when we're dealing with IDNs, whether it's ccTLD or gTLD, these subjects are going to come up Language, script, jurisdiction, sovereignty. If we don't discuss them and figure out how to move forward, guess what. We're not fast-tracking anything. Something else. When is it going to happen when we are learning from our previous mistakes? And I'm speaking here within the ICANN community. The suggestion that Bertrand mentioned, which seems to have gotten a lot of applause, is absolutely valid. This is not new. We talked about this three and four years ago. And we are -- I am speaking from an Arabic perspective as well. From one of the many hats. So this is not communities that need to come up or ICANN needs to help them. We are part of the process. But it seems like we don't want to learn about the things that have been done so that we can truly fast track. And I fully support the fast track, but it needs to be a truly fast-track process, not more of a marketing campaign process which ends up in more bureaucracy.
KHALED FATTAL That's my thought. Thank you very much.
CHRIS DISSPAIN Understood. Thank you. Ram?
RAM MOHAN Ram Mohan, Afilias. Two observations. Number one, I think it's important to distinguish between the number of scripts for a territory from complexity. You know, I had -- I heard Steve Goldstein earlier say -- or someone else earlier say that the case of India is very complex. In fact, for what we're talking about here, the case of India is not very complex. There are 12 scripts. India is going to be represented in a unique way in each one of those 12 scripts, and once it's defined and it has a specific status associated with it, getting it out there is actually not a big deal. So let's just make sure that we are separating complexity from implementation. Implementing, you know, India at the top level -- you know, Bharat in Hindi or Bharatam in Tamil -- to actually do it is noncontroversial, pretty straightforward, and I think the fast-track mechanism will allow it. The second observation is one size doesn't fit all. One thing that I've heard over the past few months has been that if India wants 12 scripts, every other territory should also get, you know, 12 scripts. Now, that doesn't really work well, and I think it's important to establish that, you know, when -- when there is some sort of a status or some sort of a mechanism that identifies language, script, et cetera, follow those. And I think you will actually get past it. One of the suggestions has been to go, you know, constitutional --
CHRIS DISSPAIN Yeah. Let me push back for a second because what you said is very interesting. If India has 12, I want 12, et cetera. Well, yes. And I agree that's -- for me personally, that's nonsense, but what's the basis upon which India has 12?
RAM MOHAN Well, let's look at the constitution of the country as an example.
RAM MOHAN The constitution --
CHRIS DISSPAIN You don't have to go into detail. You're saying it's a constitutional thing.
CHRIS DISSPAIN So does that then mean that the policy has to be --
RAM MOHAN Taken an Indian currency note in your pocket, you will see official languages on the side.
CHRIS DISSPAIN I understand that. So then does that mean that the policy must be that whatever are the territory, the scripts have to be constitutionally recognized? Does that mean that what -- in another territory, the scripts have to be on the banknote? Or are we saying there is no -- actually no across-the-board policy, there is simply whatever suits each particular country at the time and how do you decide what that is. If you go -- if you take steps into delegation and redelegation and all the struggles that happens there about WHOIS actually representing the territory, et cetera, et cetera, et cetera, what do you do about competing suggestions where one side of the territory says that, "This is an official language" or whatever and another one says it isn't? I'm only just throwing these things out there because my -- my point is that it is complex. It's not complex when you know what you want and you're clear, because you see it in a self-encapsulated environment, which is perfectly acceptable. The Saudi Arabians are absolutely crystal clear that they want dot Saudi in Arabic. No problem. Easy as anything. But that's for them, and it's clear that you have your 12 scripts --
RAM MOHAN Chris, I don't think there's any other country that wants dot Saudi in Arabic.
CHRIS DISSPAIN That's what we're talking about.
RAM MOHAN What I'm talking about, and let's take the case of India. What I am talking about is there is not another country that I know of that is going to want dot India in another script.
CHRIS DISSPAIN Ah. So hang on. So you're talking about depriving other countries of the script and I'm not talking about that. I'm talking about whether it is necessary -- because this is ccTLD land, whether it is necessary --
RAM MOHAN I'm not talking about depriving --
CHRIS DISSPAIN Sorry. Names, names.
RAM MOHAN Of the name, yeah.
CHRIS DISSPAIN Of the name. What I'm talking about is whether it is necessary for there to be specific policy to decide that this thing is a ccTLD as opposed to it is simply a name that you apply for with a gTLD -- through the gTLD process and you treat it as a gTLD. If you want it to be a ccTLD, there are certain things that go along with that, and, therefore, there are certain policies that need to be in place to ensure that it is a ccTLD as opposed to a gTLD. That's what we're talking about.
RAM MOHAN Fair enough. Let me -- let me suggest something. I think perhaps what we are in danger of doing here is looking at IDN ccTLDs with the lens and the prism of how it's been done with ASCII, and I suggest to all of us here that that's probably not a good model to work with. There is not a one-to-one mapping anymore. I mean languages and scripts --
CHRIS DISSPAIN So how much will you pay -- how much will you pay?
RAM MOHAN Hold on a second. What I'm actually saying is, when you're saying, "What should be the criteria to select," that's a good thing for the fast-track committee to look at.
RAM MOHAN What I'm actually saying is Predetermining that a country or a territory must select one, because they were given one in ASCII --
CHRIS DISSPAIN No. I'm not saying that.
RAM MOHAN -- I don't think --
CHRIS DISSPAIN No, we're not saying that at all. We're not even saying that they must select one. I was just using it as an example. But my point is it's got nothing to do with how many there are in ASCII. Nothing to do with that at all. It has to do with what will the final policy for IDNs say is the number. If the final policy for IDNs says -- not a specific number. It will set itself according to criteria. If the future policy for IDNs says anyone, any territory, can have anything it likes, subject to -- you know --
CHRIS DISSPAIN -- it can have as many as it likes in one script or it can have one each, one across every script, that's -- that creates one set of parameters. If we -- and again, I'm just using these as an example. If we give you 12, then that immediately means that we have decided that it is right for there to be able to be a -- for a territory to have one TLD -- or one IDN TLD per script using the definition of the status of the script that India has. That doesn't necessarily mean that over here, that's going to work for another territory.
RAM MOHAN I agree with you.
CHRIS DISSPAIN So we have to decide -- so we may decide that, in fact, we can't have. But that -- we can't have any policy. It has to be, you know, per territory. But the problem with that is, that's all fine but that's -- that's the policy development process. We're talking about right here the fast track the intention for which was always to simply try to relieve the pressure. And the reality is, this is not guaranteed to happen. If we cannot come up with a mechanism, then the -- the working group will simply say, "Sorry, it's just not workable. Wait until the policy development process has occurred."
RAM MOHAN Yeah. I -- and that's a fear I have. You know, if I listen to what Steve Goldstein was saying, the fast-track process might take about two or three years and then the policy development process might be -- you know, I might be too old to even think about what might happen there. [Laughter]
RAM MOHAN So that's -- I just -- that's my concern. The issue is, if you look at a minor language in India, Tamil, it's only got 70,000 users, not a lot of users given the scope of India itself.
RAM MOHAN But it's got pressure to actually be able to reach out and get all of those people accessed, and do those folks wait for the policy development process, rather than the fast track?
RAM MOHAN And I'm making the case it ought to be fast track.
CHRIS DISSPAIN I'm conscious of two things. I'm conscious of the fact that there are other people in the queue because something someone said has caused people to get up and -- But if you'll indulge me, I just want to ask one more question of Ram. This is as much for the committee's benefit as everybody else's. So let's say 12. Let's say they're on the banknotes. Let's say fine, no problem. So what does the string have to say? Does it have to say the name of the country? Or is it acceptable to have an abbreviation? Does it have to be the full -- the full name or is an abbreviation acceptable? Because the moment you do this, you're into policy areas. So that's why you have to be so careful. Could we simply say it's the name of the territory on a list somewhere? No, that won't work for the Hashemite kingdom of Jordan, unless you want to talk further.
RAM MOHAN Yeah, Chris, I agree with you that this is a very thorny area and I think Steve Crocker was -- I'll echo what he was saying. By making decisions, by saying, for example, fast track won't consider some of these PDP areas, you are making policy. And you may not like to hear that that's --
CHRIS DISSPAIN No, I accept that.
RAM MOHAN So in I didn't remember -- the answer to your question might simply be, you're going to make a choice, whatever the fast track committee makes is a choice, and then that becomes a policy that further development, you know, looks up and says that's good, we endorse it, or that's not good and it ought to be changed.
CHRIS DISSPAIN Okay. Thank you, Ram.
RAM MOHAN Thank you.
ERIC BRUNNER-WILLIAMS Hello, Chris. Eric Brunner again, speaking in a personal capacity. Much of what I would like -- came up to say has just been said. But I want to give you two examples. There are a third of a million Din?tah speakers -- Din? who live in Din?tah. You probably call them Navajos. There's a quarter of a million Tsalagi only a few of which speak Tsalagi. Those are Cherokees. I'm one of them. There are two points here, I think. One is the U.S. will probably never formally recommend to any body in the international arena, including ICANN, the allocation of any resources, any namespaces, to any indigenous language community in the United States. Over which it has colonial domination. And the second one is that if we were to wait for the policy that is recognizing that the large languages are going to get the fast track and the minor languages like Tamil or the very minor languages like my own are going to get the full policy treatment and in our old age will finally be available to us, many languages that are much smaller than Navajo, much smaller than Tsalagi, will probably be out of living speakers in our lifetime. So the choice of mechanism to make the access to fast track through state actors already eliminates a class of candidate scripts, and the existence of a mechanism that privileges larger groups and does not privilege smaller groups will have consequences which are deleterious to the smaller groups. Thank you.
CHRIS DISSPAIN Thank you. Tina?
TINA DAM Hi, Chris. Tina Dam from ICANN staff. So I just have a comment. Not really a question. A comment into the fast track. I hope it's -- well, I think it's clear from the discussions that have taken place today, and previously in the week, that talking about numbers and limiting numbers and numbers at all might not be very useful because the need is different in different places of the world. We've also talked about the fact that from a technical standpoint, you know, the root servers and the resolvers can handle this, but in my mind also from a technical standpoint, we start having some related technical problems if we're talking about huge numbers that are just entered with -- without any criteria around it. So I think maybe it would be useful to start specifying what that criteria is. What is necessary in order for these strings to be entered? And I think maybe there could be a community consensus that in a fast track, and in order to do something fast, we could make some rather restrictive criteria in order to get somewhere faster and gain some experience before we start putting huge numbers into the root that is going to cause what I consider related technical issues. So get the -- you know, I think we should go towards the criteria as opposed to the numbers, and I think that was where Ram was getting at, and those who have multiple scripts and languages --
TINA DAM -- are arguing in that direction.
TINA DAM Oh, and actually one more thing.
TINA DAM If we do that, then I actually don't think that the number we're going to end up with is going to be that huge --
CHRIS DISSPAIN Particularly high.
TINA DAM -- that we're going to have a problem.
CHRIS DISSPAIN Okay. So can I just summarize that, to make sure that I'm clear, Tina. What you're saying is that rather than saying limit to one for now -- we're just talking about the fast track -- limit for now, et cetera, set up a series of criteria, and if you happen to have six that meet that criteria, then so be it? Is that basically what you're saying?
TINA DAM Set up -- sorry. Set up a criteria -- a set of criteria that the local communities then can come and say, "Based on that criteria, here, look, we have done this and this and this. These things are in place. We've fulfilled the criteria." And then whatever number that they come up with will then probably have some relation to the languages that are used in those local communities.
CHRIS DISSPAIN Sure. But that would mean, wouldn't it that -- can you go back to slide -- to the previous slide? But that would mean, wouldn't it, that the second or third lined point would still need to be answered, wouldn't it? About what status the -- what status the language had in the territory? Would you still need to answer that question? I can understand you'd lose the number question. You'd simply say, "If you're 6'3" and wear green shirts and you're blonde, then you can -- then you will -- you meet those criteria," tick, but would we still not need to answer the question, what's the status of the language or the -- sorry, what's the status of the language that uses a particular script? Or are you suggesting that Australia could apply for dot Australia in -- well, then you are saying -- then you are saying that you do have to answer the question in the criteria, that the language must have a certain status, so you're not suggesting that anybody can have anything, so you still need to have to answer that question. Okay. Cool. Thank you. That was what I was trying to get to.
TINA DAM Oh, did you want my answer on it too or should I go --
CHRIS DISSPAIN No, no. You go ahead if you got a different answer.
TINA DAM Oh, but if I go and put on a green shirt, then I guess I get an IDN TLD.
CHRIS DISSPAIN Right. Exactly right. But only if you get a green shirt.
TINA DAM I'm going to go now. But I agree with Ram, so for those of you who didn't hear what Ram said, that was a yes and I agree with that.
CHRIS DISSPAIN So we do need to answer that question.
TINA DAM I think you need to put some criteria around that question, especially in the fast track, because if you don't, then you're going to end up with something that is rather unlimited.
TINA DAM And unlimited to me means technical concerns.
CHRIS DISSPAIN So you would say and I detect that some people here would agree with you, you would say that the answer to the first question is no? The second one becomes redundant because of the answer to the first one. But the answer to the second -- to the third one is yes.
TINA DAM Well, okay. So we're going into, I think --
CHRIS DISSPAIN It's just a personal opinion but --
TINA DAM -- we're going into discussion. Limitation, I think, happens automatically if you put up the criteria.
TINA DAM So limiting the number, I think you should not say it should be one per each or two per each.
CHRIS DISSPAIN Criteria limited.
TINA DAM Criteria due to limitation.
CHRIS DISSPAIN Understood, gotcha. Yes, sir?
KANWALJEET SINGH My name is Kanwaljeet Singh. I am a journalist and I am speaking on my personal capacity. Am I allowed?
CHRIS DISSPAIN You need to be a little louder.
KANWALJEET SINGH I am a journalist. I am speaking in my personal capacity. Am I allowed to speak?
KANWALJEET SINGH What I want to raise is the first criteria should be numbers, number of users per script, (inaudible). Second thing, when you take, for example, India, we have 22 scripts, all have been applied -- all have applied -- the government of India has applied for all of them. First fast-track, Hindi, Hindi is the main thing here. Put all of those in the second level, second round.
KANWALJEET SINGH And, C, if in first fast-track number of users criteria are taken into account, if some area is left out, take them as minorities, say, for example, some small island is left out and they don't have anything in the script, no script has been nominated as per the number of users, nominate them in first category, first round.
CHRIS DISSPAIN I understand.
KANWALJEET SINGH Take those, all regional languages, the languages which don't have a common language -- like in India we have a Hindi as a common language all over India. English is certainly there and English is working. Take all these regional languages in second round. First round, go with the vast main language of the region. If somebody -- certain areas or some islands, some nation is left out as a minority are not governed in the main languages which have been governing, take them and go into the second round. This is my suggestion.
CHRIS DISSPAIN Thank you very much.
THOMAS NARTEN Thomas Narten, I'm the IETF liaison to the board. This is just my making some observations. Listening to the discussion back and forth, a lot of what people have said, I agree and I think makes a lot of sense. I will sort of observe. I think the way the bullets are written here are not very helpful in the discussion because you are sort of asking why a black-white yes-no question, is it necessary? Well, necessary for what reason? What criteria? If the answer is yes or no, what does that mean? In some sense -- the other observation, again, is what is the purpose of fast-track?
THOMAS NARTEN It is to do something quickly, relatively quickly. And the way you do things quickly is eliminate and avoid controversy.
THOMAS NARTEN And the way you do that, you winnow down your choices and take away degrees of freedom. Perhaps, it is not necessary to limit the number of scripts but would certainly be prudent if you want to get something done in a reasonable time frame. And it is much more productive to talk about, well, what would be reasonable criteria in -- to define what the limit should be either in a hard number or a criteria. Same things for the first bullet and the third one, is it necessary for the language represent by IDN script to have a particular status? Well, of course, because if it doesn't have any status, then there is no limit.
CHRIS DISSPAIN Okay. Thank you, Thomas.
AMADEU ABRIL i ABRIL This is Amadeu Abril i Abril again and will try not to repeat what has been said. Remember, this is a fast-track for one goal. How many territories? For many of them known -- if Australia came to propose 12 different scripts -- different ccTLDs in different scripts for Australia, I hope that somebody will tell them that they are in the wrong place in the wrong moment. This is not for this sort of stupid exercise, even if -- you know, it would be nice to put your own name for other people. The goal here is to lull those people to have a main language in their main territory, something that's not in Latin to have access. Therefore, the only criteria here should be the denomination, identification, or abbreviation of the name of that territory in any of the local scripts, and, then, how you approve that method. Look, if you try to set criteria, you will never find that. The criteria have to be negative. You cannot define fairness or justice. You identify unfair or unjust situations. It is very difficult to define what's being in love, but I know that you are not in love with me. I know I am not in love with you. We are just friends.
CHRIS DISSPAIN What are you talking about?
AMADEU ABRIL i ABRIL It is very difficult to define friendship. So do something. Give these definitions. Identification, abbreviation or designation of that language and only that, that territory, that language. And then have a panel of people to review that in case there is a problem. Example of problem, Russia wants you in Cyrillic. This is exactly the same look as PY, Paraguay. There is a reason for saying no. We start saying no confusingly similar. We know where we will end. So just have a joint group of ccNSO, GNSO, GAC and ISO, you know, ten people reviewing that and having one month for reviewing its application. If they don't see a problem, that's it. It's easy. It's funny.
CHRIS DISSPAIN Thank you, Amadeu. Just before you start, Adrian, because I love making you wait even longer --
CHRIS DISSPAIN We are going to have a break. So I'm going to draw the line behind Roberto and we are going to have a break. When we come back, we are moving on to the next slides. Otherwise, we will not get through everything. Mr. Kinderis.
ADRIAN KINDERIS Adrian Kinderis. I am speaking in my capacity as a simpleton and as a member of the GNSO Council.
BRUCE TONKIN They go together.
ADRIAN KINDERIS They do not go together necessarily. Thank you, Bruce. [ Laughter ] Two points. First one, just wanted to, I guess, make the point, provided you were prepared to pay a fee to be determined and provided you were prepared to pay -- sorry, to sign a gTLD contract, just wanted to remind entities out there, people, that if you miss out on the fast-track process, we will gladly welcome you in the gTLD process.
ADRIAN KINDERIS For new TLDs. Point one.
CHRIS DISSPAIN Sorry, there's more?
ADRIAN KINDERIS Second one, I assume there will be 14 more versions of the new Delhi sign up tomorrow so we get all the scripts in? Is that right? How many scripts am I going to see there?
11 more scripts.
ADRIAN KINDERIS 11 more scripts. If we can get that done by tomorrow.
CHRIS DISSPAIN How do you know they're not there?
ADRIAN KINDERIS It is a subtle point. Subtle point, thank you. [ Laughter ]
BERTRAND DE LA CHAPELLE Bertrand de La Chapelle again, personal capacity. Just volunteering my personal answer to these questions. Is it necessary to limit? No, it is not necessary. Is it useful? Probably yes because we're in a fast-track. We don't want to overload. We want to make it efficient so globally it would probably be better in general to have one string per country per script. And, ideally, one string per country in one script at first, knowing that -- of course, exceptions are important. Some countries will have to go with exceptions, so there is no such response as to the second question because there is not the limit.
BERTRAND DE LA CHAPPELLE This is the whole problem of distinguishing all the different subsets. Once again, if you keep in mind this table of 13 columns and 200 and so lines, how many lines, i.e., territories will want to fill any of the columns? How many of them will want to have something in more than one column? This is something that a group of five people tonight can get around the table and get like this how many we will have.
CHRIS DISSPAIN You will do that, then, tonight?
BERTRAND DE LA CHAPPELLE I am volunteering for that.
CHRIS DISSPAIN While we are at Bollywood. Let's make it simple, you, Avri, I for the GAC or Janis, somebody from ALAC, we sit around the table and we produce this whole thing. I am doing it on PowerPoint. We can black and white the different columns, and tomorrow I'm willing to present my estimated guess of how many problems we have. I'm sorry.
CHRIS DISSPAIN Can we have wine?
CHRIS DISSPAIN Can we have wine?
CHRIS DISSPAIN The end of the table may be a little messy.
ROBERTO GAETANO First of all, if there is one volunteer, I volunteer also, even if there is no wine. I think it is an interesting approach. Roberto Gaetano, member of the board. As a member of the board that came here in reality much more to listen than to speak, but as the discussion was going on, I think that I have to make the meeting aware of one of my worries. We have started talking about IDNs many years ago. And we had complicated issues that were technical and political and so on and then we came out with this idea of a fast-track because we were thinking that to solve the global problem will take years, and we don't have the luxury of time because we have already large part of different experiences with top-level domain in scripts that are starting -- that are presenting the risk -- the series of risk of fragmentation of the Internet, which is not something that any of us is going to look forward. But I think there's one essential feature of the fast-track, that it has to be fast. And I think that we have to come up -- and that's why I am looking forward to a quick solution like the one that Bertrand is proposing. We need to be aware that this process has to bring IDN TLDs in the root by the end of this year and, otherwise, we would have failed one of the objectives that we had. So if things start getting complicated, let's start to cut out the complication. Let's try to make something that if it's not globally fair, that is not globally responsive to all the millions of objections, but that at least can reach with 20% of the effort, 80% of the objective and not spend another 80% of the time for the additional 20%, that is going to be solved by the general solution that might come up in place in the years to come. But let's keep the fast-track fast. Thank you.
CHRIS DISSPAIN Thank you, Roberto. [ applause ] Some of us have taken to calling it the slightly less slow track. We're hoping it will still be fast. We're going to take a break. We are going to be strict on time. We'll start again at quarter till. We do need to finish pretty much on time, 600 or a few minutes thereafter, so we'll be back in 15 minutes. Thank you very much. (Break)
CHRIS DISSPAIN Please take your seats, ladies and gentlemen. We're going to start again. Thank you, everybody, for coming back. There are still some people to come back but we do need to get started, so we will. Okay. We're going to move on to Section B of the initial report which actually deals with -- sorry, Section 2 of it which deals with the second mechanism, which is the mechanism for the designation of an IDN ccTLD manager. Now, there are some -- just give me one second and I'll just get my slides up. There are some overarching requirements and limitations in respect to that, and these are overarching requirements that are -- form the basis of the working group's charter approved by the board. We have been told that an IDN ccTLD has to meet the IDNA protocols and any other IDN technical requirements. That, to me, is obvious. Clearly any IDN has to meet the IDNA protocols and technical requirements. It also has to -- we also have to, as an overarching requirement, that the current practices for the delegation of ccTLDs apply. This is not -- this fast-track approach is not an opportunity to rewrite the delegation processes for ccTLDs. So any delegation of an IDN ccTLD in the fast track has to be in accordance with the current practice for the delegation of IDNs. -- for the delegation of IDN ccTLDs, and that includes the various IANA materials and so on. And there is a question, which is Are there other IDN-specific criteria that an IDN ccTLD manager needs to meet. And we don't know the answer to that question, but it is, I would submit, certainly a valid question which would need -- which would need to be answered. So (a) who can be the IDN ccTLD manager? Does the IDN ccTLD manager need to be evaluated against the requirements and criteria? And if so, by whom? Now, if you look at the current delegation process for an ASCII ccTLD, there are certain requirements that a ccTLD -- the proposed ccTLD manager has to meet. This question -- and they're there. They're a given. This question is whether there are -- whether there should be an evaluation process against those criteria and the IANA -- sorry, and the IDNA protocols, and if so, by whom. Secondly, does the IDN ccTLD manager need to demonstrate a track record of managing a TLD? Now, the current situation is that under the -- under the normal delegation of ccTLD process, there's no requirement that the ccTLD manager needs to manage the TLD before, but the question is here, in the fast track for an IDN ccTLD, given all of the other bits and pieces, should there be some sort of experience demonstrated by the IDN ccTLD manager? And finally, does the IDN ccTLD manager need to demonstrate experience with running IDNs in a particular script, or does that not matter. Okay? We're going to come back to these in a minute, so I'll just go through them, so that you can see how they all fit together. The second one is operation of the IDN ccTLD. Given the overarching requirement to adhere to the IDNA protocols and other technical requirements on an ongoing basis, how can ongoing adherence be ensured? Are elements of the registration policies of the IDN ccTLD manager relevant in relation to compliance with the overarching IDNA protocols and other technical requirements? So because this is an IDN ccTLD, there are some new things involved. IDNA protocols being one of them. So does that affect the registration policies of the IDN ccTLD manager? And thirdly, if so, how can ongoing adherence to the required policies be ensured? So this slide is all about ensuring ongoing -- ongoing commitments. And to some extent, Bruce, that -- the answers to some of the responses and answers to that may, in fact, turn to contractual obligations in the sense that if you're trying to assume ongoing -- ensure ongoing adherence to stuff, then one of the answers to that may be Yes, and it should be in some way contractually -- in some sort of contract. Because you asked earlier on about that.
BRUCE TONKIN [Speaker is off microphone]
CHRIS DISSPAIN Well, it doesn't say that. I'm just saying that the answers to this -- if the answers are -- one of the answers to how do you ensure stuff on an ongoing basis could be Well, you put it in some sort of a contract. I wasn't suggesting it answered your point, just that it's relevant to your point. Janis, did you want to speak?
JANIS KARKLINS Yeah, once you're done with this.
CHRIS DISSPAIN Once I'm done with this. Okay. That's it? That's it. I'm done with this. So before we go back and start talking about the individual ones, you want to -- okay.
JANIS KARKLINS Janis Karklins, chair of the GAC. Of course I want to apologize. I didn't understand that you will start now with the managers and I missed the chance to say what GAC decided in relation to --
CHRIS DISSPAIN We'll go back. We'll go back --
JANIS KARKLINS -- to script selection.
CHRIS DISSPAIN We'll go back. Sorry. No, it's my fault. Which one? C, B or A?
JANIS KARKLINS Yeah. We were discussing this section of the initial report in the GAC, and it turned out that there were two questions which we wanted to add, and initially we thought that they would fall under section B and C, string selection and --
CHRIS DISSPAIN String proposal.
JANIS KARKLINS -- string proposal, but we decided that maybe they are more overarching, the whole script section of this, and I would like maybe to read out, though I submitted them already, on behalf of the GAC to the --
JANIS KARKLINS -- to the working group list. So these two additional questions is what GAC is proposing to add to the initial report and seek for answers. They are the following Should there be coordination and cooperation within different script groups on definition of the IDN ccTLD strings in given scripts? And the context of this question is that we know that there is an Arab group dealing with Arab scripts, and this is apparently working very well, and may serve as an example of cooperation. And another question was -- is related to ICANN's role, and the question reads "Does ICANN have any formal role, other than facilitating multistakeholder corporation, in defining IDN ccTLD strings consistent with security and stability requirements of introducing IDNs?" So these are two questions GAC would like to add to the list in the initial report. Now, with your permission, I would move on to the second section concerning the designation of IDN ccTLD managers. We had a long discussion on this. We did not find answers to all questions, but there were three principles that we agree as a GAC, and these principles are the following and here I'm referring -- I wonder whether we can take Roberto as an honorary member of the GAC, because our first thing, what we said was that the fast track should be really fast. [Laughter]
JANIS KARKLINS And basically, Roberto said that already before. Procedure should be light and consistent with current ccT -- ccTLD delegation process. At the same time, it should be ensured that the stability and security of DNS is not put in jeopardy. So this is the first thing that we agreed upon. The second is that the GAC ccTLD principles are relevant and applicable to IDN ccTLD fast track and PDP, including when it comes to the delegation of IDN ccTLDs. And the third, we felt that the questions outlined in the initial report will facilitate decision-making process at the national level.
CHRIS DISSPAIN Thank you. Thank you, Janis. Those questions and comments have been posted to the comments list? Okay. Excellent. All right. So let's go back to the first of the manager questions. Does anyone think or does anyone know or would anyone like to tell us about any other IDN-specific criteria that you think an IDN ccTLD manager needs to meet? We know that they've got to meet all of the usual ccTLD criteria manager, we know that they've got to meet the IDN protocols and technical requirements, et cetera. Does anybody have anything else that they think that we know of right now that we can add to the list? Yes.
SAMRAD HUSSEIN My name is Samrad Hussein from Pakistan. So this -- there may be some script-level issues when you go into ccTLDs, so for example in Arabic scripts, you may want to have space between two words, if your country has a name which has two separate words.
SAMRAD HUSSEIN So those kinds of issues which are IDN-related issues that --
CHRIS DISSPAIN They would be covered by the IDNA protocols, though, would they not?
CHRIS DISSPAIN Yeah. Okay. I understand.
CHRIS DISSPAIN Okay. Thank you. Okay. Well, that's good. So I'm not -- that doesn't mean there aren't any others. It just means that no one else in the room knows of any others, which is good. Okay. Moving on to the next slide given that the -- given that the IDN ccTLD manager is going to have to go through the current delegation processes, which means that they're going to have to satisfy IANA in the usual way of their technical ability, et cetera, et cetera and they may, indeed, need to sign some sort of document in respect to the ongoing commitments to adhere to the IDNA protocols, and so on and so on and so on. Apart from the IANA -- the job of IANA, to ensure that -- to recommend the approval of the delegation, does the manager need to be evaluated against the criteria or requirements separately from that and if so, by whom? I can't see anybody desperate to talk about that one at this stage, so it's a question that needs to be thought through and it may be that it's sufficient to -- it may be that it's sufficient to empower in the same way that one assumes that the gTLD -- new gTLD process in respect to IDNs will have the normal requirements plus some additional IDN requirements, and presumably those will be being checked by IANA. Maybe the same thing applies to ccTLDs. That's -- and it's as simple as that. This is -- I think this one is quite interesting Does the IDN ccTLD manager need to demonstrate a track record of managing a TLD? None of us are particularly concerned about the fact that a new ccTLD manager arrives on the scene for country X, territory X, and goes through the delegation process and becomes a which would manager. This is -- this question is Is there anything special about IDNs in the fast track that would mean that for security and stability reasons or for any other reason we should ask -- we should say that the -- specifically for the purposes of the fast track, that the manager should have TLD experience. Bruce?
BRUCE TONKIN Chris, again, just as kind of personal thoughts on this, if we come back to the objective here that this is fast-track and that IDNs are new, in the first place, and there is not a lot of experience, I think it picks up some of the things that Tina was saying as well, that the way you are kind of crafting this sounds very much like the long track to me rather than the fast-track. Part of the fast-track would be to say, well, those that actually have experience and have potentially operated at least at the second level within their ASCII TLD, to me, would be a good way of constraining this. You're not just opening it up. If you don't already have the 20 scripts at the second level, don't suddenly want 20 scripts at the top level.
CHRIS DISSPAIN Yeah, absolutely. The purpose of asking those questions is actually not to make them long. It is to answer them in a way that makes it shorter. Just to give you the background so that you understand the concepts in which this came up, you might be surprised to here amongst -- in the ccTLD community, one of the questions is, well, does the incumbent ccTLD manager have a right to be the ccTLD manager of the IDN in that particular territory? And the question about having experience is specific to the fast-track because as you quite rightly say, that may be one way of fastening -- speeding up the fast-track because you've effectively preapproved in the sense that you are already a ccTLD -- or a TLD.
CHRIS DISSPAIN You are talking about general experience or IDN experience? IDN experience that's sort of a subquestion but I agree. Eric?
ERIC BRUNNER-WILLIAMS Thank you, Chris. Eric Brunner-Williams again speaking in a personal capacity. The first observation I would like to make is that this makes an equivalence class of all ccTLD managers that are hypothetically -- all ccTLDs which are in this hypothesis being considered for fast-track. Shortly after September of 2001, I did a survey of the zones in a particular geographic area of the world and found that most of them could have been run out of a very small portion of my Rolodex. Not all ccTLDs -- the operations of many ccTLDs is not an indicator of the ability to do very much at all. Second, the elimination order in the gTLD space as we brought up the seven new registries then of the early aughts of this decade, some of them were very small and very modest operations. Some of them turned out to be very modest operations even though they had very large budgets. So I think the point I'm trying to make here is that the demonstration of the track record is probably not relevant or it is not as relevant as it would be for -- for a large gTLD proposal. Ironically, on the other hand, one of the hard parts of gTLD proposals is marketing the name, and we assume in fast-track that the marketing has already been taken care of because there is demand.
CHRIS DISSPAIN It is a ccTLD so the marketing is less, yeah.
ERIC BRUNNER-WILLIAMS There is demand whether or not the ccTLD wants it or not. There apparently is demand from the linguistic community. So that part of the problem is absent in terms of looking at the requirements of the candidate to operate.
ERIC BRUNNER-WILLIAMS Then the last bullet point about experience with a particular script, if we were to generalize that and to say does -- is there any specific policy that makes this different from any -- I mean, it sounds like there are nuances in the third bullet item which I don't think actually are present if we remove the word "script" and replace it with just "generic policy." So does operating a TLD have any competence in a particular area of policy? I think the answer to that is clearly no.
CHRIS DISSPAIN Well, I understand that, but, again, for background part of the way this discussion -- this particular point arose was talking about should the -- to fast track, should you be able to demonstrate that you have experience of dealing with that language using that script at the second level in a particular -- in a particular territory because that way you could say -- to pick up on Bruce's point, you got asked a certain point because you have experience in doing that. Again, it is all about fast fastness here. The answer may be no, but I am just explaining the background.
ERIC BRUNNER-WILLIAMS Yes, I understood the response. I still don't see the relevancy of that since, as you know, the demand is there. There's, basically, just the requirement not to screw up with the large volume.
CHRIS DISSPAIN Thank you. So let's move on to the next -- the next set of questions. And this is where we're talking -- we're starting to talk about -- effectively talk about -- I don't want to use the word "contract" because the term "contract" is massively politically charged charge one for the ccTLD community. We are effectively talking about here what do you have to do in order to get your -- the management of your TLD from a compliance, security and stability point of view and take a specific example, I ran a workshop at the Internet Governance forum in Brazil at the end of last year on the fast-track, and I said at the end of the day -- we had this amazing discussion about, I want 27 of these, if he's got 3, I want 6 and all of that sort of stuff. At the end of the day, the one thing that we hadn't talked about and the one thing that everything needs to know and needs to be talked about at some point is this The ghost of Jon Postel is not going to send you an e-mail to say "Hello, here's an IDN ccTLD, would you like to run it"? That's the first thing. The second thing -- because you have to understand for those of you that are not part of the ccTLD community, that the ccTLD community, basically, has been originally given these things and there has not been any kind of negotiation with ICANN, et cetera. In fact, the vast majority of them were there way before ICANN and still are by the same people. So at one end of the continuum, there's not going to be a ghost of Jon Postel e-mail. Equally at the other end, there is no way that the ccTLD manager/governments of these sovereign nations are going to enter into something that looks remarkably like a gTLD contract or for that matter something that looks like the sort of contract that ICANN was suggesting ccTLD should enter into about five or six years ago. Somewhere in the middle -- somewhere in the middle, there is a thing, whatever it is, that needs to be created to ensure amongst other things. So what that is and how that works is not necessarily the job of this working group. The job of this working group is probably to say "we recommend that, a thing be created to ensure that this happens." Now, for me personally -- speaking personally, we spent -- the ccNSO spent a very long time working out -- working out this thing called an accountability framework, which carries in its context, varies in its length. But nonetheless, it exists as an exchange of signed pieces of paper between the ccTLD and ICANN. So it makes sense to me, speaking personally to use that as the starting point of any discussion for what needs to be in place. It also makes sense to me to say if it's an ASCII ccTLD, there is a minimum requirement that ICANN has that your accountability framework, assuming that you are prepared to enter into one, must say this. So that is your starting point. And from there you can build, "well, what does it need to say specifically because it is an IDN?" And this ongoing -- this ongoing stuff is obviously -- is obviously relevant. So that's my take on these particular questions and I'm really happy to hear from anyone else who has comments to make or anything. Are we going to ditch this now? Yeah, we'll ditch it? I don't believe it is working. It has a yellow light. Half a mike is no mike. We have sound. Good. So would anyone like to comment or to -- no? So everyone agrees then? Excellent! Just again, just to be clear, this working group is not going to be coming back with a series of recommendations about what should be in some sort of document between ICANN and the ccTLD manager, but it might be coming back with a recommendation that these things need to be dealt with in some way with some kind of agreement between the two parties. Janis?
JANIS KARKLINS Thank you, Chris. Concerning the contract issue, we had in the GAC yesterday very lengthy discussion on this. And the outcome of discussion -- we couldn't reach a final agreement on that, but the outcome goes in the direction that there should not be a compulsory agreement. But, rather, the approach should be if an IDN ccTLD operator wishes to enter into contractual relations with ICANN, he should do that. Otherwise, that should not be imposed. So this was the essence of majority of interventions of what took place in the GAC.
JANIS KARKLINS Maybe this would be a good opportunity to have a little more arguments in favor of that agreement because today we know for ccTLD operators, there isn't a requirement to have a contract with ICANN.
JANIS KARKLINS And many GAC members felt that this should be perpetuated and proposed to the IDN ccTLDs.
CHRIS DISSPAIN Dr. Twomey would like to say something on that issue. Paul, if you would like to, that would be great, thank you.
PAUL TWOMEY Thanks for that. Thanks, Janis. I think people do know that at least personally I have been someone over the last five years who's not been someone in favor of trying to impose heavy burden agreements on cc's and, indeed, pretty emphatically moved to have the previous draft of the previous contract that existed from seven years ago dismissed as an approach and have worked quite a lot on this idea of accountability framework which we very much appreciated the ccNSO work. So I think people should -- I think people would recognize that the last five years or so, staff or board of ICANN have not been a force for imposing ICANN positions on cc's but, rather, a point of engagement. I say that, however, to say "however." And the "however" has a clear thing. It is actually not about a question of, if you like, sovereignty or choice but really a question about protecting national interest. The thing that I am personally concerned about and I think to a degree, Chris, your slide sort of indicates it which is this technical requirements question. What I don't think any government or cc manager really wants to get caught in, particularly in this large amount of uncertainty that we shall have as IDNs are brought in to be caught in the situation where their customers/consumers are vulnerable to be actions being taken by another TLD next door over whom they have absolutely no control and to which we have no means of saying to that TLD operator "Please, you are supposed to do something minimalist." The thing that I am particularly concerned about is operating an IDN TLD according to the RFCs. So technically sticking to the ones in which they should be operated. I may be speaking personally. Other people on the board and others may think there are other things that are important, but just that particular issue. For me there is an issue about consumer protection and we are going to see, especially in different parts of the world where there are different languages with common characters right next door to each other, this Indian nation region is a very good example. I think we do have to be a little careful about this because we will end up with this example. It has been the view of the ICANN SSAC and others, for instance, that wild cards, as an example -- I am now shifting away from IDNs -- that wild cards are a stability issue for the DNS, a threat to the DNS. And, yet, there are many wildcards sitting in many cc's for marginal commercial regions over which we have no way of saying that's a bad idea. Yet, we get a lot of pressure about it. Now, I am not wanting to address that. That's a post-fact problem, but I think it is an illustration of we don't know what the next 20 years is going to bring us in terms of what people could do in the IDN space. But there is no doubt that while there are many very well-run cc's, there are also cc's that are, perhaps, a little less well-run or open more to commercial incentives where I think many governments where, if they thought about it, would be uncomfortable if there was no way of being able to say "Please at least stick to the technical standard." That's just a personal perspective.
CHRIS DISSPAIN Thank you, Paul. From my personal perspective -- again, for me speaking personally, one way to look at it -- to consider doing it might be to say that you size out the stuff that you consider to be the security and stability stuff and deal with that in one particular way and deal with everything else in a different way, but that's just off the top of my head. The gentleman behind you is actually first. Thank you.
JON BING Thank you, Jon Bing. I am intrigued by this issue and I think it is crucial to find the solution for it. That certainly is not easy. But I wonder whether you have considered whether third-party classification societies, like the societies that decide whether a ship is seaworthy or things which are dangerous, actually operated to standard, whether they could be a solution or part of a solution in such a context.
CHRIS DISSPAIN They might very well be a solution in the long-term. But to try and impose that on to a fast-track mechanism, might I suspect defeat the purpose of having a fast-track in the first place. Thomas?
THOMAS NARTEN Yeah. So Thomas Narten here. I just want to add a couple of these points. You know, I share the concern about technical requirements and making sure that operators adhere to them. The thing I wanted to sort of add to is to make it clear that, you know, sort of adhering to technical requirements is not sufficient to say they adhere to the RFCs or to the IETF standards and the reason for that is, there's a lot of things that are sort of best practices that are sort -- sort of fall in between the cracks of the standards and aren't written in the standards, you know, at a technical level. And wild card is a good example. The wild carding is not illegal, according to the standard.
THOMAS NARTEN You know, and so it -- some of those policies and some of those practices would likely be defined within this body here. They wouldn't just come from the IETF side.
CHRIS DISSPAIN Absolutely. And you've just raised a point which has triggered off something, a thought process for me, which is that, you know, remembering that this is -- that we're talking here for the fast track, one of the things that we say and we have said in many documents is, you know, one of the great benefits of this if we do this is that we've got a sort of smaller -- small enclosed ccTLD communities, we can run -- you know, it's an experimental thing. Is it going to work? How will it work? Et cetera. Well, it seems to me to be perfectly legitimate, given that, to say, "Because of that, we need you -- for the fast track, this doesn't answer the question for the full policy -- we need you to enter into some sort of an agreement to specifically cover the fact that, you know, this is a first, we don't know what's going to happen, et cetera," and, therefore, say, "In order for us to test all of this and make sure that it works, wild cards are out," for example.
THOMAS NARTEN Yeah. And so the last comment also is, I think some of these best practices are going to be very script-specific.
THOMAS NARTEN And they haven't actually been developed yet. What we're going to be developing it as we roll it out, so we clearly don't know what they all are yet and they're going to be a moving target over time.
CHRIS DISSPAIN Sure. And that is why the ongoing compliance is necessary because it's going to change as we all learn more about how these things work or don't work. Yeah. Okay.
BRUCE TONKIN [Speaker is off microphone].
CHRIS DISSPAIN Yeah. It's not so much about whether it's a full-blown, you know, bound up with green tape legal document. It's just a function of the -- of the... Okay. That seems to have closed off that one. We missed a -- if you go back to A again. We missed just a couple of things on the string selection mechanism. We dealt with that one. Go back. So we've covered that. Does anyone have anything to say about this one? This is very much a ccTLD issue. It doesn't come up at all in the gTLD world. There's an organization who wants something, they apply for it, they either get it or they don't. The way that cc delegation works is that the -- there are a set of requirements that need to be met demonstrating that the -- apart from the ccTLD manager's technical competency, which we've already talked about, demonstrating the acceptance of the local Internet community, et cetera, et cetera. Eric?
ERIC BRUNNER-WILLIAMS Thank you, Chris. Again, Eric Brunner-Williams speaking in a personal capacity. While the example that I gave of Din? and Din?tah and Tsalagi in the United States is a minor language in our context and even unified Canadian aboriginal is a minor language in the Canadian context, it may be the case that there are major languages which do not have access to the corresponding government or the ccTLD operator, and would not have access to proposed -- so I'm suggesting that the list of actors for a territory who need to be involved is not exhausted when one says, "The GAC or the existing CC or any other one who comes forward with some official language representation which excludes perhaps Tibetans in China or some other larger language group than the ones that I represent."
CHRIS DISSPAIN Yes, yes. And the point you make is also relevant because under the current -- under the current principles and guidelines that are used for delegation, the local Internet community means the local Internet community in the territory. Now, in the case of IDN ccTLDs, the local Internet community might mean the local Internet community in a particular language-speaking part of the territory. In the case of Russia, it's not because it's the territory, right? But in the case of India, to use India again, there may be a script and a -- sorry, a language spoken using a particular script and only in a particular area which might have, you know -- there's 20 million people in it but still not be -- so the local Internet community part of this might need to be retooled and redefined for the purposes of IDN ccTLDs to take account of the fact that it may be a part of the territory rather than the whole of the territory. Yes, Dimitry.
DIMITRY BURKOV Chris, I want to add because I think it's necessary to take into account an interest of a territory language. I want to exclude these issues from fast track but it should be covered because from another side, we have dozens of languages on a territory basis. But not on fast track. If we will discuss all in one package, it's impossible to implement.
CHRIS DISSPAIN I understand.
CHRIS DISSPAIN Okay. No problem. Well? Anyone want to -- just one final thing before we finish, which is does anybody have any comments they'd like to make about the objection procedure? Dennis -- about the objection procedure or anything else at all that we have either not covered or you think we should be talking about. Thank you, Bill. Anything at all relevant only, obviously, to the fast track. Otherwise we'll be here all night. Dennis.
DENNIS JENNINGS Dennis Jennings, again speaking in a personal capacity. Has any consideration or thought been given to the fee structure that should apply between ICANN and the ccTLD and IDN or IDN fast track process?
CHRIS DISSPAIN Not really, except of course the kind of the same argument applies, which is that there is a current ccNSO guideline about how you should -- how you should voluntarily pay fees, et cetera. It's not part of the scope of this working group to figure out the terms of a contract or whether there should -- there should be a fee, and if so, how much that fee should be. That is an issue for ICANN and discussion, but not for this working group. But it's an exceptionally good point because is it going to be free? Is it going to cost a million dollars?
DENNIS JENNINGS Well, it is costing money.
CHRIS DISSPAIN No, no. I mean cost to me as opposed to --
DENNIS JENNINGS I know. So I mean, the ghost of Jon Postel is hanging around, but I'm willing to suggest that the existing ccTLDs are a special prehistory case, but I think the issue of contract relationship and fees should not be obfuscated and should come out in the discussions. I'm not saying in this forum, but should be discussed at length at some point in time.
CHRIS DISSPAIN I accept that completely. And if I may be -- if I may be blunt, speaking personally, in the case of the existing two-letter ASCII ccTLDs, we have them. You don't. And, therefore, you know, we've got them and what happens happens. In the case of new ones, you have them, we don't.
DENNIS JENNINGS We have them, you don't. [Laughter]
HARALD TVEIT ALVESTRAND Harald Alvestrand, a Latin script user.
CHRIS DISSPAIN You're forgiven.
HARALD TVEIT ALVESTRAND About objection procedures --
HARALD TVEIT ALVESTRAND -- this is supposed to be fast track.
HARALD TVEIT ALVESTRAND There will be a number of cases where it's obviously the right thing to do.
HARALD TVEIT ALVESTRAND And the whole purpose of the exercise is to get those through as fast as possible. So we need the flexibility. We are pretty sure that the rules -- any rules we come up with are either going to be incomplete or too onerous for the fast track so we need the possibility to toss out applications where it didn't make sense even if they follow the rules.
CHRIS DISSPAIN Too controversial, et cetera. Yeah. Thank you. Bill?
BILL SEMICH I have a little bit of not flotsam and jetsam to throw your way. In Item 3, in the second paragraph.
CHRIS DISSPAIN Hang on a second. Let's try to get the slide up. Is that C, string proposal.
BILL SEMICH Yeah. Just the first paragraph. Mechanism for the selection of an IDN ccTLD string.
BILL SEMICH I think we're kind of -- have -- we may have the cart before the horse here.
BILL SEMICH I was thinking that maybe we should be coming up with criteria to exclude a country or territory from fast track, just in order to minimize the kinds of things that we're going to have to go through, like objections.
BILL SEMICH What do we do to exclude them?
BILL SEMICH And then riffing on Dennis' comment about fees, again, partly as an effort to minimize the number of applications that go through this fast track, and partly as a mechanism to help ICANN deal with the potential flood of fast-trackers, I really think we should consider all agreeing in advance that ICANN should be allowed to charge a fee for reviewing these, for going through this process as they do for gTLDs.
BILL SEMICH And the fee should be substantial enough to pay the cost of doing it.
CHRIS DISSPAIN Okay. Thanks, Bill. Hong.
HONG XUE Thanks. I'm Hong Xue from the University of Hong Kong. I have one question, one comment. Would you please go to the part of objection procedure? Okay. So we can see objection procedure for the selection of IDN strings. What's interesting is that we can't see the similar procedure for the selection of IDN managers. So does this mean for the selection of IDN ccTLDs managers there won't be a similar procedure.
CHRIS DISSPAIN Why would you need an objection process for the selection of the manager if the manager has passed all of the IANA and any other technical requirements? Why -- and who would be able to object?
HONG XUE Who would be able to object. I assume that maybe another stakeholder who believed that he has better capacity to run the IDN in that ccTLD territory.
CHRIS DISSPAIN And that would work in a fast track approach. If -- basically, you've got -- I don't actually see how you could have -- I don't see how you could have an objection process for the manager if the -- the purpose of having an objection process for the string is different, because the string itself could be, you know, too close to another country and all sorts of things but the manager seems to me -- I don't actually understand why you would need to do that. But Paul seems to have something that he wants to say.
PAUL TWOMEY Sorry. Perhaps it's just worthwhile pointing out what happens for further comments for delegation under the IANA processes because it might partly address your question.
PAUL TWOMEY The ICANN board will have to consider these strings as being delegations.
PAUL TWOMEY Delegations under the IANA procedures will require evidence of local Internet community support for the string and the manager, and the support of the government. So there's a fairly high test, and I can tell you that in situations where there is conflict in the local community as to who should the manager be, and we get that now in the two-letter strings, the IANA procedure is we send that back to the community and we say, "Please try to sort this out amongst yourselves."
HONG XUE Thanks. I have another comment. On the IDN ccTLD managers. Chris, I hope you can record that user community has always been very strong supporter of the fast track approach.
HONG XUE We do believe there shouldn't be any more delay. That's very true. But, on the other hand, we hope the fast track approach will not be conflicting with the long-term solution. It is very important we see the principle at the beginning of this document. We're saying that the fast-track approach will not preempt the future PDP. This is very good point, but please consider about another perspective. That is the stability continuation and consistency of registration services. From the user perspective, we have serious concern about the change of registry after the fast track. Say a user have registered an IDN through an IDN ccTLD manager that's been selected in fast track process and later on we have a PDP. That manager could be replaced and the registry will be changed and who is going to protect the privacy and the personal data that's been submitted to that registry? So I -- I hope you could consider about that danger.
CHRIS DISSPAIN Okay. Thank you.
GUANGHAO LI Guangzhou Li here, speaking in my personal capacity. Actually, I have a comment about objection procedures here. First, I would like to actually appreciate all the efforts that has been put into this thing, which is I know that representatives with efforts like from ccNSO, GAC and GNSO, ALACs, all the representatives has put in all these things. Which is I -- somehow, I feel has not been very different from what we had last year with the issue paper. I mean, essentially. But the thing is, I want to mention if we wish to put something really forward and I think to open for all the community to get involved, it's a good objection procedure, which is probably anybody in the community can raise an objection on any basis, but who will be the body to judge that objection should be lodged or it's legitimate? I mean, who can or what grounds. But it doesn't mean -- it doesn't say anything about who will judge that objection, should it be lodged, on what criteria.
CHRIS DISSPAIN It says if an objection is lodged, what is the impact? Which means what happens next.
GUANGHAO LI Yeah, but --
CHRIS DISSPAIN But I understand what you're saying. Right.
GUANGHAO LI Yeah. But then if it's legitimate, I mean some body says "Okay, that objection is legitimate," then what will happen next, right.
CHRIS DISSPAIN Well, that's -- but that's an extremely good question and again, it gets back to the fast track. Do you say, "If there's an objection, then it doesn't go through in the fast track" or do you say something else? I don't know. But the -- it's a perfectly valid question to ask. Thank you.
GUANGHAO LI Yeah. I mean --
GUANGHAO LI -- the thing is like who will judge that? I mean somehow some objections will be raised, but some are legitimate and some just nonsense. I will say that.
GUANGHAO LI Then who will be judge that that objection is legitimate, it should be lodged and then should we have a one-month or two-month objection resolving period that we can resolve that.
GUANGHAO LI And then after that, we -- if the objection is legitimate and sustained, then we can call the objection sustained and then we put it off -- out of the fast track.
CHRIS DISSPAIN Okay. So what you're doing is proposing an outline of an objection process.
GUANGHAO LI Yeah. I would say that, yeah.
CHRIS DISSPAIN So if you could put that in as a comment on the e-mail, that would be very helpful.
GUANGHAO LI All right. Thank you.
CHRIS DISSPAIN Thank you. I'm going to pass this back to our cochairs now, since we've completed everything that we set out to do.
MANAL ISMAIL Okay. Thank you, Chris. And thank you all for this very healthy conversation. Just a few quick remarks. I think we all agree that the fast track really needs to be fast, and as fair as possible. And although this is the fast track and there is still the PDP to be finalized yet, there are some irreversible decisions that have to be made, such as the delegated strings, for example. It seems to me that the criteria with which we are going to limit the number of introduced IDN ccTLDs for the fast track seems to be the bottleneck for this period, so I think it's going to be a priority for the group to get this resolved, and I think once -- once we all agree on the criteria and how we are going to go forward, this would definitely make things easier. Again, I think it might help a bit to know how long is expected for the PDP to be finalized. Maybe this would make people more confident to wait for the PDP if they are not going to fit within the criteria of the fast track. I would then hand to my colleague.
YOUNG EUM LEE Thank you. Thank you again. I think a number of very useful suggestions have been made, and we will make sure that the working group takes a good look at them, and maybe take some actions on it. For example, the creation of a table for the possible number of cc's, and maybe we could come up with a definite or like a rough number of cc's that can be introduced initially. And for those cc's that are potentially controversial and that don't go through this process, as Edmon says, they're welcome to apply for the "g" IDNs, and so I think again the working group will take all of your suggestions into consideration and please we still have until February 25th to get your comments, additional comments. Please make them. And when we come up with an interim report, please make note of that and hopefully we will have our job done in June. And before we end, I would like to thank Chris for a wonderful job of moderating this session. Thank you, Chris. [Applause]
YOUNG EUM LEE Thank you, everyone.