ICANN Cartagena IDN ccTLD Fast Track Process Review 6 December 2010 5:30 p.m. >>TINA DAM: Good afternoon, everybody. My name is Tina Dam. I'm with ICANN staff. I just want to mention to you that the session for the IDN ccTLD fast-track review is going to start in about five to 10 minutes. There's a slight overlap with another IDN session going on from the JIG, and so I agreed with Edmon, who is the chair of that session, that he was going to stop a little bit early and we were going to start a little bit late to see if we could get everybody to complete that session and join this session, so we're just going to wait a few more minutes before we get started. All right. Good afternoon. I think it's time to get started. My name is Tina Dam. I'm the senior director for IDNs at ICANN, and this is a session for the first annual review of the IDN ccTLD fast- track process. With me, I've had Patrick Jones, and Patrick is familiar to most of you. He's really in the ICANN security department, but has been helping out with IDNs so Patrick, do you want to just mention a little bit? >>PATRICK JONES: No, I've -- Patrick Jones and I've had the good fortunate of assisting Tina with the fast-track process since it began and happy to be here today. I'm also managing the chatroom, so if anyone has questions either remotely or in the room to raise them and I'll make sure that they're addressed for today. >>TINA DAM: Right. So we're going to try to make this a very interactive session, so those of you in the room here locally, you're a little bit spread out but get ready to get up to the microphones because we need your feedback and ongoing discussions. And of course those on line get ready as well. I'm going to do just a quick status on where the fast-track process is, and after that we're going to have six different topics that also have been posted publicly as discussion topics for the review of the fast-track process. After each one of them, we'll have open microphones, so the intention is that we'll discuss every single topic separately, and then of course at the end there's an open microphone for any additional topics that you want to raise. Now, the intent with this review is of course to make sure that the fast-track process is continuing to function well for all participants, and in that review which will be an ongoing annual review, we have the opportunity to make adjustments or amendments to it, so please be creative and come up with ideas if you thing there's something that needs to be different. So here on the first slide, just a brief status. The column on the side there shows you the list of the IDN ccTLDs that have -- the strings that have been approved, so as you can see, it's quite a bunch there. The launch, of course, was just over -- just over a year ago, on the 16th of November last year. Since then, we got 35 requests in total. 22 -- so that's not countries and territories, but 22 countries and territories have passed the string evaluation. 15 strings are in the root. We have a total of 22 languages represented. And if you compare it to what was expected -- and that expectation was based on the feedback we got from ccTLD managers and governments -- there was an expectation of 50 strings covering 15 languages within the first two years. So we're -- you know, it kind of looks like we're pretty well on target. If you do take a look at those interests that have been indicated, only a few countries have actually not submitted their request in the fast-track process, so we're pretty well underway for what was expected. All right. So the first subject under review is transparency, and I'm just going to be like very brief on it. A request or information related to a request is not made publicly available until the string evaluation step has been successfully passed, and that's the part of the process. Of course that's very beneficial if you think about it being confidential from the applicant's side of things. It also means that any kind of not valid requests are not being publicly announced, which otherwise could create confusion within the region or in the country. But of course on the negative side, communication with end users and interested parties becomes more difficult because ICANN staff is not allowed to communicate what countries and territories have applied, what have they applied for, or anything like that at all until string evaluation has been passed. So it's an open question about whether applications or requests should be published at an earlier stage, and with that, I'm going to see if there's anybody that have any comments or opinions on that. >>PATRICK JONES: And this part is questions about either the transparency of the fast-track process or the -- the release of information during the evaluation of requests? >>TINA DAM: Yeah. Any type of transparency, if you have any -- you can also come to the microphone if you think that everything is great because then it's going to be easier for us to just check that off the list and we'll go on to the next one. And it looks like we have nobody. >>PATRICK JONES: So while we're talking about this, we might want to remind everyone that the review of the fast-track process has been posted for public comment and when the deadline is for -- for that. >>TINA DAM: Yeah. So the on-line public forum is open until the 17th of December, so if you change your mind and you still have comments, you can give those in written capacity. And of course anything that's commented here in the session or on line publicly will be taken into consideration as review. Okay. I will take it that we'll move on to the next review topic. So the next one is community support. And that goes to both demonstration of community support for the string and the IDN ccTLD manager. That either is decided early on or later in the process, and as you can see on this picture, there of course is different approaches in community support depending on where in the world you are located. We have one example up here, and there's many different ones, and because of that and because we want to allow that diversity, this is something that's very open for the -- for each applicant to determine how they want to demonstrate their outreach and their community support. But it's important to note that there needs to be community support for the string in the string evaluation portion of the process and there needs to be community support for the IDN ccTLD manager when the process -- or the application enters into the delegation process. Those two things have been a little bit confusing for some applicants. They've felt that if they demonstrated community support for the string, that that was sufficient and they didn't need to demonstrate it later on. It is two completely separate processes. It is even different staff. It is different criteria. So we have beefed up the communication, information going out to applicants, a little bit, but I do want to mention here to those of you listening in that you do need to remember that you have to demonstrate both. That doesn't mean that you need to do two types of outreach. You can do an outreach for both the string and the IDN ccTLD manager at the same time. It just means you need to demonstrate it at two different points in your application process. >>PATRICK JONES: Can you mention some of the types of examples that have worked for community support so far? >>TINA DAM: Yeah. So we've seen a lot of variety. We've seen e- mail surveys. We've seen local events having been held. Newspaper advertisements. Technical fora discussions. There's just been everything imaginable. And that, of course, needs to continue to be that way, so that it works for you in the local community. Did you -- Patrick, you know as well as I do the different types, so... >>PATRICK JONES: No, I think those are, you know, good examples of what's worked. Some of them, I think, also showing the history of the discussion of the string in the local community and those have been examples. >>TINA DAM: Yeah. So it doesn't mean that you have to select any of those. If you have any creative ideas for how you would like to do your own outreach, you can do this in obviously different ways. So when it comes to documentation that goes in to ICANN, we see minutes of meetings. We see on-line sites of votings, documentation of the surveys, and, you know, all kinds of documentation like that related to what kind of teacher that has been taking place. Now, the question on this subject under review is what level of community support is necessary. And some have communicated that they think that if there's a government support documentation involved, then it's not necessary to do any additional community outreach, and so that's one of the questions we're opening up for discussion here. So, again, I will invite you and we have people coming to the microphone. That's great. No, it is not coming to the microphone. All right. Well, the other thing you see on this slide here is questions guiding applicants into, you know, how to provide us with documentation, and I'll say that the more information you bring up front of course the easier it's going to be. If we do have questions in the evaluation of community support documentation that has been provided, then we will, of course, communicate back and forth. So this is not a one-way street. We will e-mail and talk to you guys on the phone and any other way if it's necessary. All right. If there's no comments on community support -- and again, I mean, you can ask questions or say, "Yeah, this is understandable" or not. It is the staff experience that there's been a lot of confusion on this subject, so we do want to try to make things clear for everybody. >>PATRICK JONES: We have a question in the -- oh. So IDN gTLD fast track in the comment forum. This is your chance to ask questions related to the fast track. If you can hear us on line and this is an opportunity to raise questions. >>TINA DAM: All right. We're going to go to the next subject. And this is meaningfulness. A string that's asked for in the IDN ccTLD fast-track program has to be meaningful, and that means it needs to be a meaningful representation of the country or the territory name. In other words, applicants can't apply for dot anything they would like to have. It needs to be the country name, territory name, or a representation of it. There's basically two sides to this -- very simple -- in the fast- track process. Either this requirement is auto-fulfilled, if the country name or the short name of it is on the UNGEGN list. If it is not on that list, the applicant is required to provide documentation from a linguistic expert. Now, as with the other subjects, we've gotten comments and feedback to, "Can we find other ways to make this an ought fulfillment without needing a linguistic documentation being provided?" I will say from the staff side, we didn't have a lot of good ideas for how else would you auto-fulfill this requirement. It is also our experience that those who have needed to get a linguistic documentation support have not had a lot of difficulty with that, and certainly it hasn't been something that has been declined from ICANN either. A couple of instances we have helped finding a linguistic expert, and that opportunity, of course, is open ongoing for all applicants. But if there's any of you that see a good way for auto-fulfilling this type of requirement other than being on the UNGEGN list, then we'd love to hear it, and of course if that's something that's reasonable and make sense and demonstrates that the string is indeed a meaningful representation of the country or territory name, then that would be an obvious addition to have in as a check in the box in auto-fulfillment. And it looks like we have no comments. Patrick, do we have any comments on-line? >>PATRICK JONES: Not so much a question about this section, but if some do come in, then we can raise them here. >>TINA DAM: All right. This is going to be an easy session today, and it's probably going to be the least commented IDN session I've ever hosted. But that's great. And I just want to make sure that you understand that we will take it as you are basically saying that you think it's going great, so if you do have anything you want to change, you -- I do want you to come up to the microphone. But I also know there are a couple of parties after the session, so maybe that's what everybody is waiting for, to be released for. Okay. The next subject is IDN tables, and this is perhaps a little bit more technical oriented. We have these IDN tables that is basically lists of the characters that each IDN ccTLD manager will support and offer in domain names under their IDN TLD. The content of these tables have not been evaluated or approved pretty much in any way whatsoever. Staff does look at them and check that they fulfill requirements in the IDN guidelines, and to see if there's any, you know, direct security issues related to it. But other than that, we do not go through the content of the tables or approve them. And there's been a little bit of a misconception that the DNS stability panel is conducting that work, and I just want to be very clear that they do not. But because there's been some questions about this, and specifically questions related to are these tables good enough, does it create a secure enough environment for our users, we raise it as a question: Should there be any requirements or any additional reviews of these table -- should any of that be taking place in the process? Some of the feedback that we had gotten was that people thought we would evaluate the tables, and because of that they would just take an existing table that had already passed through the system and they would think that that had been approved, but it hadn't really. But because of that, applicants would essentially send in tables that did not entirely match what it was that the community needed. They would just send it in because they would hope that that would get them a check in the box and it wouldn't raise any questions. So that, of course, is not a good outcome of something that's not being reviewed or approved, so the question is: Should there be more checks in place for reviewing these tables and approving them. >>PATRICK JONES: But at least today, all requesters submit a table with their IDN request -- >>TINA DAM: Yeah. >>PATRICK JONES: -- and it's after delegation all those tables are posted for public view in the IANA repository? >>TINA DAM: Yeah. So the tables are required to be posted in the IANA repository, and it's something that's -- that we're going to take up with all of those IDN ccTLD managers that are -- have their strings live in the root and are launching. You do have to send those tables in to the IANA repository for posting. That, of course, can raise questions, but we have -- >>XIAODONG LEE: You mean the IDN table is the IANA table, right? >>TINA DAM: The IDN table in the IANA repository, yeah. >>XIAODONG LEE: But from my point of view, you know, dot CN, dot TW submit the IDN table firstly to IANA, but to -- you know, now I review the IDN table in IANA, and not all of the table is following the -- I mean, the rules defined by the RFC 3743. So the -- I mean, the format of the table is wrong. So I don't know who will check the table, who will evaluate the table. >>TINA DAM: Right. So that's -- that's the question I'm raising. And so it sounds like you have an opinion on it. Right now, nobody is vetting those tables. >>XIAODONG LEE: Sure. I mean, if ICANN want to follow the table registered IANA, but I -- I mean, now, the table registered in IANA is not perfect. >>TINA DAM: Right. And some of the tables that are in the IANA repository are tables that are not relating to the IDN ccTLDs, which could mean that we don't have any mechanism in place for saying -- other than just providing straight out information, saying this is incorrect. >>XIAODONG LEE: You know, for the -- for the IDN table, you know, the -- all of the character, I mean, displayed in that first column of this table mean that the character scope for the IDN registration, and the second column and third column mean the preferred variant and the variants. So I mean now the table in IANA different kind of format. It cannot be decided what kind of scope for this language and if they're variants or not. I mean, there is so many problems for that. >>TINA DAM: So let me ask you: Do you think that ICANN should form like a panel or a group who should review these tables for content? >>XIAODONG LEE: Sure. Sure. >>TINA DAM: And -- yeah. >>XIAODONG LEE: Sure. If ICANN want to follow the table in IANA so I do not -- maybe some kind of evaluation panel should be formed to evaluate and improve the IANA table. >>TINA DAM: Right. >>XIAODONG LEE: Yeah. >>TINA DAM: One of the things that's difficult with that, of course, is I think it's going to require a lot of linguistic expertise. There are some tables that will be different, even though they match the same language or script, just because of the nature of the TLD and the community they -- >>XIAODONG LEE: Sure. >>TINA DAM: Yeah. >>XIAODONG LEE: It maybe depend on the registry, you know. For -- the Japanese table for dot b is totally different table versus the table for dot jp, so it looks like very strange. It's a Japanese domain name. But I don't know what kind of table you follow for -- maybe for the Japanese (inaudible). It should be that dot b is Japanese table or dot jp is Japanese table? >>TINA DAM: Yeah. So I think between the gTLDs and the ccTLDs there will be an obvious difference, the difference being the gTLDs often support more languages and scripts, or multiple ones, whereas the ccTLDs -- you know, not all but -- tend to be more localized. And so because of that, there will be differences between the tables, but that doesn't mean that we shouldn't set requirements up. So, Xiaodong, if you have any good ideas for how those types of requirements should be set and evaluated, that would be, you know, helpful. >>XIAODONG LEE: I have no exact suggestion to ICANN, but I think that two suggestions maybe should be considered for ICANN. The first one, a evaluation panel maybe should be formed for ICANN to evaluate the table. And the second one, maybe ICANN can conduct some -- maybe some specific community. Maybe for Chinese city (inaudible) for Chinese domain name and for Japanese, maybe -- I don't know if there's some kind of Japanese linguistic community. >>TINA DAM: Yeah. >>XIAODONG LEE: So it depends on what kind of language. Maybe ICANN can conduct different kind of community to do that. >>TINA DAM: Yeah, I think that's right, and I think that's a really good point. For example, we have the Arabic script working group that are working on table for Arabic that can be used -- >>XIAODONG LEE: Sure. Sure. >>TINA DAM: Yeah. >>XIAODONG LEE: Sure. >>PATRICK JONES: Yeah. And this is an area where input would be helpful because tables is an area where there might be security issues if, you know, the -- >>XIAODONG LEE: Sure. If you -- >>PATRICK JONES: -- tables are different depending on the scripts. >>XIAODONG LEE: If you use the wrong -- if the registry uses the wrong table it will cause a very terrible issues for security. For example, the phishing issues. You know, if you use the wrong table, the phishing problem is very terrible. Yeah. Thank you. >>TINA DAM: Okay. Thanks, Xiaodong. Ram? >>RAM MOHAN: Thank you. Ram Mohan. Two comments. One, I think it's time to -- for ICANN to stop trying to publish this IANA repository of IDN tables. You're doing yourself, I think, some unnecessary damage. But more importantly, it doesn't scale. As you yourselves have pointed out, as you have more applicants both from the gTLD IDN side as well as the ccTLD IDN side coming through submitting different language table -- language tables that purport to be for the same language but are completely different or somewhat different, you really are creating a -- a -- not you. This creates a significant mess and it's a mess that once it gets tangled is very difficult to disentangle, so one very direct suggestion is please stop this. It was intended originally to serve a particular need, but you're probably better off redirecting users to the registries themselves. I'm not saying stop the applicants from submitting the tables and, you know, going through that that vetting process, but if you, ICANN, or if we, ICANN, publish that in a repository, then we take on other responsibilities, including keeping it up-to-date, so on and so forth and it's not really compliance but you have tremendous confusion that starts from it. So a clear recommendation is: Stop publishing an IANA repository of IDN tables. I don't think it serves its purpose anymore. The second suggestion is, you're saying here that there is going to be some limited staff review and feedback in the case of security issues. I'd caution you on taking that task up because I can imagine several scenarios where a TLD operator or an applicant submits a table -- since there is really no review, submits a table that crosses multiple scripts or does a lot of things that are not obvious, and if we -- if you say there's going to be some limited security review, it may not be sufficient. So try to be a little bit more black-and-white on this, even though it will make applicants unhappy, it will make some other folks unhappy, but this is one of those things where getting a -- doing a limited review might cause unlimited problems. Thank you. >>TINA DAM: Yeah. So just to give you a little bit of feedback, Ram -- and I agree with what you say, but, you know, it also is a difficult balance. First of all, of course the intent with the IANA repository was to share these tables, so that a table for a certain language used by one TLD operator could be used by others who want to support the same language, and obviously that is not what we have accomplished. But the intent was to create some sort of unity. >>RAM MOHAN: Right. It was a good intent. >>TINA DAM: Yeah. And what resulted out of it was confusion. So we didn't really reach the goal that we had set in mind. The thing about the limited security review that we're doing, it does relate to the IDN guidelines, and that's the only -- well, and slightly to the IDNA protocol, but that's the only spec that ICANN staff is doing at this point in time. I do think that that's important, but I agree with you, we can't go and say, "Because it follows the IDN guidelines and because it follows the IDNA protocol, we are sure there is no security issues." That's not a result out of that -- >>RAM MOHAN: Yeah. >>TINA DAM: -- but we do need to do the checks against those two technical standards. >>RAM MOHAN: So let me briefly clarify. I completely endorse what you're doing in terms of checking against the guidelines. I was merely commenting upon security review as compared to IDN tables. I don't think -- >>TINA DAM: Yeah. >>RAM MOHAN: -- conflation is good. >>TINA DAM: So I think my slide is maybe a little bit easier to misunderstand and -- but what I said was it's against the IDN protocols in the protocol. >>RAM MOHAN: And that's a good thing. >>TINA DAM: Yeah. Great. >>PATRICK JONES: There's a comment from Jaap Akkerhuis in the chat. It says "If ICANN is going to evaluate tables, it's directly getting involved into registry naming policy and it's something that we should be aware of." >>TINA DAM: Yeah. And that has always been one of the reasons why we're not evaluating tables, so -- >>HARALD ALVESTRAND: Harald Alvestrand. A couple of comments. One is that you need to evaluate tables for correctness. We have had cases where, due to the no review policy, we have published tables with rules about characters that were not allowed in IDNs. That's just wrong. And so striking the word "security" in that review thing is probably a good thing. Because we're reviewing them for not being total nonsense and I think that's a good thing. Another thing -- two other things we might consider is (a) whether we could actually come -- publish or cause to be found a competent linguistic commentary on tables. I'm not sure any competent linguist would want to comment on the tables but if such commentary were to arise it might be good to store it somewhere. And the other thing is whether it would be reasonable to give some brownie points or a feeling of goodness -- I don't know if we have anything else -- to people who choose to reuse an existing table instead of creating their own. I don't think we should get very strict about tables. I know all the reasons why we ended up here, or a good number of the reasons why we ended up where we are, but I do think that the current chaos of tables is less than optimal and we should see if we can find some way to incentivize people to do a little better. >>TINA DAM: Okay. That's great. So, Harald, one feedback to you is when you talk about, you know, checking whether the tables are correct or not, do you mean according to the IDN protocol that a character that's in the table is actually valid? >>HARALD ALVESTRAND: Yes. >>TINA DAM: Okay. >>HARALD ALVESTRAND: According to the specification of the table, the syntax of the table is actually parsable and that all strings generated by application of the table rules are valid IDN strings. For instance, if you have a table rule that purports to be for Arabic which allows the domain name to start with a digit, that's probably not -- not what you can express with an IDN table. But it is the kind of situation where you want to look carefully at it. >>TINA DAM: And I think it is those kind of situations that becomes difficult because one thing is to look at a certain character and say, Is this valid according to the protocol? But there are those that, you know, have registration policies associated with it. And I think -- I mean, I think I kind of know where -- what it is that you're saying that we should do, but I'm just saying I would also caution for going too far down that road because we are getting into business decisions for these ccTLD managers. >>HARALD ALVESTRAND: I mean, a domain name registry that by part of its application flagrantly indicates that it's going to not obey the IDNA protocol needs to be slapped down. I don't think we can do much more than that. >>TINA DAM: All right. Thanks, Harald. I wonder if there is any opinion about whether those kinds of checks should be done by ICANN staff or if we should set up, like, panels or external experts to do this kind of work or if you are comfortable with ICANN staff doing it. But I leave that as a question that people may want to think about and we can take up in the public forum. >>PATRICK JONES: So I know this is for the fast-track process, but setting up a panel is something that isn't easy to do. And is it something that could also be applied to IDN strings that might come up in the new gTLD process? >>TINA DAM: Yeah. I mean, this whole notion about IDN tables, of course, goes across all of the processes. There's not special rules around IDN tables for fast track versus gTLD. It is exactly the same. So, yeah. >>PATRICK JONES: So in the chat, Mohammed El Bashir has a comment and a recommendation that an example of this is Arabic language tables uploaded by other registries, which Arabic is not their language and that a recommendation is that this could be done by a linguistic panel. >>TINA DAM: Right. All right. We have two more topics before it is open for any topics you're interested in. So the next one is dispute, and the one after that is confusingly similar. So we will go to the disputes. I hope you like the disputes that are on the screen, but, yeah, we'll see. At this point in time, we have not received any controversial strings in the fast-track process in the sense that it hasn't been disputes between territories and countries and it also wasn't expected. And that's one of the reasons why there was no dispute mechanism built into the process. So dispute processes do not exist specifically to the fast-track process. If there are disputes within a country or territory between what string they want or who should operate it and so forth, that is something that's decided locally. And thus far, that seems to be working really well. There is one question that was raised in relation to disputes and that has to do with what if we, for example, get government support in the application and then later on or during the same time period and not a part of the same government states something that could be considered as they are not supporting it. What do we do with those kinds of disputes in the system? As I said, we don't have interdispute mechanisms in place. So we haven't seen a lot of disputes, but some of this has come up. And so it is a question of whether there should be any kind of dispute handling mechanism in the process or not. >>PATRICK JONES: Maybe just to clarify for the group, that this is an aspect that people don't see because strings are only published once they've gone through the string evaluation step. >>TINA DAM: Right. But so in those few cases where there has been disputes, it has been a local -- at least a local experience. And I know there has been some requests for dispute mechanisms being available. It does relate a little bit to the next topic, so I think I'm just going to go on to the next one and that's confusingly similarity. And, of course, that can also be related to disputes. So it has to do with situations where requested strings are confusingly similar to existing strings or other requested strings. And those kind of applications are, of course, declined in the fast-track process. There is a rule that says that you cannot get a string that is confusingly similar to something else. That is -- the confusingly similarity is established by the DNS stability panel. And they have some working guidelines on how to do a very careful and limited approach in the fast-track process. That was part of the implementation plan. We got some feedback about the need for objections or re- evaluations in cases where the applicant or the community that the applicant was going to serve do not agree with the assessment made by the DNS stability panel and where there is basically just a disagreement in their decision. This is not like a big volume. But, of course, if there is disagreement, that's, like, a really important thing for the community in question. So the question we're raising here is, you know, is there a need for objection in the process which does not exist at the moment? Is there a need for any re-evaluation which does not exist at the moment? The reason it doesn't exist is because the fast-track process was built to be very limited. So we don't have that. But it has been asked for, so it is part of this review. And, of course, confusingly similarity, if you have any comments or questions about that in general, feel free. >>PATRICK JONES: So we do have a question in the chat. It's asking if there is an update regarding the situation on either Ukraine or Bulgaria. And also once it is the proper time, the person would like to ask the question. So I'm asking it on your behalf, and they recognize that. >>TINA DAM: Okay. So we've had some discussions about specific countries and territories, discussions and questions about it in different kind of e-mail lists and online announcements and so forth. And it really relates back to the transparency and confidentiality nature of the process. ICANN staff cannot discuss individual requests or applications with anyone else but the faculty. So to the person who is asking online about Ukraine or Bulgaria, the answer is simply that we can't provide any information specific to any countries or territories. The way that staff usually handles that is that we suggest people who have those types of inquiries to either go back to the existing ccTLD manager in the country or to the government in that country or territory because chances are if there is a request that has been submitted to ICANN in the fast-track process, either of the two entities will be aware of it and will be able to facilitate that communication. But we can't talk about it, and that has to do with the nature of things being confidential and, you know, not transparent until the string evaluation has been completed. >>PATRICK JONES: And there is another comment in the chat from Iliya Bazlvankov. They wish to note for the record that the situation with Bulgaria is pretty much well described in the public comment forum. And that's true, we are getting comments in the public forum about particular countries. >>TINA DAM: Right. So there are some public forum comments that states they wish there would be an objection or re-evaluation process available. So is there anybody that would have any comments or would like to discuss that subject? Yes, Hong Xue. >> HONG XUE: I'm not going to talk about any specific case. But I hope the staff, Tina, could help us try to understand the procedure more clearly for this string evaluation. ICANN authorized a body to complete the job, and obviously they're doing very good. But there is some dispute happened on this confusingly similarity issue. But this body, also arrived by ICANN, made the decision on behalf of ICANN, and their decision is actually the decision of ICANN. But the issue here is that their decision is a technical decision, is a decision about the technology issue. And, therefore, it is not subject to the preexisting ICANN reconsideration or independent re-eval process. That's a very interesting scenario. We can see that such a technical decision could have very serious policy implication. And now this being raised to the level of accountability. ICANN is highlighting its mission to be accountable to the Internet user all over the world. And now because of this technical design and re-eval process, somebody will say outsourced from ICANN, now the sum of the users or community are not aware to the remedy process and people read. What is the solution to this? >>TINA DAM: Let me see if I'm going to at least give you some feedback on your question. First of all, the DNS stability panel has two roles. One is more technical to make sure that the string does not have any technical issues related to it. The other one is more linguistic in nature because it has to do with whether the string is confusingly similar to existing strings. So it is not just technical. Hong Xue, the other thing I want to mention to you is this process - - the fast-track process was under development, there was some discussions about whether should we have a specific linguist panel or should we use a tool for comparison between strings such as a tool that's being built for the gTLD program. As I remember it, the feedback we got from the community was no because this will take longer time and it is going to make the process more expensive and we're not interested in that. Of course -- and I'm going to quote that, "of course, nobody is going to apply for something that would be confusingly similar to something that already exists," end quote. It is a difficult subject. I don't think that it is a particular easy role to take on to make that determination. I do think that the fast-track process, the way it was built, was built correctly in the sense that it was a limited approach where there clearly were no issues with because it was the first time that we were inserting IDN TLDs in the root zone. That doesn't mean it shouldn't be different in ongoing processes. It doesn't mean that it shouldn't be different -- that it should not be different in the fast-track process either. But I'm saying at least for this initial round of it, I think we have been better off having a very careful and limited approach. >>PATRICK JONES: I don't think there's anything in the fast-track process that prevents the use of the reconsideration process or the independent review process that's already in existence. >>TINA DAM: Right. Of course, that's available for anybody. >>PATRICK JONES: Yeah. So the particular requester could have used the reconsideration step and opted not to. >>TINA DAM: And everybody at ICANN is able to make complaints to the ombudsman or to use the reconsideration process. Of course, that's available. All right. If there is nothing else on this, then I'm going to open for other topics. And it's basically if there is anything about the fast-track process that you have any questions, comments, again, feel free to say that you love the process, if that's what you do, because that, of course, is valuable as well. I know from the ICANN staff side, we feel that it's going really well. But we also do want to make sure that we serve you in the best way possible. So if you have any comments on it. >>PATRICK JONES: And it has been a little over a year, and I think this shows that processes can work really well. It has been exciting to be a part of it. >>TINA DAM: And there is none. So there is a question online that says, quote, With more delays looming for gTLDs and IDN ccTLDs getting a first mover's advantage on languages, will ICANN be introducing a fast-track process for non- controversial IDN gTLDs, end quote? And that's a question that comes up all the time. It's really -- I'm sorry. It's really not something that I can say much about. I know it has been discussed before. I know it was decided it wasn't possible before. I don't necessarily know if there is more delays looming for new gTLDs. It is a question to the ICANN gTLD team. I know previously they have said they don't see any faster way forward than what they're doing already. But, again, that's a question for them. So... Well, if there's no more questions, then we'll just take a quick look at the next steps for what's going to happen. So as we said, the public comment forum is going to run through the 17th of December. The link is on the slides. The slides will be online, if they're not already. Staff is going to summarize all of the proposals, proposed changes and discussions that we've had. We're going to make that analysis publicly available. We're also going to make it an input to the policy development process that's going on in the ccNSO right now for a longer use of IDN ccTLDs. And if there is any resultant changes, then that's going to be provided to the ICANN board for their consideration. It doesn't need to be a board approval if there is going to be any changes to the fast-track process as it stands today. And then, of course, we'll have ongoing annual reviews. This is just the first annual review. And we will continue having those annually. We can also have them more regularly if that's necessary. And those are going to continue until the ccNSO has completed their policy development process on IDN ccTLDs and until that policy has been implemented. So the fast-track process is going to be open and available until something else is going to replace it. >>PATRICK JONES: For any of the ccTLD managers who have already gone through the fast-track process, if you have observations that would be useful to share, feel free to send those in as well. >>TINA DAM: All right. I think we're going to end the session and happy cocktail hour to everybody in Cartagena. Thanks for limited feedback. We are going to take that as a positive statement. But, again, write online or grab either Patrick or me throughout the week if you have any additional questions or concerns. Thanks.