IDN ccTLD Fast Track Workshop Sydney, Australia 22 June 2009 >>TINA DAM: All right. I think we're ready to start. Welcome to the IDN ccTLD fast track workshop. My name is Tina Dam. I am with ICANN staff and I'm in charge of the entire IDN program, of which this project, of course, is one of them. This is the agenda for the workshop. We're going to go through a very brief status on the IDN ccTLD fast track process, of where we're at, and then we're going to look at some of the outstanding topics that we're really forward to your feedback on. The first one is a review of the process for requesting an IDN ccTLD. The second one is proposed details about DoR, the documentation of responsibility. The third is IDN cost and cost recovery. And the fourth is the proposed details around IDN tables and how to manage IDN TLD variants. And so we have a set of slides for you to go over these topics, and as soon as we're through those, there will be open microphones for questions, and you can of course ask any kind of questions on the fast track process, not just on these topics. But we did select these topics because we thought that these would be the ones that were most interesting for you to talk about today. And I have with me a couple of colleagues. Bart Boswinkel and Kurt Pritz. And Kurt was just here so he'll probably just on his way back in again. So we're going to share the slides, and there's a few other ICANN staff members up here who are part of the IDN program to help answer questions for you. So this is just one slide on the status of where we're at. You may all know that right before the Sydney meeting, we posted a revised draft implementation plan for the fast track process, and together with that a set of explanatory documentations. The draft implementation plan itself, the main changes that are -- have been made since the last revision have to do with operational and administrative elements in it. So we've put a lot of details into it regarding how to manage the ongoing evaluation for the string, which is the part of the process that takes place in ICANN, and got those details out for you. We also have a draft application online form that you haven't seen yet, but I'm going to give you just a brief view of it, and then I think shortly after Sydney, we're going to be able to post it so you can see it. That doesn't mean you can use it, but just to give those who are interested applicants or participants in the fast track a good idea about how does this online form -- what does it look like and, you know -- I know you know the kind of information you need to put in there, but it's always better to see what it's like. And then one of the things that were questioned mostly in the draft implementation plan last time around was eligibility requirements, so in the revised version, we have clarified that and hopefully good enough. But let us know if you have any questions on it. And then this is a list of all of the remaining tasks that we have. And it's sort of like a brief overview. I'm not trying to pretend that it's complete, but I think it's fairly complete. We'll need to get the online application form out and we need to get the interface to the gTLD or the TAS system in there as well. As I said, some of that will happen shortly after the Sydney meeting. Then the second bullet may be a little bit more sensitive. It's the IDNA implementation. As now, the IDNA protocol is under revision, and we need to soon start to make a decision as to which version of the protocol we're going to implement and which one are we going to ask you to use. That, of course, is going to finalize the technical string requirements for this process. Then we have a pre-evaluation process, formation of the stability panel, and finalization of linguistic processes. The last one is one that we also got a lot of questions on in the last round, and we have not been able to finalize it completely into answering all of your questions, so, you know, I apologize about that. You can still ask questions, of course, but we're not completely finished with how that process is going to work in enabling all of the contacts that are necessary for that piece to function. And lastly, on the status update is that we are still aiming at finishing this by the ICANN meeting in Seoul, Korea, which is going to be end of the year, this year, calendar year, 2009. All of the elements that are remaining as tasks have been scheduled to meet that goal, and as you know, this was also what the ICANN board asked us to be able to manage at their meeting in Mexico City. Okay. So a quick review on the fast track process. I know this may be a little bit hard to see on the slide. It's -- well, from here, it's pretty good. [Laughter] >>TINA DAM: It might be hard in the back of the room but it's not that big of a room and the slides are going to be posted to you'll be able to see it as well. But this is just to show you there is, right now in the draft form, four steps. The first step is where you provide all of your contact details. The second step is the one that the screen dump is up here, and that is where you enter the IDN ccTLD string details, so all of the A-label, the U-label and so forth, all of the details around what language and script the string that you're requesting is associated with. Step 3 will be where you upload all of this important documentation. And Step 4 is a basic review, where you get, you know, everything you entered up on the screen and you just have a chance to review it before you submit it. So it's fairly simple and it's -- and it's intended to be fairly simple. But as I said, we're going to get this finalized and get it out to you hopefully fairly soon. The process, as soon as you have submitted it -- submitted a request to ICANN -- goes as follows: It's going to go through these four overall steps. The first one is to request completeness validation or verification. That is basically ICANN staff just checking off that everything that was necessary in the request is actually provided to us. So if there's anything missing of any supporting documentations or so forth, you're going to get an inquiry back and we're going to ask you for that material before the string or the request for the string continues in the evaluation. So the first step in the evaluation is the linguistic process validation, and it's important to know understand here that we're not going into validate the linguistic requirement but we're validating that the process that was assigned to it is done in the correct way. So for example, that the language and script are determined official within the country or territory; that the string is a meaningful representation of the country and territory name that is associated with your request; and that the community support documentation that has been submitted is adequate or acceptable. So these are process checks. So first, check that everything is contained in the request; then a process check on linguistic material; and then the string that is requested goes into the technical stability review. And that's by the stability panel that yet has to be formed. Now, in this technical check, there's also a check against confusability. So this is a quicker way of determining whether the string that is requested is confusingly similar to anything that is existing in the root zone or anything that potentially is under application in the fast track or already in the gTLD process, once that is opened. And then the last step is basically that if everything is -- in those three steps are completed successfully, we call the string "validated," and validated strings are published on the ICANN Web site. And we're looking at monthly publication, so that it's not just like a one-by-one but we're going to -- while you can apply at any point in time, we're going to try to get things up in batches, and that is in order to process and streamline -- streamline the process a little bit more. And that was what I had on the process update. I'm going to ask Bart to come and talk a little bit about documentation of responsibility. >>BART BOSWINKEL: Documentation of responsibility. Just to sketch you a bit of the background of the paper that was published by us on the -- before the ICANN meeting, probably you'll recall that just before the Mexico meeting, we put out a first document on the documentation of responsibility. The reason for doing this is that the IDNC working group did not include in its recommendation anything on the arrangement between the IDNC manager and ICANN, so that is a bit of the background. What we requested at the Mexico meeting was feedback and input and the -- so the paper published before this meeting is taking into consideration the feedback and input we received on the first one. The feedback and input we received focused mostly on the need for an arrangement. So if you read the first document, you may recall that it contained two sections. One was on the need for the arrangement, and secondly was on the substance of such an arrangement. The documentation of responsibilities as well. So the second one -- and the comments we received was particularly on the need for such an arrangement, but that is reflected, of course, in the document itself. Now, based on the feedback we received, there is -- say, the way we interpreted is there is a general acceptance that a commitment to adhere to the relevant technical standards and the IDN guidelines is essential, so based on that, we move forward. The second one is that the need to define and describe the roles, that was, again, one of the reasons for introducing a documentation of responsibilities at the start of the process, is broadly accepted, but there are some people and other interested groups who have a problem with it. And it was very clearly there are divergent views on how an agreement or how such commitments to adhere to technical standards would be enforced or could be enforced. So based on this, the new DOC -- the new position paper proposes, in fact, two new -- or two mechanisms to include specifically the commitment to adhere to standards and a lightweight mechanism to it in the event something goes -- there is a need to communicate. The two proposed mechanisms, one of course is, again, the signed DoR as proposed under the first position paper and the second one -- and that is a new one and it is linked with the online form that Tina just showed you. That is that in that form, there will be language on terms and conditions describing the commitments and obligations of IDN ccTLDs and ICANN when the request is submitted. So it's a kind of tick the boxes "I agree with these terms and obligations." Note that is -- and I think that was specifically encouraged by the GNSO -- or by the GAC and by the ccNSO that the current situation with cc's is there is a voluntary arrangement that even if it would go for an express of these specific terms and conditions, it is strongly encouraged that IDN ccTLD managers and ICANN enter into an arrangement such as the DoR. So -- and I hope -- yeah -- that that will work. Say based on the new paper, we asked community feedback on the following points: Should additional county be included in the agreement to ensure the DNS stability and security? In the position paper -- or in the paper itself, the DoR as proposed in Mexico it is included, so if you think new elements should be added, please use the public comment period and the public comment possibilities. And then the form of agreement should include both options or should there it be limited to one of the two? We'd like your feedback on that as well. And the open question is: By what means can ICANN -- or can we achieve adherence to the relevant standards and IDN guidelines? How can it be ensured? As I just said, one of the mechanisms that is proposed, at least in the -- say in the new paper is what is called the cooperative engagement. It is a lightweight manner, or at least a commitment that in case there is an issue or an event that ICANN and the IDN ccTLD manager commit to engage and communicate to try to resolve the issue. What is not included is, for instance, the arbitration as suggested in the DoR. That's it for me. >>TINA DAM: Thanks. Yeah. So those were the two first topics, and we have two remaining. The next one is IDN costs and cost recovery, and Kurt is going to come and speak to you about that. >>KURT PRITZ: Thank you, Tina. We drew straws and I lost. I got the short straw, so I get to talk about fees and costs. the most popular topic, I think. So leading up to the meeting here, and in preparation for this discussion, ICANN published three separate documents, and they're all intended to accomplish separate objectives. One was the expense area group or expenditure analysis by stakeholder interest area, the EAG paper, which attempts to take ICANN costs and allocate them to different stakeholders. I'll talk more about them in a second. But really, it's a cost allocation mechanism. Taking all of ICANN's costs and allocating them somewhere. The second is a -- a cost analysis specifically having to do with IDN ccTLDs. How much did it cost to develop the IDN program and specifically the IDN fast track program? And then also, what are the processing costs associated with IDN ccTLD requests? How much does it cost to process that request? So it doesn't address all of ICANN's costs. It only addresses and seeks to calculate the costs associated with the IDN program, the IDN ccTLD program, the IDN ccTLD fast track program. And then finally, there's a paper about financial contributions, and that is: What would a model be for contributions to ICANN by IDN ccTLDs and also ccTLDs? So how can that best be done? So three separate papers with three separate objectives, but all dependent on one another in their calculation for their -- their results. So the first one is this expense area group paper, and the purpose of this analysis, you can call it whatever you want, either to assign or allocate or identify or associate all the ICANN costs with a stakeholder group or a customer group. So it seeks to take all the ICANN costs and put them somewhere. What costs are in support of gTLDs in general? What costs are in support of gTLD registrars? What costs are in support of ccTLDs? What costs are the support of other stakeholder groups, the RIRs? So it takes all of ICANN's costs and allocates them somewhere. And almost every group, I'm sure, would look at these costs and be shocked and say, you know, "I don't think that much cost should be allocated to our group." But then we can have the kind of discussion we want to have, right? Not "are these the right costs to be allocated to me" but the costs are associated with an activity, and so should ICANN continue to -- should ICANN continue to provide that activity or not. So it differs from a traditional accounting in that, you know, traditional accountings are educating to functions such as finance or the IDN program or contractual compliance department. When we build up our budgets every year, we build them that way. This is allocating costs by customers. So I'm going to show you some charts that are much too small to see, but they're part of the deck that will be published and also they're a part of this report that was published earlier, this EAG report, that suggests that of ICANN's efforts of the 50-something million dollars, 17% of it goes to the benefit of ccTLDs. So that's the chart you can't see. The biggest pie, 34%, goes to supporting the gTLD activities and space, and then there's -- travel is another big chunk, but the -- what color is that? Magenta? Purple? Is -- goes to ccTLD support. And that's just another way of looking -- looking at that chart. It's allocated that way. How did we come up with these numbers? You know, we took the labor time for every man, woman and child on the ICANN staff, and put their time towards something. So personally, most of my time would go to the gTLD space, I think. Some because I'm associated with the IDN program might go to the ccTLD space, but a small amount. And so on for other groups. So we took every manpower hour or womanpower hour and associated it with an activity. All the consulting dollars, consulting dollars are often easily attributable to an effort, right? So we can assign those dollars to one of these activities. The same thing with travel. Then when we get done with that activity-based stuff, you know, we have some overhead left at the end -- our finance function, our HR function, our senior executives -- and we allocate that over the whole, as any organization would, by various -- by, you know, an overhead allocation method. So that -- so that's it. So the first paper, the EAG paper, was a lot of work, a lot of cost accounting work, and it sought to allocate all our costs, so we kind of have a model for how much ICANN spends in support of each stakeholder group or set of customers. So that's one. The second is IDN cost analysis. How much does ICANN spend on IDNs or is spending on IDNs? Well, there's two kind of costs here, I think. One is the development cost for the IDN program, and the second is, when we start receiving requests for IDN ccTLDs, there will be effort associated with that, and that's cost. So the answers -- I'll tell you the answers first, and then I'll show you some of the details behind it. But the answers are we've spent over the last several years $6 million in developing the IDN program. That's labor, travel -- travel, consultants, other costs, but all direct costs, no overhead costs. And, you know, in this, we suggest here that half of it is allocated to gTLD space and half of it is allocated to the ccTLD space. There's an extra parentheses in there, if anybody wants one. And then what about processing costs? Well, we've built a model. We've built an application model, a request model, and then what ICANN staff is going to do with it and what consultants ICANN is going to hire. The technical guys that are going to look at the string to make sure it doesn't break the DNS and the language capability we're securing. And we've calculated an amount that we think is equal to about $27,000 spent per request. And so here -- the detail behind both those numbers are here. You know, on the development costs, you know, there's labor, meetings, workshops, this. You know, there's a tiny bit of money we're spending here in this meeting right here so that got shoveled onto the pile. And then consultants, contractors, and the like. So if you look at it over a period of time, if you can see that -- if you can see that, you see this is really calculated over three years' time, so the first time I saw the numbers, I went (gasping) 2.4 million in personnel costs, oh, my god. But then I saw it was allocated over four years and, you know, now it's only a few -- you know, a few people, essentially, working on this full-time. If you add up a bunch of parts of times. And the same thing -- so the $6 million is spread over four years' time. So that's how that number was derived. And then in the processing costs, we -- there was an assumption made that there's 50 applications, and then as I stated earlier, we calculated the variable effort associated with each application. We have some fixed costs, not had very high, 115,000, to get the thing started up. And so that 115,000 is spread over the 50 applications, or requests is a better word, right? And so we developed a cost of 26.7 million. So those costs include no development costs. It's just the straight evaluation costs. And we also don't have any IANA costs in there, so this is the money, the effort required to take the request through the evaluation that needs to occur. And then once it's validated, then it goes on -- then the request goes on to IANA, which -- and there's no charge for IANA services, as we all know. So that's how that cost is developed. So now we -- now we have, like, two ICANN cost models. One is all of ICANN costs, how much is attributable to ccTLDs, how much is attributable to gTLDs, and then we have another cost model that just focuses on the effort associated with the IDN fast track. So this is the part where ICANN suggests that contributions be made to its annual operating expenses. So we say we've got these two lumps of costs, this EAG, the ongoing support of ccTLDs and IDN costs. So what the paper that was published prior to this meeting suggests is there's two areas of contribution, one to cover the cost of processing the request for an IDN ccTLD, just those costs that are spent directly on processing the application, the 26.7K, about, and an annual contribution to contribute towards supporting the operations costs. The operations costs are that 17% of ICANN's budget, which comes out to be about -- which comes out to be about $9 million. So what's that mean? So this is sort of a reiteration, and I apologize for it. On processing the IDN ccTLD request, the contribution would be just those direct costs with those development costs in there, no fee for IANA services. The annual contribution costs are based on that EAG analysis. How do we build up to $9 million? Well, the paper suggests that the contribution be about 3% of revenue. A percentage of revenue is in there really based on discussion among the community as a suitable model. I can argue on both sides whether a contribution model should be based on percent of revenue or a transaction-based model. There are several different models, and after a lot of discussion, it seems like this percentage of revenue model was decided upon. What's 1 to 3% mean? Well, if you think about trying to recover $9 million, if we receive -- if ICANN received contributions from essentially all the ccTLDs at 3%, we think that's about that much money. So this model does not seek to make the -- place the burden for contribution on IDN ccTLDs. In fact, doesn't put all the development costs on the IDN ccTLDs but, rather, it spreads the development costs and then the IDN ccTLDs share the 17% or $9 million, just that share on the ccTLDs. So if you think of all ccTLDs contributing some day $9 million to ICANN, just think, then -- I can't do this and talk at the same time -- but the IDN ccTLD contributions, say there is 50 of those and they are all small, they are all just starting up so they are contributing 1 to 3% of their revenue, would be contributing only a small amount to that. So it's asking the IDN ccTLDs for a recommended expected contribution of 3% as a calculation of what a fair share would be as a ccTLD, not as an IDN ccTLD. So I'm trying to make a really fine point, I don't know if I'm doing a good job of it. The reason that there is a 1 to 3% here is that community discussion again suggested that smaller registries -- the burden be considerably lightened for smaller registries. Not only smaller contribution proportionally but more than proportionally. So very small registries if you read the paper would be asked to contribute 1 or 2% and the -- and then as the registry grows, it goes up to 3%. So I think that's the end of my talk. I hope it was -- I hope I was clear. I'm not a cost accountant and just took one course in it. Are there any -- do we take questions at the end? >>TINA DAM: Yeah. Thanks. So that leaves just one more topic before we open the microphone for questions. And the last topic we thought would be interesting for you is the topic of IDN tables and how to manage variant TLD strings. I just have a one-slider on that. First up, how do we deal with variant TLDs? This has been a topic that's been going back and forth quite a bit over the last couple of versions of the paper that's discussing this topic and the draft implementation plan itself as well. I think the most important thing for me to say on it is that, first of all, it is clearly understood that there is a community need and in different regions, the need is much bigger than in other regions. But a community need for having the IDN TLD variants allocated in the root together with the actual string, that the other strings are variants to. And one of the reasons for it -- and the example I put up on the screen is that in some places it is really just difficult for users to type in a string. And all depending on what keyboard you have or what input mechanism you have, you may type either the actual string or one of the variant strings in. So in order for IDN TLDs to really be useful for users that don't really actually know if they're typing one string in or the other, they're just typing what they're used to typing, right? Then we would need to have both strings or all strings in the root. However, there is a technical problem with that and that is these strings are -- you know, they're not identical from a technical standpoint but they are identical from a user standpoint. And so they look the same. I mean, they're confusingly similar. And in order to put confusingly similar strings in the root, you got to make sure that they are -- well, we call it aliased or you can call it mapped but they are considered the same in the root as well. And we don't have a technical solution for that. These last couple of days, and actually before the Sydney meeting, there were already suggestions towards why don't you solve it with a policy solution as opposed to a technical solution. But a policy solution just does not guarantee that each one of the -- so if you put the two strings separately in the root and then you say "by policy regulation, if I make a registration under one, I need to also have a registration under the other," while you can copy that zone file at the second level, you can't really guarantee anything further down in the tree. And so at least initial review of that determined that stability of the name space is then not stable. So we don't have a technical solution, so the current proposal is that if there is variant TLD strings to the actual string that is requested, well, they will either be reserved for potential future allocation once these technical solutions are in place or they will be blocked. And "blocked" meaning blocked so that no one else can register that TLD or that string in the root. And that was the best possible solution we could come up with that would create some sort of, like, safety mechanism for those regions that need these TLDs to be allocated, is to at least ensure that no one else is getting the strings to avoid the confusability in the industry. So that's one. In terms of the IDN tables, these tables are, you know, in some cases, fairly simple constructions of tables of the characters that a TLD is supporting. And it basically is put into place so users can see and get the information about what characters are supported under each registry. And then, also, in those cases where there are variants, and it is not in all, but in those cases where there are variants, then variants are identified in these tables and that is to further avoid confusability. Some of you may have been in the IDN session yesterday where we saw a couple of examples of what that confusability looks libeling. But if you're interested in it, you can, you know, come and check with me at any time. I'll share it with you. Now, the IDN tables have traditionally been used for very good purpose at the second level. And we also want to use them at the top level. So anybody who applies or requests an IDN TLD -- and that can be either in the fast-track process or in the gTLD program -- will need to supply also an IDN table supporting the characters that they want to make available. And in that, the language right now is that it's a strongly encouragement for language communities to collaborate in the developing of these tables, especially in the cases where there can be confusability for users. And, for example, that could be in cases where languages are using the same script or it could be in cases where scripts are looking alike. And Cyrillic, Greek and Latin is one of those examples for that. Now, the feedback we've gotten so far -- and this is under public comment, right? And the public comment will end on the 15th of July together with all the other topics we talked about. But the feedback so far that we got on this is that ICANN needs to take a stronger stand on the IDN table development. And that, I think, is something that can be a little bit difficult because there is a lot of linguistic rules around how these tables are developed. And those rules traditionally have been set in country. So this is something that is decided locally. So if we were to move that into ICANN and have ICANN decide on the actual content of these tables, then we're talking about additional expertise and I'm not necessarily convinced that that is a good idea because that expertise sits out in the local communities. But it's one of the feedbacks that we've gotten so far, so we're really interested in hearing what you think about it. And that was what I had on IDN tables and variants. So we're going to move to questions, and at the same time a quick advertisement on the remaining IDN slots for this week in Sydney. There has already been several of them, and there's more coming up. So, for example, tomorrow, there is a technical session together with the GAC. On Tuesday, also, there is a lot of different constituency meetings and some of them have IDNs on their program. All of those meetings are open. And on Wednesday the ccNSO is looking at this fast-track process as we are talking about in this workshop and also on the longer term, ongoing IDN PDP. So those are the next sessions coming. But -- oh, I already have people at the microphone. Great. Eric, go ahead. >>ERIC BRUNNER-WILLIAMS: Thank you, Tina. Eric Brunner-Williams from CORE. I have two questions, Tina, first to take them in inverse order, can you identify whose comment that was that ICANN should take a stronger role in developing the variant tables? That isn't classified, is it? >>TINA DAM: No, that's not classified. In fact, we try to keep everything as open and transparent as possible. The comment came from the Arabic script working group as a part of -- they had a long set of comments in the last -- in the last round and it was one of those questions where it was really difficult for us to come up with a way of dealing with it. So it is still a remaining open question or proposal. >>ERIC BRUNNER-WILLIAMS: Thank you. Now, Kurt, at Mexico, I think I pointed out that you weren't appearing to cost in the contributions made by ccTLDs in the past -- well, going all the way back to the IDNA 2003 effort. That work, of course, was not done with the expectation that ICANN would be recompensating them, at least I don't think so. But when looking to cost out the total cost of developing introduction of IDNs into the DNS, it doesn't seem like it's correct to overlook that cost that has been sunk already by predominantly ccTLD operators and their linguistic communities, academic and otherwise, when attempting to determine the cost of ICANN's IDN program and, therefore, to then generate fair by whatever metric charge-backs to parties that are interested in using the technology that's been developed. I appreciate that it's easier to calculate ICANN staff time, but it's not impossible to estimate the amount of non-ICANN staff time that's been sunk in this effort and the value of it. So I hope that at some point, the numbers that we work with can reflect not just ICANN staff costs but the community cost. Thank you. >>TINA DAM: Thanks. >> WERNER STAUB: My name is Werner Staub. I'm speaking in personal capacity. First of all, I would like to make a call for solidarity in the context of IDN ccTLDs. We all have an interest in their success, even if you're from countries that do not use them. That's for the sake of the DNS. And the DNS has been a joint system, something we all have together. Now that we've discovered that we have a serious bug in the DNS because it does not accommodate necessary features for a number of participants who we want to have in the DNS, we want to correct that bug. We're shipping a patch, and then suddenly we are saying you need to pay for the patch. That's not nice. It is about all of us. We want the DNS to be working for all of us. It is simply unfair if we say to those people who have been disadvantaged up to now by the way it's been run, that they should be further disadvantaged for having to pay for the patch that we actually have an obligation to ship. That's the one thing. The other one is I'm little bit surprised about the statement that indicates of what you called variants of a TLD. Such is the case in Chinese traditional and Chinese simplified script that one and the same character -- I repeat, one and the same character -- is encoded as two different Unicode codepoints. For some of these reasons -- but it is one and the same character which leads to variants. It is not just Chinese. For instance, in Iran, you have to root Iran where again one and the same character had to be encoded in two different Unicode codepoints depending whether you use an Arabic keyboard or a Farsi keyboard, you get one or the other. These are cases where it is necessary for the operation of the TLD to have both variants active. Not one of them, not the other one of them, both must be active. So saying that it is a question of stability that only one should be active because you cannot guarantee that they would all be the same, well, it is not ICANN's job to guarantee that. ICANN is supposed to make available what has to be made available. In this specific case for China, for instance, it would be two delegations of two, as it appears technically separate TLD. From a moral standpoint, it is one TLD. Now, it is the registry that will make sure whenever a registration is made that there, again, are two separate delegations, two separate zones with the same name servers and the best practices to be used in that registry make sure that this is done on a contractual level and on an enforcement level in a fashion that makes sure that, indeed, it is the same TLD, they're not run by different people. So it is perfectly possible. There is no problem, stability in assigning for the case of Iran or Pakistan, the necessary variants in the case of China as well. In the case of Taiwan, there would be even more variants. They can all be delegated without any problem. >>TINA DAM: Thanks, Werner. We don't completely agree at least not on the topic of the variants. I agree with you that it is the necessary to have the variant TLDs in the root, but I don't agree it is okay to do it without making sure that things stay stable for the users. This is for the end users as well. While they have a need for it, because without variants in the root, it's going to be difficult for certain users in the world to access and enter the addresses. Well, we also don't want to be in a situation where users are at a disadvantage because there are confusingly similar strings in the root that are not managed in the right way. >>WERNER STAUB: If you look at what ICANN has done in this context from the beginning, since 2000, let's take the example of the delegation of TLDs inside .COM. Telefónica and telefonica which are confusingly similar just for a little accent on the O. It would be easy to make sure it is the same. It would have been easy. ICANN saw no problem there but couldn't trust with the registry to know what it has to do in its country to make sure that it is stable. They know what to do. >>TINA DAM: Okay. I'm happy to talk some more about that. Perhaps, the problem, of course, is not about trust and it is not about trusting registries to do things in the right way. It is the fact that there is no way they have control under the lower-laying levels in the tree. But in any event, I mean, it's a topic that is still open for public comment and I hope you'll perhaps put some more details into the online public forum so we can continue to debate and reach a solution. We agree there is a need for having these TLD variants in the root as well. Go ahead, Edmon. >>EDMON CHUNG: This is Edmon Chung. We are talking about this again. This is the topic I wanted to talk about and I think variants is very important. And I also agree with you, the security and stability issue is important. My problem or really question is if you take the logic that you just had in terms of not being able to ensure the downstream ones, then are you also suggesting that any variant implementation at the second level by registries also inherently secure -- are insecure or unstable? Because that is -- essentially if we take that argument that it would create stability issue in the top level, you would create exactly the same issue in the second -- for registries already implementing in the second level. So it is a very serious issue that we need to address because if you are saying this, then maybe the IDN guidelines or something -- registries that are already doing this today may have to be stopped? >>TINA DAM: You know what? That's a really interesting point to bring up. You know what may be interesting is to maybe look at has there been any problems with that, or how has that solution functioned for the community? And that would -- I think that would be a great study to take on. >>EDMON CHUNG: So, yeah, I just bring this up because, you know, in this perspective it might be more clear, especially, you know, speaking from Chinese perspective. I'm sure there's plenty of experience with that by now and probably people from China or Chinese-speaking communities can provide some experience in that. And basically alleviate the concern at the top level because that's quite important for -- that's the whole reason for having variants in the first place. >>TINA DAM: Right. Thanks. I'm not quite sure who was first here on the two microphones. Yeah, go ahead. >> SIVASUBRAMANIAN MUTHUSAMY: I'm Sivasubramanian Muthusamy. I am the IDN liaison from ALAC and asking a question in my unusual capacity. I will ask the question first and then go to ALAC and then ask them if my question is okay. Kurt was talking about cost accounting model which 1 to 3% of the revenues of the registry or ccTLDs shared with ICANN to recover the costs, and if you take a country like India, for example, our country is very enthusiastic about IDNs and in all probability the government of India, an agency of the government of India should be responsible for IDN registry. And they might give it away free to the registrars. But the end user or the registrant would inevitably pay about $10 to $50 per domain registered. So isn't it possible for ICANN to think of an alternate model, maybe 10 cents per registrant or 10 cents per IDN registered passed on to ICANN through the registrar, through the registry so that the costs are fully recovered. By that model, probably the cost recovered could amount to $50 million a year or $100 million a year and it also happens to be a very, very small sum for the end user. >>TINA DAM: So it is really hard to estimate the number -- the volume of registrations, right? So you bring up a good point because if the volume of registration is really high and IDNs become really popular and you get, yeah, huge volumes, then the cost that the EAG was specifying, of course, will be covered fairly quickly. Now, if that is the case, then fortunately ICANN has annual budget reviews so we'll catch that really quick, if that actually is the case. If it's not the case, well, then, you know, it is going to take a longer time to recover those fees. >> SIVASUBRAMANIAN MUTHUSAMY: The point is the revenue per registration -- the registry level would have 5% to the cost of the registrant. So if the registrant pays about $50, the registry would be giving it away at $1. Already it is about 5% of the end user's expenditure on IDN. So you're talking about 3% of that 5%. So hardly if I'm paying $50 as a registrant, ICANN would end up getting 5 cents, so that's not what I'm talking about. So that could be an alternate model and need not be considered negatively as some kind of taxation or something, but it is a very, very fair method of recovering costs and it could be very light on the registry. Some countries can't afford upfront costs. If you are going to say give us $100 million per IDN for evaluate or to recover costs initially, and then give us 3%, that might not work for them. So instead you can keep it light by saying, okay, give us 25 cents or 10 cents per IDN registered and then it is going to add up to $100 million because at least you will get about a billion IDNs registered worldwide in a couple of years. >>KURT PRITZ: So numbers with all those zeros make me feel all warm inside. [laughter] But I think you are exactly right. I think there is probably a problem with any rigid format for contributions and that given the model and the spirit of the amount of fees that are trying to be collected to support ICANN activities in support of ccTLDs, that registries be given discretion for different models, especially, you know, given what you're saying. You're trying to sell a different model to your community. You don't want it to appear as a tax. You want this whole thing to appear as a benefit. I think registries should be given -- well, they are going to take it anyway, but registries should be given discretion in achieving whatever contribution goals we've set. Does that make sense? >>TINA DAM: Let's go to the other microphone. >> ANDREY KOLESNIKOV: Hello. I'm Andrey Kolesnikov, I'm representing the Russian Federation. We will apply for the IDN dot rf. A couple of notes. For the DoR, of course, it is nice to click the buttons on the online forms, but all legal requirements is very simple. We need a piece of paper signed from both parties. Of course, we'll click the buttons. But after that, we will need the paperwork because it's a civilization and legal people going after us, of course. And, also, a couple of ideas about this financial contributions, I think it's a fair model, honestly. 1 to 3%, it really, first of all, it ranges the volume of the registrations and because of that, it looks fair and also talking about the variations, maybe it's possible to have some kind of pro forma contract going back to the DoR the responsibility of both parties, obviously I know what ICANN really needs. It's a lot of questions about the stability and responsibility of the local registry to not break the Internet, speaking in simple words. And I think this is an absolute requirement, should be signed by the local ccTLD and without it, no paperwork should be preceded well, because there is no cases still but it doesn't necessarily mean there will be no bad situations. Going back to the 3% of calculated, we expect about 1 million registrations during the first three years in the IDN in Russian federation. We did a simple calc. This is because basically 90% of the people in the Russian federation, they may know the ASCII characters, but they would obviously prefer to type in the Cyrillic script and it is preinstalled on the keyboard. When you turn on the computer, it is the first thing you'll see. You have to do some tricks to switch into the English or other ASCII characters. And the third point about variances in the encoding tables and the characters itself, I think it will be a good idea at some point to say, "Okay, here's this -- this is the clean situations and we go with the IDN ccTLDs. They solve the problems, they don't have any problems, they all agree, and do not wait until all the world will agree on the certain problems with the certain scripts because it will take another year or two." This is my estimation. Thank you. >>TINA DAM: Thank you very much. You didn't look for a question, right? Comments. Thanks for that. >>IZUMI AIZU: Thank you. My name is Izumi Aizu. I am at-large from Japan. I have perhaps two naive questions and a comment, mostly on the costs. The background is that in Japan we are working to have some kind of open process with the government, initiating a panel to select the new IDN ccTLD registry, including the existing TLD to apply for. With that background, the -- for the selection or evaluation costs for ICANN, there seems to be a scaling thing. Am I right? Between 25,000 and 50,000? Is it a scaling or it's a sort of uniform cost to be allocated to every applicant? That's the first question. The second one is that we assume that there will be no difference between selecting a new TLD registry for IDN, know existing one from each country, or is there any -- for the costs as well as how to really avoid a duplication of the sort of costs that if we are to do that in Japan, for example, we will have to sort of evaluate the technical capability and other capabilities. Some of them may overlap in reality with that of the ICANN evaluation. Or am I wrong? These are sort of questions and comments. >>KURT PRITZ: So the paper proposed a range of costs for the application processing or request processing because even though it stated with specificity later on in my presentation 26.7 thousand dollars, there's really quite a bit of uncertainty to that number, and so when the first calculations were made, one, it was uncertain whether we were going to include development costs in that, and second, there was a lot of uncertainty, so a range was written. But I think later cost analyses have shown that it's toward the bottom end of that range. You know, around the 26, $27,000 number. And I -- so I don't really understand your second question, though, about -- what? You do? >>IZUMI AIZU: The first question is that are you going to impose the same amount of evaluation fee to all the applicants, no matter the size, or whatever? You have only the scaling for the annual contribution but not for the initial? In other words, if one ccTLD -- new IDN gets one million within five years and another gets only 5,000, then you are going to set the same entrance bar, right? >>KURT PRITZ: So the recommended expected processing fee is just calculated based on costs, not based on the situation of a particular ccTLD, so it's a -- you know, a projected, expected cost -- recommended fee for that. But it's just based on cost, not based on the situation of the individual registrant. >>IZUMI AIZU: Yeah. Because the -- of course my opinion is that because the expected demand for each IDN ccTLD may vary a lot, depending on how large the prospective users are or population of that culture or language. So is it really fair to set the equal -- for the processing fee is an interesting question. This kind of question is -- as I said, we are working to have some evaluation domestically of the prospective candidates for the registry with some serious work to evaluate technical and other capabilities. Some of them may seem to sort of duplicate your process, and by the same token, if we put much resources domestically and then we'll have to pay for another processing, then that is sort of a waste of money and time, perhaps. Are there any smart ways to avoid that? >>TINA DAM: So we can quickly agree that there are some requests that are going to be easier and faster to process than other requests. But we have to -- >>IZUMI AIZU: And cheaper? >>TINA DAM: And because of that, they potentially would be cheaper. Because, for example, the labor that would be included in it would be less number of hours, and so because of that, some of them would be cheaper than the other ones. >>IZUMI AIZU: Thank you. >>TINA DAM: We are, though, in a situation with an initial process for allocation of IDN ccTLDs, and it's a fast track and limited number and so forth, and so we had to come up with something that seems fairly reasonable across all. >>IZUMI AIZU: Sure. >>TINA DAM: So that's what the number is. And just to make sure that it was completely clarified, I mean, when there's a range from 25 to 50,000 suggested in the financial contribution paper, it doesn't mean that some will be paying 25 and others will be paying 30 and others will be paying 50. There will be one number in the end, and as Kurt mentioned, it seems to be that it's at the lower end of that range. So it won't be different. >>IZUMI AIZU: Okay. >>TINA DAM: Okay? Avri? >>AVRI DORIA: Hi. Avri Doria, a question in personal capacity, personal curiosity. In the first presentation when you went through, you talked about the technical decision that needed to be made in terms of which IDNA, the old or the new, and you said, "We need to make a decision soon." And so I was wondering what process -- because there was both a technical aspect to that -- risk, risk analysis -- which may or may not have been done, and then there's also a policy part to that where IDNC basically sort of mandated a "going with the new one," at least as I understood it. So I'm wondering: How will you go about making this technical/policy decision real soon now? >>TINA DAM: Okay. So I -- I actually think that's primarily a technical decision. I am still the -- one of the people in the camp that expects the IDNA protocol revision to be finished before we go live, and I think -- I think it's really difficult to answer your question right now. I think I'm going to hold off on it until we have been at the IGF meeting in Stockholm at the end of July because one of the major topics that was disagreed upon in the revision was the topic of mapping. And not to go further into technical details on it, because this is not a technical session, but there is now a proposal on the table on how to solve that, and it is being discussed -- I think you're on the mailing list -- >>AVRI DORIA: Oh, yeah. >>TINA DAM: -- so I am quite hopeful that we come to -- or the IETF working group on the topic comes to a conclusion on that which could lead us into a last call around the Stockholm meeting. And of course I can't stand here, just to make sure it's not misunderstood -- I'm not standing here guaranteeing that at all. I'm saying this is what I'm hoping for, and that would make that decision a lot easier. >>AVRI DORIA: In that case, you wouldn't have a decision. >>TINA DAM: Yeah. Because it would obviously be to go with the revised version of the protocol because that would be a standard at that time. >>AVRI DORIA: Okay. Thank you. >>TINA DAM: Janis? >>JANIS KARKLINS: Thank you, Tina. Janis Karklins, GAC representative from Latvia and chair of the GAC. I cannot say that I will speak in personal capacity because we are not going for the fast track IDN TLD. Maybe sometime in the future. But there was a very interesting debate, and I particularly liked those who spoke at the beginning and spoke about the need for solidarity. ICANN has a mission, and IDNs -- introduction of IDNs, I think, is a big part of ICANN's mission, and we need to evaluate what is more important, to cover money which has been already spent two or three years ago or put that on the table and in some extent make an obstacle for launching this process. The entry fee may be prohibitive for some TLDs or for some applicants because we expect that applicants will come from developing and maybe from these developed countries, and I think we need to make a provision which would facilitate those applicants. And I didn't hear anything of the kind of subsidy in case -- if there is no possibility to pay this fee. We may think about an option that there is no entry fee, but the fee is recovered over time, and my question is whether you have ever considered that option and whether we may expect it in the final version of the proposal. And then the third point that I wanted to make is: In Mexico, the GAC -- and if I'm not mistaken, ccNSO -- suggested that treatment of ASCII ccTLDs and IDN ccTLDs should be equal, and as we know today, the ASCII ccTLDs are not required to pay but they can pay on a voluntary basis. And in your presentation, I didn't hear a single time the word "voluntary." Is that a -- on the table as a proposal that those who, for one reason or another cannot pay, they -- I mean, they cannot pay formally, requested, compulsory, they would have a chance to consider a voluntary payment which would be fully in line with the existing system for ASCII ccTLDs? Thank you. >>KURT PRITZ: Thank you, Janis. Going from back to front, the words in the paper suggesting fees are prearranged recommended fees, so the paper doesn't suggest mandatory fees. It doesn't use the word "voluntary fees." The -- those words were adopted as, you know, I don't think they're terms of art but they were adopted recognizing that asking for mandatory fees, especially from governments who are participating is somewhat difficult and that in other areas where governments are making contributions to some causes as worthwhile as ICANN, that the arrangement is then put in terms of voluntary but is put in terms of prearranged, recommended, or some other language, and, you know, that builds off of other areas and also, you know, builds off of agreements ICANN has with ccTLDs. So given that, the evaluation or processing fee for a request is also termed to be, you know, prearranged and recommended. I personally think it's probably the fairest way to go about it, rather than have ICANN try to parse which entities might pay more or which entities might pay less, especially with regard to the request, because all requests, you know, essentially cost the same. And so -- and so the answer to Question 1 is that the terms in the paper are prearranged and "recommended" so hopefully a little more voluntary, you know, a little less than mandatory. And then I think the idea of, you know, the development costs that are in the past are somewhat of a red herring. The fees that are suggested are, you know, just the direct evaluation costs or the processing costs without any development costs in that one fee that accompanies the request, and as far as the ongoing fee, if we think about the recommended amount of 3% that would add up essentially someday, if all cc's contribute, to 17 million. Then that's $6 million worth of development costs spread over a number of years, you know, over a number of cc -- ccTLDs really becomes quite small. So I think -- I think we -- you know, I would like to leave the costs of how we're paying for the development behind. That is a sunk cost, and what ICANN's recommending is that there be a recovery of ICANN support costs for ccTLDs. Did that answer your question, Janis? No? 17%, 9 million, right. >>RAVI SHANKER: I hope we have time for one more question. Ravi Shanker, member of the GAC from India. I would like to emphasize a few points that the perspective would be different for different countries. In my country, we have 22 official languages, and we have done the whole course of trying to emphasize this aspect to the GAC community, when the number of IDN ccTLDs were to be introduced, and then it became an accepted principle that all official languages would be incorporated, and the ICANN board also accepted that recommendation. Now, $25,000, if I did a mental calculation, it's $300,000 for 22 languages. Languages are an emotive issue, and when we came to the table, 22 languages, because all of them are official, we had to take the whole together. Now, the next stage is to take the process together. I must emphasize that we did a lot of homework prior to coming to the GAC community and then the next stage. Homework on developing the IDN philosophy in a technical and community manner was done. We are prepared. The same registry who is operating the dot in has been mandated to operate all the 22 IDN ccTLDs. At this point of time, for a dot in, we recover $10. Right now, we're in a promo period, so it's $5. So if dot in is at $5, you can imagine for an IDN ccTLD, I think it has to be priced, as one of my country managers said, at almost no cost, because it has to be a promotional activity, and this in our country's context has to bridge the digital divide. Unfortunately the digital divide also envelopes the socioeconomic divide, because it is that community which is unable to pay otherwise. If they had the amount to pay, they would have taken a dot in domain name. So this is one facet I thought I will bring it to this particular group, and maybe it's an area in which I am very happy to note that it's a recommendation and that it's not mandatory, it's voluntary, but in the course of decision-making, many things will have to go about in a fairly uniform manner, but also employing the principle of equal social justice, if one may say so, and I understand that ICANN is a not- for-profit society, it looks at things in a much broader ambit. Thank you. >>KURT PRITZ: Thank you very much for your comment. I just want to -- so agreeing with everything you say, Ravi, I just want to point out that if there is $300,000 in processing cost for the 22 requests, the -- $300,000 of ICANN's budget being not-for-profit is still a significant number, even though ICANN has a fairly big budget now, and so the money really needs to come from somewhere. If you extrapolate to an environment where someday there will be hundreds of applications, I hope, for IDN ccTLDs, that, you know, it -- that -- those one-time costs need to be recovered in some way. Some equitable way across the whole environment. >>STEVE DelBIANCO: Thank you. Steve DelBianco with Netchoice and also a member with the business constituency. We've heard a lot of talk about solidarity and about the money but I'd like to invite this group to broaden what they think of as solidarity, and they may find a way to simultaneously solve the money problem. I would broaden your notion of solidarity, not just from the ccTLD operators in the room, but think about the registrants and users today around the planet who are accessing and creating content in all of these IDN scripts but the content is all on the pages in Web sites. They live in ASCII ccTLDs and in ASCII gTLDs. Go to arableagueonline.org and that's it for the ASCII. The entirety of that site is in Arabic. But it's in a gTLD dot org, it's not in a ccTLD. And think about users. Users of all the scripts that you're wanting to support. Those users are accessing both g and cc content today. So by broadening that concept to look at the registrants and users, you have a chance to pick up where the real opportunity to solve your money problems are. If this group would invite a few of the bigger gTLD operators who have -- well, I understand there's a million IDN second- level domains in org, com, and net today. Invite a couple of large gTLDs to throw themselves into the same fast track process, so that we get IDN gTLDs -- maybe only three or four or maybe only five or six of them. That will bring the money to this process that could really drive down the costs that have to be paid by the ccTLDs. There's one thing we know about the big gTLD domains is that they're going to be able to bring a lot more expertise and maybe a lot more cash to the process because of the millions of registrations they already have. >>YALING TAN: Hi. This is Tan with CNNIC. I have a few comments on this. One is about the cost of recovery. I understand that ICANN has put a lot of money and a lot of effort into this. So did the IDN community. The IDN community actually has long [inaudible] into this IDN development and have participate in the ICANN process in terms of the IDN development. It looks like for IDN community, the IDN thing is just one way to serve our local community, to serve our local users, and this is one of our responsibilities of the -- you know, the ccTLD world. In this means, I think ICANN should also have such kind of responsibility in helping our IDN community to get the IDN deployment as soon as possible. Another comment is about what is variants. Actually speaking as a Chinese speaker, I understand there are some technical problem on the -- you know, the variants allocation or delegation thing, but for a Chinese speaker, we do think that simplified Chinese and traditional Chinese are -- share the same meaning, regardless of what it looks -- how different it is in the technical side. But for us, a simplified and the traditional Chinese are also the same meaning, and so in the case of for the -- for the sake of, you know, the end users, I strongly suggest that we just delegate the simplified and traditional Chinese for our Chinese speakers. This is for the sake of our whole IDN community. Thank you. >>JONATHAN SHEA: Okay. I'm Jonathan Shea from Hong Kong, dot hk registry. I just want to share with you a few comments. The first one is about our work that we have done in Chinese domain name consulting. This is -- at least we have five members also speaking Chinese and, therefore, have been working on the Chinese domain name technical methods for quite some time. We have also been incrementing variant -- handling of variant at the second level, Hong Kong, China, Taiwan, and, you know, possibly in Singapore, Macau later on. So I'm really surprised that if, you know, ICANN have concern on technical stability, concern with technical impacts on the top level and root level. Then we are really ready to share experience with you, because we have been operating at the second level for so many years and we haven't find any problem with it. So, yeah, I think that's the first thing. I think in terms of variant treatment, there is abundance of experience technically already at the second level, which I think should be applicable at the top level as well. Secondly, about the charges that this paper proposes, please note that in the Asia-Pacific region, we have really a wide variety of ccTLD registry operating. Some of them are very small. Most of them are nonprofit. Most of them are doing this as a community service without actually breaking even. So some of them are operating at a loss already. Therefore, I really urge ICANN to consider that we are not gTLDs, we are not in the business of making a profit. If we are going to provide the service to the community, then we are operating, you know -- some of them are operating in a very difficult financial position, so we should make this contribution voluntary. I don't think that we are not paying or we are not recognizing that there is an overhead. We do. But imposing a compulsory fee will make things very difficult for many, many of those, you know, less advantageous ccTLDs in the Asia-Pacific region. So -- and one last thing about -- is a question about the timing of this whole process. Is it -- is there a delay already? Since I remember last time I heard about the process we will be able to, you know, launch it or start -- starting this process October/November this year. Is it that we have a new timing established, such that we are going to start in April next year? >>TINA DAM: No. So let me take the last question first. >>JONATHAN SHEA: Okay. >>TINA DAM: In terms of timing, the answer is no. What we're looking for is Q4 2009. What you hear about around March or Q1 2010 is the gTLD program. >>JONATHAN SHEA: I see. >>TINA DAM: The IDN ccTLD fast track is aiming at by the end of this year, 2009. Brief observation on your variant TLD comments, and also to the -- to the previous commenter on that topic. I hope -- I hope I've been clear in stressing that it's 100% understood that there is a need for having these TLD variants in the root. That's not a question at all. That's fully understood. And it's also understood that it's for various reasons in different regions. But as we're standing here and talking about it -- and that's the whole purpose, right, is to see if we can find some way of coming to solution -- I'm wondering if it might be useful for us to take a closer look at variant definitions. Because the previous comment talked about strings that have the same meaning, but not necessarily looking confusingly similar. And one of the big problems we have from the technical side of things is to put confusingly similar strings in the root without doing so by making sure that there is an aliased functionality between them. So it may -- it may be -- and, you know, I don't speak Chinese, so we may need to just sit down and look at it and you explain to me and I'll explain it to you and see if there's something that's different for Chinese that is not confusingly similar. Because certainly in the fast track, you can have both a simplified string and a traditional Chinese string, so it may be that there's a -- there is a little bit of leeway there. But I -- you know, I don't know. I'm just saying this is certainly something we need to look at. >>JONATHAN SHEA: Yes. We are equally concerned about confusion, and ambiguity caused at the second level, and the use of the variant table. We have been using that for many years and that, we believe, is a very good way to resolve the problem, and you should consider seriously how that can be applied to the top level as well. >>TINA DAM: Right. And as I've said before, we want to use those tables at the top level, and in fact, we're going to use exactly the same tables at the top level. Both for gTLD processes and the IDN ccTLD fast track. >>JONATHAN SHEA: Okay. >>TINA DAM: It's just a matter of making sure that when we talk about confusingly similar strings, that they are entered with an aliased function. >>JONATHAN SHEA: Well, variant tables are actually addressing that as one of the uses. Yeah. >>TINA DAM: Okay. Thanks. >>JONATHAN SHEA: Welcome. >>KURT PRITZ: Well, I understand your fee question, and we're all sympathetic to that. One reason for the revenue-based model was, you know, low-revenue, low- volume registries would pay very little. That's why the percentage model was developed. And we talked before about another model, where registries would have some discretion how to create a fee model or a contribution model that was suitable for itself. But ICANN certainly doesn't want to get in the way of the viability of a registry that's serving the public. That's for sure. >>JONATHAN SHEA: So just one quick thing. I ask for voluntary treatment. I think we -- some matter of them are willing to pay more than what you said. Just make it voluntary so that the less advantageous ones can -- you know, can afford to run their services. That's all I want to say. >>KURT PRITZ: Thank you. >>JONATHAN SHEA: Yeah. >>KURT PRITZ: So this will be -- we're going to time this perfectly. We have three minutes to exit the room so they can rearrange the furniture again. So Hiro, if this could be the last question, that would be great. And Manal has a quick question, so if you're willing to divide your time, that would be good. >>HIRO HOTTA: All right. Thank you. Maybe my question is a little bit related to the question made by Izumi Aizu regarding if ICANN do a lot of evaluation or not. My question is very practical one, about how many pages are expected in the proposal document submitted to ICANN by a candidate registry. I ask this because it is relatively easy to write the proposal in a language we use everyday. Usually it may be the language corresponding to the proposed IDN ccTLD. But ICANN will not accept the proposal in local language, right? Maybe this is my main question, but it will be a big burden for the candidate in non-English-speaking country or territory to write a long sophisticated proposal in English. Even a professional translation service before proposal submission may be needed. Thank you. >>TINA DAM: So the supporting documentation that you need to supply with your request, we actually need it both the original, if the original is in the local language and that language is not English, so we need it in the local language because we need it with the signature and the hard copy on it. Number of pages? I -- you know, as I see it, it's very few. I mean, you saw the four steps which is in the draft form right now. It's -- it's not -- it's not a lot. And then there's a few supporting documents, right? So I don't -- this is not going to be like a thick request that is going into ICANN, so I think it's going to be fairly simple. >>MANAL ISMAIL: Manal Ismail, Egyptian GAC representative -- >>KURT PRITZ: This is the last -- >>TINA DAM: Just the last question. >>MANAL ISMAIL: I'm sorry. Just very quickly, I want to echo what has been said by most of my colleagues on the financial contribution and specifically the first -- the down payment, the 20-something thousand. I think it would impose a financial barrier to registries, especially from developing countries. I have a quick question regarding -- you were urging language communities to contribute in developing the language tables or script tables or whatever, and I want to know how would this -- is there a process for the output of those language communities? I mean we have -- sometimes we have specific recommendations that characters, for example, be protocol-valid but still not be implemented in the registration because they impose some security threats or something. So how would this be reflected in the whole process? And to end positively, I would like to thank you for taking into consideration the application forms that was suggested in Mexico meeting. Thank you. >>TINA DAM: Sure. You're welcome. How that process goes, I think for development of the IDN tables, I think it's going to be different from region to region, but you have a very good example in the Arabic script working group, right? That I think -- that is going really well and potentially may end up being an RFC or a best practice document, so that could be one way out. Right now, ICANN does not specify you have to end in a -- with a process or a document like this, and it has to be acknowledged like this. There -- we don't have the details of that, because we leave that to the local community. We just encourage you to work together on it. If you do need support on figuring out which communities you should collaborate with and which you shouldn't and so forth, we will get you some linguistic support, but it's not going to be ICANN staff. >>MANAL ISMAIL: Actually, I meant where to submit the output. >>TINA DAM: Oh, I'm sorry. So the -- the IDN table will need to be submitted together with your request. So just like there's supporting documentation, there's also an IDN table and that will be -- so we didn't see the details of the form, but there will be like an area where we can -- where you can upload all of that supporting documentation and the table as well. So it goes into being a part of the whole request. And then later on, it goes into the IANA repository for IDN tables. Yeah. So everybody's on their way out, so thank you for your time and please go to the public forum and make your comments and ask questions if you had any more than was asked here. Thanks. [Applause]