IDN ccTLD Fast Track Monday 26 October 2009 ICANN Meeting Seoul, Korea >> Ladies and gentlemen, our program will begin in approximately two minutes. Thank you for your patience. >>KURT PRITZ: Hi, everybody. We're going to start today's session now on the IDN fast-track process. >> Can't hear. >> Volume up. >>KURT PRITZ: Test. Okay, great. So as many of you know, Tina Dam can't be here physically at this meeting, which is, I'm sure you know also, very unfortunate, because she's led this effort to introduce IDNs into the domain name system for some time now, years. Can you not hear, Steve? >> A little louder, Kurt. >>KURT PRITZ: I'm talking as loud as he can. He'll have to twirl the dial. Is that better? >> Yeah, it is. >>KURT PRITZ: So it's unfortunate that -- [ Applause ] >>KURT PRITZ: Thank you. It's unfortunate that Tina can't be here today. But it's just impossible. But it's not all bad, because she is going to join us through the miracle of modern communication and provide an IDN briefing, an IDN fast-track briefing, for what promises to be a watershed event, that is, the consideration by ICANN's board to introduce IDNs through the IDN ccTLD process or the fast-track process. So it's a remarkable moment in ICANN's history, we anticipate. And so to introduce the discussion on this for what will be a week- long discussion about the introduction of IDNs is Tina. So can you bring up -- yeah. So Tina's going to appear here. I've got a bottle of water for you down here, if you need something to drink. And I'm just going to let Tina take the presentation away. And she's going to direct it from where she is now. So, Tina, welcome to the room. And welcome to Seoul. >>TINA DAM: Thank you, Kurt. I'll start with the water, because you can promise you wouldn't make me cry. But good afternoon, everybody. I really wish that I could be there. But, you know, this is as close as it gets. So as Kurt said, this is really a great time. And I'm really excited to be able to give you this presentation on the IDN ccTLD fast-track process. So let's just get started on it. Let's go to slide two that has the agenda on it. So as you know, the proposed final implementation plan was posted not so long ago. And so what this session is going to entail is, basically, a broad review of everything that goes on with the fast- track process: what it is, who can participate, what requirements are required, so what you need for preparations. We're going to take a quick look at how you can submit a request, and, well, I wanted to give a whole online demo, but we're going to give you a little sneak preview, at least. Then we're going to go through the string evaluation, the costs, and support functions, and where we're at and where we're headed next. So let's just go ahead on the next slide. What is the IDN ccTLD fast-track process? And if you go to the next slide. This is, as you know, most of you, I think, a limited process. We are only going to introduce a limited number of IDN ccTLDs. And the reason for this limitation is that not all of the policy decisions have been made. So limitations are associated with the country and territory has to be associated with the ISO 3166-1 list. The strings have to be comprised of non-Latin characters. There has to be government and community support. And the strings that are going to be allocated through this process has to represent country or territory names. And then, of course, not last, but certainly one of the most important aspects, we need to make sure that we have a continued stable operation of the DNS. So that's very briefly -- I said it's limited because not all of the policies are ready. And as you may know, the ccNSO is running an IDN PDP on that. So all of this is going to go into that process as well as informed information. But these are some of the limitations. And the rest we'll take a look at in some of the eligibility requirements. Son on to the next slide. Who can participate in the IDN ccTLD fast- track process? On the next slide, the requester eligibility requirements are that, basically, anyone can function as a requester. In case this is a little bit of a strange word for someone, the requester is really the applicant. It can be the identified IDN ccTLD manager. It can be the government or public authority itself. Or it can be someone else appointed to submit the request for the IDN ccTLD on behalf of the country or territory. The IDN ccTLD manager does not need to be appointed or elected at this point in time, so it really can't be someone else. There is only one rule associated with it, and that is that if the requester is not the corresponding government or public authority, well, then there needs to be a letter of support from that government or public authority, you know, stating the support for the request. So let's go to the next slide. Next few slides, actually, are going to be around preparation guidance. So go ahead to the next slide. There is a list of requirements. And most of them are related to the string requirements, because this piece of the fast track is really a string evaluation. So I'm just going to go through what's listed there on the slide. The string must be based on an official language, and the script for that language has to be non-Latin. The way that that is clarified is that it has to be an ISO 639- listed official language. That is something that's listed in the U.N. manual that the proposed final implementation plan is referring to. And there is a link in there in the proposed final plan that specifies where you can find that manual. If it isn't listed there, then there needs to be a government support or some sort of government documentation that the language is official for the corresponding country or territory. Then the string needs to fulfill the technical string criteria. Largely, that means IDNA protocol requirements and the IDN guidelines. And I just put one thing in there because it has been quite a topic of discussion, that the minimum number of characters is two. It can be a longer string, but it doesn't -- and it doesn't have to be just two characters. The string, though, has to be a meaningful representation of the country or territory name. It can be long or a short version in the U.N. manual. Again, if it's not in that U.N. manual, you, as a requester, need to provide some additional documentation for that. It can be an acronym. And two characters often represent an acronym. But it can be longer. If it is a longer string, then we're providing some usability warnings, if you want to call it that, that longer strings do have some usability issues with it. And then the last thing for this slide is that the string must be supported by the local community. So to the next slide. In your preparations, you need to develop an IDN table. The IDN table basically specifies the characters that you want to support under an IDN ccTLD string. And you may also choose to reference an existing table, if you like. We do recommend that, as much as possible, references to existing tables are made. And those tables are posted at IANA.org. If you do go ahead and develop a new table, then please try to see if you can work together with other communities that share the script that you are going to be offering IDNs in, because that will limit confusability as much as possible for the communities. And, of course, you know, that's what we want; right? IDNs are supposed to work in the best possible way. Then on the rest of the slide, you can see you need the A-label, the U-label, the Unicode codepoints, and the English translation of the string. There's been some questions around that English translation of the string. And, you know, why do we really want this? We're trying to internationalize the Internet, so why do we need it in English? It really is mostly for practical purposes. It's really hard to talk about an xn-- long sequence of ASCII characters string. And so we need some other way of referring to it. And even though ICANN staff has a lot of -- there is a lot of staff at ICANN that speaks a lot of different languages, we don't speak all. So it's going to be hard to refer to the string in the U-label form. On the A-label form, as you may or may not know, we're in this great situation where the IDNA revision is almost completed. And so for the purpose of the fast-track process, we are actually accepting the characters that are -- that has become newly valid with the IDNA 2008 revised version of the protocol. It's possible that that may require manual evaluations while that revised version of the protocol is being implemented. But it's really the chicken and the egg, what comes first; right? So let's get those characters out there, and let's get moving on it. All right. Next slide. Number of strings. Again, a topic that actually still is under discussion. But for the proposed final plan, the number of strings are one string per official language or script per country or territory. So that means that if you're a country that has more than one official language, and, you know, hence you have more than one way of expressing your country or territory name, well, then you can have more than one string. And the way that the application form has been set up is so that you can add more strings into your request. The second half of the number of strings relates to variants. And the way that it's described here on the slide that I'm going to go through is what is proposed for the fast-track process and what is going to enable that fast-track process to be launched right away or, you know, as soon as the board is approving it. It is a topic that's under continued discussion. And so because of that, we need to make sure that we have a way of revising the process as soon as there is some solutions on how to manage variants at the top level. But for the launch, the proposal is that all those variant TLDs that are desired for delegation must be identified in the request by the requesters. So desired variant TLD is a variant TLD that you want to have inserted into the root and that you want to use together with the base TLD, if you want to call it that, that you're requesting. Now, we're not going to insert the variant TLDs in the root zone right away. They are going to be placed on a reserved list allocated to the specific requester. And that's really just a precaution to make sure that these variant TLDs are not going to anyone else. Because if that happened, we would end up having confusable situation; right? So we want to make sure that this is managed the right way. So variant TLDs on a reserved list allocated, but not inserted in the root zone. The nondesired variants, those are all of the variants that come out of the IDN tables, and because a lot of characters have variants associated with it. And those nondesired variants will be placed on a blocked list so that no one else can apply for them. And as I said, the desired variants, as soon as there is a method for allocation of them or a delegation of them in the root zone, then the fast-track process can be revised to take that into consideration. All right. Next slide. The next slide is how to submit an IDN ccTLD request. And I only have one slide on that, so go ahead to the next slide. So once you've gone through all of this preparation and you're ready and you have all of the supporting documentation and the supporting material that you need, you go to an online form where you can submit the request. And there is these -- let's see, one, two -- there is these five pages on this online form. The first one is the terms and conditions. The next one is a place for you to insert your contact details. Then there is the string details. Then there is a page for you to upload all of the supporting material. And then there is an option to review all the information that you included. And once you've reviewed it, you can submit it. The online form link is going to be announced as soon as we're ready to launch. And there is also going to be a manual released that is going to help guide you through this online form. I will say, though, that this online form is fairly simple. And it's even so simple that you have to enter all of the information in one go. You cannot go and enter, for example, your contact details and then next day go back and look at it and see if there is anything you want to change or, you know, continue to request. So it is a very simple setup, and it's intended for a fast launch. So let's take a look at it. If you go to the next slide and click on the "demo" link. You know, it's so nice to have Ted over there on the side help me with the slides. So I actually don't know how well you're going to be able to see this in the room at all. But the intention was that I was going to go through all of this and show you exactly how to fill out a request. And I can't do that. But for those who are interested in it, I can do it at a different time. But this is the first page for the online form. And, Ted, if you scroll down just a little bit, you will see that -- yeah, that's good -- if you can read it, you will see that this is really general information. There is a little bit of usability warnings and information about ICANN on there. And if you scroll further down, actually, just go ahead and scroll down to the bottom of the page, you will see that the terms and conditions are there. And so by submitting -- and you also have to sign a request once you've submitted it to ICANN, you need to actually print it out and sign it. And by doing that, you actually agree to the terms and conditions that are listed there. These terms and conditions are exactly the terms and conditions that are listed in the proposed final implementation plan. So I'm guessing it's really hard to read up on the screen there. So you can go in the proposed final plan, and you can read it there. They are very limited in nature. They primarily refer to technical standards. Now, the last piece on this front page of the form is that you can select to enter into any kind of other relationship with ICANN. And this is of course something that we would like to see. But it's totally by your choice. So you can choose something that's very similar to the accountability framework that exists with ccTLDs today or with some ccTLDs today. Previously, it was referred to as the documentation of responsibility. Again, that is detailed completely in the proposed final implementation plan. Or you can choose to enter into a letter or other kind of agreement with ICANN. And, again, the details are in the proposed final implementation plan. So, Ted, if you go ahead and click "enter" down there at the bottom. So if that works, it -- if that works, it should take you to the second page. Will you say "no" to that. Yeah. So -- Great. So what you saw happening there is that as we've worked on this, right up against the Seoul meeting, we're switching things over into a secure site with a secure server and stuff like that. So it's a little bit unstable at the moment as it's being moved over. But, anyways, this is the second page, and you can see that this is basically just entering contact details. And at the top there, you can see that all the next pages are exactly as I said. The one following this one is going to be for the string details. The page following that is going to be uploading the supporting material. And you also need to identify in what way your language is considered official and so forth. So all of the rules are set up in there. And it should be fairly easy for you to select all of that out. So let's go back to the slides. All right. So the next set of slides deals with the IDN ccTLD string evaluation. So go ahead to the next slide. So once you have submitted your request through that online system, it's going to end up in very standard system, back-end system, as ICANN where we can log all the communication going on with it. Actually, I should say, I just missed one point, and that is once you submit it via the online form, you are going to get this confirmation e-mail. And you have to confirm the submission of the request within that confirmation e-mail because otherwise, you know, we're not going to start evaluating your request. But once you have confirmed it, the following three things are going to take place. First, we're going to check -- and that is a staff check. Staff is going to check that the request is complete; that all of the material and supporting information, documentation, letters that are required have been included, and that if it's required to have supporting material from a government or public authority, that it's coming from the adequate government or public authority. If that is not the case, then we're going to e-mail back to you and provide you with some information about what we're missing, and we'll communicate back and forth, and we can also do that by conference calls. But if it is complete, then we're going to change the status of your request, and you will receive an automated e-mail from the system that's going to inform you that your request has now cleared the completeness check and has moved into the linguistic process check. And the linguistic process check is exactly what it indicates. It's a check that the process for linguistic material has been followed. So that means that the language is official, the string is meaningful, and the community support for the string. The processes for all of those have been followed. So you are not going to have staff sit around and make determinations on whether the string you requested is meaningful or not. We are just going to check that you followed the right process for it. Again, if there's any problems with it, we're going to have a communication with you as quickly as we can. And if not, you are going to receive a notification that states that the linguistic process check has been fulfilled and that your string now has been provided into DNS stability evaluation. And the DNS stability evaluation is something that takes place outside ICANN staff. So if you go to the next slide. We have -- Yeah, we have a DNS stability panel that is coordinated by Interisle. And the panel is going -- The entire panel is going to look at all the strings for security, stability, and confusability. So they are going to check a number of technical requirements, make sure that it's a technical adequate string, but they are also going to check for confusability. And that is confusability against existing TLDs, other things that are under fast-track application, or strings that are under gTLD application, if that process is running at the same time. The panel will take a look at all strings. If they feel that they need additional expertise, either technical or linguistic, they can call for that. And that is in their discretion. If they do have questions or concerns about the requested string, they are going to contact ICANN staff and, through ICANN staff, that information is going to be passed on to the requester so that you have a chance to provide additional information, if needed, or you can have a communication about what potentially could be wrong. We are going to send strings to the panel on a monthly basis, so it's going to be in batches. And the evaluation, all in all, is expected to take 30 days. It may be taking less that be that, but that is the expectation. If there are any problems with a string or a set of strings requested, then it could take longer. But this is sort of like the baseline of what you can expect. All right. Go ahead to the next slide. So this is the final steps in string evaluation. Once the DNS stability evaluation has been successfully passed, we are going to initiate a public posting of the string and contacts for the string. This is also done on a monthly basis, and you are going to be informed that your request has now passed DNS stability evaluation, and this is the date on which your string and contact details will be posted publicly on the ICANN Web site. Once the public posting has taken place, you will get the last notification from the fast-track system that is informing to you initiate the TLD delegation via the IANA function. This is a standard delegation in the way that it takes place today, and I have put the link in here but there is also some more information in the proposed final implementation plan about that. All right. Go ahead to the next slide. So the next topic is around costs associated with an IDN ccTLD request. Again, it's a topic that has required a lot of discussion. And if you go to the next slide, you will see what it is that we ended up with in the proposed final implementation plan. There is two fees associated with an IDN ccTLD. First up is the processing fee. We did a revision of the costs associated with the evaluation of an IDN ccTLD, and it stayed at very close to the same baseline as before. The 26,000 U.S. dollars, or equivalent local currency. So you can pay it in any currency you like. The invoice will be sent out to you when we have received the request from you. We do understand that some are not able to pay it immediately, and so the processing of the request will continue, even though we have not received the payment for it. The second fee is the annual contribution fee, and it is set at a tiered level; 1, 2, 3% of the IDN ccTLD registration revenue. So there's been a lot of questions around that. If, for example, the IDN ccTLD is run by the same manager as the ccTLD, it needs to be separated out. We're not talking about registration revenue from the ccTLDs. We're solely talking about it from the IDN ccTLD. There's also been questions about, well, what if the revenue is zero? And the answer is really simple to that, because 1, 2, 3% of zero is zero. So that means that there won't be an annual contribution fee. So how are you going to calculate it? Well, ICANN is not going to go out and ask you for information about revenue or anything like that. We're going to send you a letter where you can fill out the statement, and we're going to take that on as being good. You can pay, again -- this can be paid in local currency or in U.S. dollars, as you prefer. These two fees are preferred -- sorry, they are prearranged and recommended, which means that they are expected. So we expect the payment because the launch of this process and running of it and evaluation of the requests and the ongoing maintenance does have a cost associated with it. So that's why they are expected. But we also understand that there are countries and territories who are incapable of paying this. And if you are incapable of paying that, you should contact ICANN and request a fee waiver. So that's about the costs. So go ahead to the next slide. This is the second to the last subject for my presentation, the IDN support from ICANN. So go ahead to the next slide. We have tried to set up a really good support function on this. So as countries and territories are going through their preparations, we have a specific -- we have staff available for specific support functions. You can send e-mails into this e-mail address, and they are going to be replied to quickly. All of the regional liaisons that you know that supports the different regions around the world will help out and support you in all your preparation efforts, and we're only asking that you try to coordinate your inquiries through this e-mail address so that we can sort of like coordinate the support function in the best way possible. But, of course, meetings, events, conference calls, you name it, you are welcome and approach us. And actually, for this Korea meeting, we had set up consultations for you, and we're going to it be doing that as well. During the string evaluation itself, you are actually not allowed to have communication with staff, board members, or anyone else contracted to ICANN about your requests. So if you have any concerns about your request or inquiries about it, you need to reply to the confirmation e-mails that you are getting from the system. And, you know, if we need to set up a conference call or anything like -- or even a visit in the office or a meeting at an event or anything, we'll arrange for that. So don't worry about it. But we're just trying to keep communication limited. Then during the IANA delegation, which takes place after the string evaluation, you can direct inquiries to IANA. And the way that that works is the same as it has been for any TLD delegation so far, and it's detailed in the paper. Once you have your IDN ccTLD string delegated in the root zone and you are launching, and some are ready to launch right away and others might take a little bit longer, you can again ask us for any kind of support. As long as you keep in mind that, you know, we can't make business decision or legal decision or anything like that at all, but we can help you out as much as possible. All right. Enough about the help. So let's go to the next slide. Implementation status, and so what's going to happen now? So go ahead on to the next slide. Implementation status. I just put some brief information on here. The DNS stability panel is formed, and they actually have taken part in the testing of the system that we did in the past few weeks, and it's almost done. We're just pending the report from the stability panel where they tried out the evaluation of certain strings. And so they have tried this out and they are ready. The request system, the online form, the back-end system to log everything and the manual that explains how you are going to use the system is all ready, and it's ready to be released. We do have some small changes to it, and we're moving it to a different server and so forth. But all of that is really minor, and it has nothing to do about how it operationally works. Then there's the online IDN area. It's pending release. It is not 100% ready yet but I think this week while you are in Korea busy I will be working with a couple of people in the office and getting that finalized. Last item on this slide is the linguistic processes, and these are in place as much as we could do so far. It's hard; right? Because we don't know which countries and territories, what languages, what scripts we need to provide some support for. So this is something that's going to be under continued development based on what kind of requests we get and the experience with the system, all in all. But the very basic components of it is ready. So go ahead to the next slide. So what's going to happen next? Well, we have the meeting now, and a lot of other meetings throughout this week, in Seoul. And we have the board consideration coming up on Friday, which is going to be really exciting. The launch, as you know, I think you know, is proposed to be on the 16th of November. So it's coming up shortly. And as soon as it's launched, we're also going to prepare and schedule for annual reviews and possible revisions. All of that, of course, is based on user experience. And then we're going to provide reports about how the fast-track process is going and provide the input into the long-term IDN ccTLD PDP, the policy development process for long-term implements of IDN ccTLDs, so we can take advantage of everything we learned in this fast-track process. But if you go to the next slide, what's coming up much more immediate in the next steps is the IDN reception tonight. And I really hope that you will all be able to go to the room next-door tonight. There's the IDN reception from 6:00 to 8:00 p.m. I think it's going to be great. I know that ICANN's CEO and chairman of the board would really like to thank the ICANN community not just for IDN work for the fast track but for IDN work overall as we're moving into this next step. And with that, go ahead to the last slide. I'm just going to say thank you for listening in. I hope it's -- I hope you have been able to hear me and follow this in an okay way. And we're going to open the microphones for Q&As. So thank you for this, and if you have any questions, go ahead and line up. [ Applause ] >>TINA DAM: And you can be a little bit more excited, because I am excited and I am not even there. >>KURT PRITZ: So Tina, this is Kurt. Can you see the queue? There's a gentleman standing there. >>TINA DAM: I can see Chris. I don't know if there is another microphone, but go ahead, Chris. >>CHRIS DISSPAIN: Hi, Tina. How are you doing? >>TINA DAM: Doing good. >>CHRIS DISSPAIN: Good. Two things. On the variant subject, how will we decide if something is a variant? So I put in my application for, you know, dot whatever it might be and say this is a variant of that. Now, is there some sort of standard by which it will be judged that it is actually a variant? How will that actually be worked out? >>TINA DAM: Right. So that's the -- I think at least for some, that is the hardest thing about variants. And I think it's partly the reason why it's being discussed so much how we're going to manage them, because variants are defined based on -- you know, basically you are going to take the string that you want and you are going to take your IDN table that you developed yourself, and you identified which characters are variants in that IDN table. So if you merge the string with the IDN table, you are going to get a list of variant strings. >>CHRIS DISSPAIN: Okay. >>TINA DAM: So you have ABC. It's a really bad example. >>CHRIS DISSPAIN: Yeah. >>TINA DAM: You have dot ABC, and D -- and you happen to have decided that D is a variant of the character C. So that means you have your ABC base string, and then you have a variant string that is ABD. Okay. This is a really bad example. But because you decided what variants you have in your IDN table, you are the one who is deciding what are the variant strings. So I don't want to get into this too deeply here, but doesn't that effectively mean that I have the power to effectively block someone else's string? Because I decide that something is a variant and if I say it's a variant, it will then be blocked as a variant of mine. >>TINA DAM: Yeah. Well, there are two sides to that. One thing is, fortunately, for the fast-track process, the desired variant, the variant that is not being blocked, the one that you want to have allocated, that needs to fulfill all of the fast-track requirements, just like the base string that you requested. So it has to be representing the country name. So you can't just get anything; right? >>CHRIS DISSPAIN: I accept that. >>TINA DAM: But the blocked strings -- yeah, if you are capable -- I haven't really tried it out, but I think it's hard to do, but if you are capable of managing to set your variants up in such a way that you are going to have a undesired variant string that means another country or territory name coming out of that IDN table of yours, then that would go in for blocking, obviously that would be a problem we would need to deal with. Because if a blocked string is actually a country or territory name, well, you know, we need to have some communications about why do you want it blocked when someone else wants it as their base string. >>CHRIS DISSPAIN: Yeah. You could maybe solve the issue by saying that even if you don't want it, it still has to be meaningful. In other words, the standard is the same for desired and reserved as it is for blocked. It's just that you have said you don't need to desire or reserve that one. I can't see how it could be possible for you to -- how it should be possible, rather, for you to block something that isn't a meaningful representation of your country or territory. So it might be worth thinking about actually applying the same standard across those two. >>TINA DAM: The whole purpose of blocking the undesired strings or the undesired variants is that all kinds of variant strings can show up based on what you have in your IDN table and it could be nothing but really, really confusingly similar to the string that means your country name. So, you know, but I see your point. >>CHRIS DISSPAIN: If it's confusingly similar, then it fits within the -- Anyway, let's not -- I will move onto my second question which is hopefully a little bit simpler. I am a country applying for an IDN ccTLD and I want to enter into a document of responsibility with ICANN. My question is there is a template of that document of responsibility available, but that document of responsibility is still negotiable, isn't it? I don't just have to just agree to sign the template. >>TINA DAM: You don't have to agree to sign the template. What's going to happen is you are going to check that box that says I would like to enter this, and please send it to me. We are going to send you the template and then we're going to -- somewhere throughout the process we are going to initiate a conversation about what you want to keep in it and what you might not want to keep in it. >>CHRIS DISSPAIN: Thanks, Tina. >>TINA DAM: Sure. >>WERNER STAUB: My name is Werner Staub. My question again is about the variants, and related to the questions we had last ICANN meeting about the blocking of variants as opposed to activating those variants that need to be activated. Did I understand correctly that it is not being contemplated that in the case where the country needs both variants, or more than one, typically two, to be active that this would not be done immediately? >>TINA DAM: Hi, Werner. Yeah, this is right. And I may not have been clear enough about it. There is an implementation support team, so a team of individuals from the community who is assisting ICANN right now in figuring out how to go about actually inserting these variant strings into the root zone so they are function jam and usable. And that team, implementation support team, is scheduled to come out with a report that then will be posted for community discussion. So since this is clashing, timewise, with the launch of the fast- track process, the fast-track process is proposing that the variant strings that you want, and that you want to have in the root zone, will put them on a reserved list for you to make sure that once we have a way of delegating and inserting them in the root zone, we insert them in there and they are yours. That's the only compromise that we could come up with where we will launch the fast-track process right away, you know, following -- the board obviously needs to approve it first, but following that, if we want to launch it right away, we have to do it that way. And it's really just a precaution to make sure that the variant strings goes to the right entity. But yes, what you said is right. But that doesn't mean that we're not working on it and still aiming at getting a solution on the table for it. >>WERNER STAUB: In this context, I think it's important to remember that there is an established solution for that problem, which is simply the delegation of separate zones that are tracked by the registry to be equivalent, and make sure they are always delegated to the same name server, also on second-level domain level. So there may be need for documentation, but this could be at most a couple of weeks' work to do that, but it's nothing that would justify the delay of the activation of those variants for anything more than that period. >>TINA DAM: Well, yeah. You are right. But the point is just that there is a lot of discussion and disagreement in the community about whether that is an adequate way of getting variant TLDs in the DNS, and I know the implementation support team is looking a that way of doing it as well. But let's see what they come up with, and let's have that as a separate public discussion. Go ahead. >>ANDREY KOLESNIKOV: Hi, Tina. It's Andrey Kolesnikov. Nice to see you. Question. What will be considered as a community support? I mean, is it, like, quantible number or absolute number of supports, like a million letters signed, or ten letters signed? Or letters from the local community organizations? I mean, how do you know that communities support this certain IDN? What's the form of it? >>TINA DAM: That's a good question. I'm just looking for -- >>ANDREY KOLESNIKOV: For the particular case. >>TINA DAM: We have an example or a sample and explanation of that listed in Module 5. >>ANDREY KOLESNIKOV: I know. But, I mean, there are different countries with different communities with different configurations. So the question is, as much as a community can deliver? >>TINA DAM: Yeah. >>ANDREY KOLESNIKOV: Or only to the certain examples posted on the Web site? >>TINA DAM: Yeah, this is -- >>ANDREY KOLESNIKOV: Is there a way for improvisation? >>TINA DAM: Yes. So sorry I spoke over you. But, yeah, this is obviously something that's going to be different from country to country and territory to territory. There is no one demonstration of that support that fits all. So the sample that is listed, it's in appendix 2 to Module 5, the sample there is really just for guidance. We've based it on the IANA, the TLD delegation of requirements that IANA is using for demonstrating that there is support for the IDN ccTLD manager. So we've based it on something similar to that. But, you're right, it can be different from place to place. >>ANDREY KOLESNIKOV: Okay. Thank you. >>TINA DAM: Sure. >>IMRAN AHMED SHAH: Hi, Tina Dam. My name is Imran Ahmed Shah. I am representing Urdu Internet community from Pakistan. And I have some questions. First one is related to the similar my friend. What is the procedure for the region of a proposed IDN ccTLD string and IDN ccTLD manager as well? Because if it is assigned by a government and don't have the support from the -- its community, what's the procedure you have to evaluate and to revise it? Next question is, what is the procedure for domain dispute resolution for local IDN domain names? Third question is, what is the procedure to authorize any local company, legal entity for IDN domain name resolution? And my fourth question is, what is the procedure for the (inaudible). Thanks to ICANN and you, as well, to reduce the cost of the IDN ccTLD and charging it in different steps, and also you approved my proposal to provide some support like you have announced in this last draft that IDN ccTLD manager can apply for the waiver. So what is the procedure for the waiver you have configured out? And what is the criteria to provide them for the waiver? Thank you. >>TINA DAM: Sure. So I know there's a lot of people in the queue. So I'm just going to give you, like, a brief answer. And then I know you've sent me an e-mail as well. So we'll talk some more details about it. >>IMRAN AHMED SHAH: Okay. Excuse me, excuse me. I would like to -- to have your answer so my other fellows will listen at this moment, instead of sending through e-mail. E-mail goes to me, not the -- all the participants. >>TINA DAM: Certainly. So as I said, I'll give you a brief answer at least now. So the IDN ccTLD manager does not need to be decided upon until you hit IANA delegation. So throughout the whole string evaluation and the online form that I showed you that you need to submit all the information in, you do not need to have decided upon the IDN ccTLD manager. That is something that comes up with an IANA delegation. And the way that the community support for the manager is decided is being dealt with exactly the way that it has been dealt with so far for ccTLD delegations. So nothing there has changed at all. I am really not the right person to go into details about that right here. There was a link online. But I do need to refer to my colleagues at IANA to go through how that is dealt with. Your second question was dispute resolution. There is no requirements from ICANN about how to deal with dispute resolutions on second-level registrations under your IDN ccTLD, if that was the question. That is a local matter. You know, the generic dispute resolution rules around gTLDs might be a guidance for you and a help. But it is a local decision on how you want to deal with that. So -- >>IMRAN AHMED SHAH: Excuse me, but -- >>TINA DAM: -- ICANN -- Sorry. Go ahead. >>IMRAN AHMED SHAH: But if it relates with top-level ccTLD, IDN ccTLD, then what? >>TINA DAM: Disputes at the top level? >>IMRAN AHMED SHAH: Yeah. >>TINA DAM: So for the fast-track process, we don't expect to have disputes, because all of the IDN ccTLDs have to be representing country or territory names. If there would be a situation where there would be a dispute between two country names that are so similar that there would be problems between them, then we're going to have to take that as a separate communication. There is no specific dispute resolution set up for the fast-track process. >>IMRAN AHMED SHAH: Excuse me. No different countries, but the same country, if -- >>TINA DAM: Oh. >>IMRAN AHMED SHAH: -- the community's demanding a good name, but the government has applied full name, what will be -- happen? For example, in our case, the government has applied in -- last October for dot Pakistan, a complete, full name. We can't understand. A community is not convinced with this. We need dot Pak. How we can enforce government, as public, as a community on the lower level? >>TINA DAM: Okay. So, I'm sorry, now I understand your question better. That is not part of the fast-track process. That is something that needs to be decided locally. And, you know, it's a local discussion. As soon as the local community and the government have decided what they want and what string they want, they can go to ICANN and request it to be delegated. But for any disputes within country or within territory, ICANN has nothing to do with that. >>IMRAN AHMED SHAH: But what ICANN will do for the evaluation of the strings? As IDN ccTLD for a territory or country? >>TINA DAM: If we see disputes coming from within one country or territory, we're going to put those requests on hold and we're going to inform the requesters of those strings that we've put them on hold until the disputes have been solved locally. >>IMRAN AHMED SHAH: If there is no dispute, what is the procedure for the evaluation of the string? Will you go to the local linguistic peoples? >>TINA DAM: If there's no disputes. >>IMRAN AHMED SHAH: Yes. What is the criteria evaluation of the string when -- >>KURT PRITZ: Yeah, so let me interrupt for just a second. Tina, we have a long queue, and we're almost out of time, sir. So, Tina, can you take your best shot at answering the question, and then we'll establish an e-mail contact after that. >>IMRAN AHMED SHAH: Okay. Proceed to next question. >>TINA DAM: Okay. Thank you, Imran. And I'll make sure to follow up with you. >>IMRAN AHMED SHAH: Thank you very much. See you. >>IZUMI AIZU: Okay. Hi, Tina. This is Izumi Aizu. This time, I'm a member of the newly established body called the Japan Internet Domain Name Council. I'm not representing it at all, but I'm a member of its steering committee. I have some sort of strange question about the structure of the evaluation and the fee. It says that the $26,000 fee will be invoiced after you receive the request. Request for the evaluation of the strings? Or the delegation? Or what if they are separate or the evaluation fails? Are you going to return a portion of it or what? >>TINA DAM: So as soon as you go to the online form that I showed and you go through the entire four or five pages of it and submit the request and confirm that you've submitted that request to ICANN, -- >>IZUMI AIZU: For the first -- for the initial one, you mean, the string evaluation request? >>TINA DAM: Yeah. As soon as we start evaluation of it, we're going to send you out an invoice as well. If it fails, there is no schedule for refund of it, because it still has a cost. That is solely a processing fee. It's a fee for having the string processed for evaluation. But, you know, I hope very few strings are going to fail that. And if there's a problem with a certain string, maybe it's a technical problem and so forth, you know, maybe the string will be turned into something else, a different string that can process through the evaluation and, you know, still will be useful for the community. >>IZUMI AIZU: For the requester. So this means that the original requester is responsible for the fee, not the delegated manager? >>TINA DAM: The requester is responsible. Whether or not the requester wants to hand over that -- the burden of that cost to the manager is, yeah, a local decision. It could be the government paying for it. It could be the manager, based on expected revenue, or it could be different ways. >>IZUMI AIZU: Okay. Thank you. >>TINA DAM: Thanks. >>HARALD ALVESTRAND: Hello. Hello, Tina. >>TINA DAM: Hey, Hal. >>HARALD ALVESTRAND: I'm Harald Alvestrand. I'm on the board of ICANN and have been, together with Ram, chairing this committee on variants. I just wanted to say a few words about variants. What the technical group found when investigating the variant problem was that the main issue, the most difficult issue with handling variants is actually not the DNS. It's inside the applications. So the recommendation from the implementation support team is that one of the conditions for delegating a variant is actually documenting how you are going to inform the users -- the user community that sets up Web service, mail service, and all other kinds of service in those domains -- of what they have to do. I mean, these are people that have no relationship with ICANN, no relationship with the DNS manager. But they have to do configuration of their systems to handle the variants. And so -- And, as usual, things took a little longer than expected, so the report is not out yet. But I do recommend reading the report and where the difficulties actually lie with implementing variants. We looked at both the DNAME method and the parallel delegation method. Both have advantages. Both work in some cases. But the main problem is really at the end user applications. And that's a problem that is outside of ICANN or DNS control. Thank you. >>THOMAS NARTEN: Hi, Tina. This is Thomas Narten here. Good to see your face here. I don't really have a question, but I did want to say thanks. Thanks to you -- and this is coming from me personally -- and just to sort of reflecting on this a little bit, I think you've been just key to this whole IDN program and getting to where we are today. We're this close perhaps to being where you want to be. And there's more work to be done. But I can't imagine we would be here without you having done all the work you've done. You've been a huge help in working with the technical community. I mean, I think this community here doesn't fully appreciate that, because they don't see it. It's a lot that's happened behind the scenes, going to the IETF meetings, a lot of e-mail and phone calls. But I have seen parts of that. And, again, I don't think that we would be where we are today without the work that you have done in being able to channel the concerns from the technical side back into the ICANN process and make sure that everybody's being kept honest. I think I view it as sort of the tip of the iceberg here. People see you and what do you but don't know what else is going on underneath and behind the scenes. I know you've worked tirelessly to get IDNs off the ground and to see them. You're very passionate about that. And I really wish you could have been at the reception this evening. We'll be there and thinking of you and do a toast for you. And so just again, you know, I just want to say a personal thanks for me. I'm sure that I speak for many in the technical community in saying thank you as well and probably for many, if not all of the people here in this room as well. So thanks, Tina. [ Applause ] >>TINA DAM: Thank you. [ Applause ] >>CHRIS DISSPAIN: That's pretty much a fair bet someone would make you cry, Tina. >>TINA DAM: I'm sorry. Well, I started off crying. I knew it would happen at some point. >>CHRIS DISSPAIN: I -- Sorry to do this. But I want to go back to variants just very briefly. [ Laughter ] >>TINA DAM: That's going to make me cry even more. >>CHRIS DISSPAIN: You'll be sobbing by the time I finish. Just clarify something for me. We're into the future, and we've got the capacity, possibility, whatever you want to call it, that those reserved -- my reserved name that I want that's a variant can actually be used. Is that a separate delegation? >>TINA DAM: Well, so I don't know yet; right? >>CHRIS DISSPAIN: Okay. >>TINA DAM: I mean, if it's a separate -- Do you mean like NS record delegation or -- >>CHRIS DISSPAIN: Well, -- >>TINA DAM: It could be; right. >>CHRIS DISSPAIN: Perhaps it's fairer if I just put it another way. The fast track -- the fast track very, very clearly states, one name per language because until such time as the policy development process for IDNs is completed, we don't know what the fundamental -- what the policy will be for the number of -- the number of names. Now, if what we're talking about is simply a sort of twist to enable a slightly different character to be used, then that's one thing. But if what we're talking about is, effectively, two delegations and two names, then that is another thing. And then that is actually outside of what the fast track is meant to do. >>TINA DAM: Right. So I think what we need to do with these variants is we kind of need to separate the technical piece of it and whether that's a separate delegation or not, and take that as one piece. And then the other piece is, well, if it's a variant TLD from the user's standpoint, it's really considered the same string, at least in most cases. I know not in all. But in some cases, it's considered the same. So we're really just talking about two strings that are the same one name for that country name. >>CHRIS DISSPAIN: Fine. >>TINA DAM: So, from a policy standpoint, you can talk about that as being the same delegation. Technically, it might be different. >>CHRIS DISSPAIN: So, okay. And in that case -- and this is my final point. In that case, surely, we will need, before we do this, before we start considering delegating variants or whatever you want to call it, surely we need to have some IANA policy to deal with this. Because right now, we don't. So what would happen if you do have technically two delegations into the root and then you get a redelegation request for one and not the other? Or all of this stuff needs to be dealt with. And surely the only way to deal with that is in some sort of policy development process for IANA. Or am I way off beam? Because if -- You know. >>TINA DAM: So I think that's more of an operational way of managing it, where IANA needs to know that those two strings are tagged in some way so that they're handled, you know, in the same way. I don't necessarily think that that's so much of a policy, at least not in the term where the ccNSO and the GNSO is talking about policies. >>CHRIS DISSPAIN: Okay. >>TINA DAM: The only other thing that I can say about variants is that we all want the variant strings in the root so that users can use them and so that IDNs can be really useful. So we just need to get into a place where we're all on the same page in terms of getting that process up and running. >>CHRIS DISSPAIN: Thanks. >>TINA DAM: Thanks. >>NAOMASA MARUYAMA: Hi, Tina. This is Naomasa Maruyama from Japan. But it's not important point. My question is about the deadline for the application. My understanding is that the applying for the IDN ccTLD is some kind of a genuine right for each territory and country, so that my feeling is that there should not be the time limit for the application. Is that a right understanding or not? To look at the gTLD application, there should -- there will be time limit for each round, third round start from this time and they close in that date. That seems to be reasonable for the administrative reason. But I think for the IDN ccTLD, there's no similar reason, so there should not be a time limit. Is that a right understanding or not? >>TINA DAM: That's through rightly understood. There is no rounds for the fast track. The online form, as soon as we open, and hopefully that's the 16th of November, as soon as we open to accept requests, it's going to be open until we're going to announce that it's closed, which is expected a few months before the long-term policy has been implemented. So that could be a few years down the road. And we're going to announce it in a timely manner. And you will also know when we get close to that. But other than that, you can apply and send in your request at any time you want, and any time you are ready for it. >>NAOMASA MARUYAMA: Thank you very much. That, I think, is a very important point, because probably we can spend a lot of time to settle the dispute among -- inside the country or territory. Thank you very much. >>TINA DAM: Sure. Patrick. >>PATRICK JONES: Hi, Tina. Patrick Jones, ICANN staff. I have two questions from the chat room, and they are short. The first one is from Rahman Khanjohn who said, should the ccTLD authority and the IDN ccTLD authority be the same or can it be two different organizations? And then the second question is from Jorge Amodio who said, how many IDN ccTLDs are expected? What's your guess/estimate? >>TINA DAM: Okay. So the last one first. Based on all of the information we got from different countries and territories and different ccTLD managers, we are guessing at about 50 strings over the first couple of years. And so if you think that the fast-track process will run for a couple of years, that's the approximate number. It could be higher than that because there are certainly countries and territories that we haven't heard from, but that's sort of like a first-line guess. What was the first question again? Who was the same? >>PATRICK JONES: Should the ccTLD authority and the IDN ccTLD authority be the same? >>TINA DAM: Oh, yeah. So you know what the answer is to that yourself, too. But no, they don't have to be the same. In some countries and territories, they specifically want them to be the same, because they want to operate them in a specific manner. In others, they want to create more competition and diversity in the country or territory, and they can be different. So it's a local decision. ICANN has no requirements in that regard. >>PATRICK JONES: Thanks. And really great job. >>TINA DAM: Thanks. >>KURT PRITZ: So this will be -- We have one more question and then I will close off the queue. >>YALING TAN: It's not a question. It's just an observation. Actually, I would like to thank Tina for the statements and for the variant management. Actually, for the case of China, we apply for both simplified and traditional Chinese dot China. Actually, in the opinion of Chinese people, although these are two variants, but actually they are regarded as one string and one delegation. Thank you, Tina, for the comments. >>TINA DAM: Thanks. >>KURT PRITZ: Tina, do you have any closing remarks? >>TINA DAM: Are we closing off? >>KURT PRITZ: Yeah. Yes. >>TINA DAM: Can I just say one more thing? >>KURT PRITZ: Sure. >>TINA DAM: I really hope you guys all have a great IDN meeting, so please go to the reception and have fun. The camera crew that you have seen around have recorded a video with some of the participants in this meeting. I think some of you are in the room. And I just heard the video was finished and it's ready and it should be a lot of fun. So please go and have a great time. And thank you for letting me be up here on a screen. [ Applause ] >>KURT PRITZ: And thank you very much, everybody, for participating in this session. And thank you, Tina. Excellent job. >>TINA DAM: Thanks.