IDNC working group. 23 June 2008. >>CHRIS DISSPAIN: Well, good morning, everybody. Good morning, everybody. >>MULTIPLE VOICES: Good morning! >>CHRIS DISSPAIN: Thank you very much. I went to the fellowship -- ICANN fellows meeting this morning at 7:45, a great time to start a meeting, and that was how Janice Lange started the meeting. She made everybody say "good morning" and we all felt better. We're slightly delayed because the welcoming ceremony ran over, overran, or whatever. Hey, Bart, you can sit anywhere you like. We're slightly delayed for that, so apologies and there will be people coming in for the next few minutes, I should imagine. Just we're going to go through a presentation on the IDNC working group report, but I don't want to spend a heap of time -- no, I'll start that again. The ccNSO will be doing half a day on this on Wednesday morning. We'll be going through it line by line. Because at the end of that time, we need to decide whether we're going to support it or endorse it, et cetera. So the purpose of -- if you want to do that, then come to the ccNSO session on Wednesday morning. And you don't have to be a ccNSO member or even a ccTLD manager. Come to that. The purpose of this is to give an overview and to answer whatever questions people may have in the best way that those of us in the room who are on the working group can. There is a latest version posted on the Web site. It's -- it has some updates in it from conversations that have taken place. So for those of you who are not necessarily up-to-date with everything, let me just very quickly explain to you how we got to where we are now. The working group was established under a charter and a resolution from the ICANN board. It's been going for a year or so. Our job is to come up with recommendations to see if we can come up with a methodology to fast-track IDNs, some IDNs. We've met. We've had telephone calls and so on. And the process is that the working group report needs to be -- needs to go to the GAC and ccNSO and then go to the board if it's approved. Now, since we've been in Paris, the working group itself has had a face-to-face meeting which led to some amendments to the draft that was posted about a week and a half ago, and yesterday morning Bart and I and Cary and Patrik Fältström sat in on the GAC's session on the -- discussion on the report, and subsequent to that, a few more amendments have been made to try to deal with some specific political issues that arose just to give you one example of what I mean by "specific political issues," a reference to the ISO 3166-1 list as the pool from where IDN ccTLD possible applicants come from is fine, except for one small problem, which is that the European Union does not appear on that list. So we needed to make an amendment to the text to say that for the purposes of the fast track, the -- those people who can ask for one are on the ISO-3166-1 list and the European Union. So stuff like that arose out of the GAC meeting yesterday. So let's get into it. As I said, if you want to look at the document itself, it's on the Web site. I'm just going to find my copy. Okay. So where are we? Here we go. >>BART BOSWINKEL: Yeah. >>CHRIS DISSPAIN: We are rapidly running out of space, but there are some chairs over here (indicating). >>BART BOSWINKEL: Yes. You want for start. >>CHRIS DISSPAIN: I'm just waiting for people to sit down. Okay. So first slide. The reason why we had this process, the reason why we're looking at a fast track, is because the policy development process for policy for IDN ccTLDs is going to take a very long time. Current estimates are 2 to 7 years. 7 years being a time frame that involves works on the basis that the policy development process recommends that there be a mandated list of strings, similar to the ASCII two-letter list, and an estimate that will probably take 3 or 4 years through some sort of ISO or standards institute process. It's going to take a long time for several reasons. It's complicated. There are areas that need to be covered -- there are areas that have been inherited in respect to ASCII ccTLDs on which there is basically no real policy that we are going to need to deal with in respect to IDN ccTLDs, and an example of that is sunset. If -- and this came up in a board briefing yesterday, if I can -- and I'm not picking a particular country for this, but if the name of the country is currently "the Democratic Republic of Chris," and I apply for -- just say dot "the Democratic Republic of Chris" in Chinese, and then in five years' time or seven years' time the name of my country changes to something else, the -- I can't think of another name but it doesn't matter -- I might apply for another ccTLD in Chinese, an IDN ccTLD in Chinese, which presumably I would get because the -- it's the name of my country. But what happens to my old one? And currently, under the ICANN processes with ASCII ccTLDs, there's very little -- there's not really much policy in respect to that. There's a policy on the ISO list that says that the name gets taken off slowly over a period of time, and so on. So there are areas that we are going to need to deal with in this policy development process that are going to take quite some considerable time, so because of all of that and because it became abundantly clear from several meetings last year in various regions -- and mainly in the Arab states -- that there was a serious and pressing need for territories to have some sort of IDN ccTLD now, that's why we started on this process. And the focus of it is to create a mechanism that selects the string and to create a mechanism for designating the IDN ccTLD manager. I'm going to take questions as we go because if we leave them to the end, I'll have forgotten what I've said and then I won't be able to answer them, so if you want to ask a question, just stick your hand up. The way that the working group works -- worked is a starting point at the top with overarching requirements. These are the requirements that the board said we had to treat as overarching requirements, and they're not exactly controversial. Stability and security; the IDNA protocols and guidelines; input from the technical community; current practices for the delegation of TLDs. The working group then created a set of guiding principles which sit below the overarching principles and I'm going to talk through those in a minute. We created a three-stage process: A preparation phase, a due diligence phase and a delegation phase. It involves most of the people who are involved in the IANA delegation process, and it's a checklist type of process. It allows actors in the territory to self-assess, and it allows contending parties within the territory to reach agreement among themselves before entering the process. The implementation of this recommendation, should it occur, is dependent on the conclusion of the current IDNA protocol review. There are a number of technical reasons for that which I don't think really matter. It's just -- right now, it's just a case of it being dependent on that. So the timing, even assuming that everything goes according to plan, there are still some things that need to happen before IDN ccTLDs can bounce into existence. One of the other things we're suggesting is that -- or recommending is that ICANN organize, at a very early stage -- I'll take a step back for a second. If we endorse this report and it goes to the board and ICANN says, "Yep, okay, fine," the next step is for ICANN to ask the staff to prepare an implementation plan. That implementation plan, we don't know how long that's going to take but they will be preparing the implementation plan. We're suggesting that while that is happening, that ICANN organize a request for information process so that every ccTLD is contacted and asked a series of questions by ICANN: Do you want an IDN ccTLD? What language do you want it in? What's the -- what do you actually want? And that way, ICANN will have an idea of the sort of numbers and the sort of administrative burden that this is going to be, and that will assist them with their implementation plan. It's important to know that the recommendations of the working group are mostly at a very high level. The details and processes of implementation are a matter for implementation. And there may need to be some adjustment to current practices and processes. Okay. So these are the -- these are the guiding principles. The first one is that it's an ongoing process. When we originally started talking about this, we considered that we'd have sort of like a window of, say, three months and we'd say, "So, we're opening for IDN ccTLD applications right now. You got to put your application in and in three months' time, there won't be any more applications." That's not going to work, so it's an open process. You can put your application in at any time between now and when the policy is final -- the full-blown policy is finalized. And we'll talk a little bit more about what you need in order to put in an application later on. The second principle is that -- is that as far as is possible, there is no preemption of the overall policy. So nothing in the fast track, unless it's essential, should preempt the final policy. So to give you an example of that, the fast track is built on the basis of one IDN ccTLD for a language in a territory. The reason it's -- one, is because we don't know, in the ccNSO policy development process, whether our policy will be to limit it to one, you know, language in a territory or it will be more than one. And if it's more than one, we don't know whether there will be any limit. So the only thing that we can do in the fast track, so as not to preempt that policy decision, is to say, "It's only one." The third guiding principle is that the purpose of the fast track is to meet near-term demand. The fast track should only be available if there's a pressing demand in the territory. And that's evidenced by demonstrated readiness to operate the IDN ccTLD. The purpose of the fast -- actually, go ahead now. Can I get this other microphone turned on, please? Oh, is it on? Okay. Thank you. >>KEN STUBBS: Yeah, my name is Ken Stubbs. I apologize for interrupting but hopefully we're keeping in the same stream. I'm a little confused here, Chris, because it was my understanding that the original resolution that the board passed was that -- recognized the fact that there could be a need, but it was supposed to be a very limited number of strings. >>CHRIS DISSPAIN: Yes. >>KEN STUBBS: And it seems to me that what has happened at this point in time is that you've developed a process that is strictly based on a determination of territories, this pressing demand, and then you indicate here it's -- it would -- it seems to me that what you have now is a process that every single one of the ISO 3166 cc's, if they determined they have a pressing need, it doesn't become limited. It suddenly becomes -- you've got to have a 160 -- >>CHRIS DISSPAIN: In a little -- sort of, but if you -- if we go through the process, then I think you'll see that there are so many steps along the way to endeavor to lower the number. The working group decided, fairly early on, that it was inappropriate to say, "There should be 10" or, "There should be 20," "Applications should be limited to this number." What we decided and in fact, it's one of the later principles is that the criteria itself, the criteria themselves should be what limit the number. So I'm happy to have that discussion with you, but I think if we go through what the criteria are, then we can assess whether you're right, that the floodgates will open or not. >>KEN STUBBS: Well, the main thing I'm concerned about is, I understand what the working group has determined, but is the working group operating within the mandate that the board gave them? >>CHRIS DISSPAIN: Yes. >>KEN STUBBS: In keeping it limited -- >>CHRIS DISSPAIN: Yes. >>KEN STUBBS: Or is that just -- the board has determined that's the case. >>CHRIS DISSPAIN: No, we are -- we believe that we are operating in the mandate, that it is -- it is to meet pressing demand and a limited number. And you'll see -- and I'll explain that -- why, when we're going through the necessary bits. >>KEN STUBBS: Okay. >>BART BOSWINKEL: It's one of the guiding principles. >>CHRIS DISSPAIN: So that's C. >>BART BOSWINKEL: Yeah. >>CHRIS DISSPAIN: Next one? Now, the next one is that the fast track is only for non-Latin scripts. Now, this takes a little bit of explaining. I'll see if -- I'll see -- I'll give it a go and see how we get on with it. If -- we don't yet know whether it would be possible to have an IDN ccTLD in a script that is essentially -- and I know I'm going to use the wrong words here and Cary, you'll correct me, which is great -- is essentially Latin script that has accents. Decorated, exactly. So if the French -- if the French, for example, wanted to have a ccTLD that had a character that had an acute or a grav or whatever accent, is that an IDN ccTLD or not? And we don't know the answer to that yet, because essentially that is effectively Latin, a Latin character. And there's all sorts of policy questions like, say that the word "France" had an accent on the "E" at the end. >>BART BOSWINKEL: Belgium is best now. >>CHRIS DISSPAIN: Do you want to say it, because now it better than I do. >>BART BOSWINKEL: It's -- if you -- I think the better example is Belgium. In Belgium, if you look through the criteria, you have three official languages. One is German, one is French, and the third one is Dutch. Now, if you would, say, not have the restriction of non-Latin scripts, then, for instance, Belgium, on -- Belgique would not be eligible, or Belgien, which is the German word, would not be eligible, but, for instance, België -- this is the E with the umlaut -- would be eligible. So that's the Dutch version. Then you have all weird kinds of problems if you would not limit it and then you would enter into debate we would be having -- or we had with the GNSO. I think that is a better example. >>CHRIS DISSPAIN: So because we don't know -- because there would need to be all sorts of rules about you must use one letter in your string must have the accent on it, and all of that sort of stuff, we've decided that for the purposes of the fast track, it's limited to non-Latin scripts, which, you know, Cyrillic, Arab Arabic, Chinese, so on. The next one is principle E, and this is a principle that has some alternate views. In the document, there are a number of alternate views. We will get to them. Principle E is that the string and the manager must be noncontentious within the territory. So what that means is that you come -- when you come to on the -- with your IDN ccTLD, you need to show that it's not contentious in your -- in the territory, in the same way -- that's building, basically, on the IANA delegation/redelegation principles that talk about, you know, you come with your Internet community, you come with your government and so on. So we're saying that it should be noncontentious. Now, there's an alternate view, and the alternate view is that, in fact, it should be noncontentious anywhere. So, in other words, it shouldn't just be noncontentious within the territory, but it should be noncontentious to the world. And that's challenging for ccTLDs and governments simply because they say, "Well, no. If it's not contentious in the Democratic Republic of Chris, then that's fine." So principle F is that the selection of IDN ccTLDs is experimental at this stage. Now, the words -- this is not meant to be taken to mean that once an IDN ccTLD has been delegated to you, that it will be taken away from you. And in fact, it's clarified in a bit more detail in the document. But in order for me to see it, I'm going to have to put my glasses on. So the actual document says, "The introduction of IDN ccTLDs is experimental in nature and, therefore, should not be considered to be precedent-setting. The experimental nature of the fast track should also be taken into consideration when delegating names under the fast track. However, this should not be interpreted to mean that a delegation under the fast track will be temporary." So it's a statement about not setting any precedents because the policy itself will eventually decide what is eligible for an IDN ccTLD or not. And the last one is G, which is that the criteria itself determines the number in the fast track, and I notice Ken's not here right now, but I'll explain. One of the difficulties we faced almost immediately, when we started to work in this working group, was the political difficulty, which was that to ask some territories to choose one language over another is almost impossible. There are some territories who would simply be unable to do that. They would -- they would simply not be able to say, "Well, we've decided that our one IDN ccTLD is going to be in -- whatever." So it became clear that we would need to produce -- we couldn't put a limit on the number in a territory, but we could put a limit on the number in a language -- in the language in the territory. So we've done that. But each step of the process is -- has been designed to funnel down the number of territories that actually end up being eligible at the end of the day, and end up using the fast-track process, but we cannot -- and we have no right -- to say we are limiting IDN ccTLDs to the first 10 through the door, because that's just not -- that's just nonsense. Next. Okay. Let's have a look at the process. It's a three-stage process, as I said. There's in territory preparation, there's due diligence, and there's delegation. All the territories listed on the ISO-3166-1 list and the European Union are eligible. There are definitions which we're going to get to. There's a need for a language table for the language, obviously, and there are technical requirements in respect to the string. Okay. >>BART BOSWINKEL: And publication. >>CHRIS DISSPAIN: Oh, and publication of the string, yeah. So here we go, stage one. So stage one is preparing for the fast track in the territory. First of all, you got to be eligible which means you got to be a territory listed on the ISO list or the European Union. You got to meet the meaningful and technical requirements. The script must be meaningful and there are technical requirements. We will get to those. It has got to be an official language. There is a definition of that. We will get to it in a minute and non-Latin script and it has got to be endorsed by the relevant stakeholders. So let's have a look at what is -- what's meaningful and what's an official language. For the purpose of the fast track, an official language -- sorry -- for the purpose of the fast track, an official language is one that has a legal status in the territory or that serves as a language of administration. And there are a list of how that is -- how that is designated but the bottom line is that if the relevant public authority in the territory confirms that the language is used in official communications of that public authority and serves as a language of administration, then even if it is not mentioned in the Constitution or it's not mentioned -- it's not written on the money, it's still an official language for the purposes of this exercise. And, again, this is designed to reduce the number, again, because it's got to be -- it's got to be a language that has a certain status. So what we're not going to have, just to take an example, is Australia putting in an application for Australia -- dot Australia in Chinese because Australia doesn't use Chinese as a language of administration and it is not an official language. The next thing is then you've -- give me one sec. Right. So you select your string. So you got your official language. Now you got to decide what string you want. The string must be meaningful. So for the purposes of the fast track, a string must be meaningful in the official language and it is meaningful in the official language if it is the name of -- it is the name of -- what's that? [ Laughter ] Scary. Now it stopped. Spooky. It's meaningful if it is the name of the territory, it is a part of the name of the territory that denotes the territory in the language. So using English and ASCII as an example -- I've done this one before -- United States of America, it must be a part of the name of the territory that denotes the territory in the language. So dot united does not denote United States of America. Dot states does not denote United States of America. And, in fact, dot America doesn't denote United States of America. But dot USA does and dot United States of America does. Equally dot -- an abbreviation of Rica doesn't do it either. So it's got to be meaningful and it's got to denote the name of the territory. So if it is the name of the territory, it is obviously not a problem. If it is a part of the name of the territory, it has got to denote the territory. And, thirdly, a short -- it can be a short form designation for the name of the territory recognizably denoting it in the indicated language. What that means is you can have an acronym. So Russia can have RF. So there is a list called the United Nations geographic something or other, and number of territories, not all but a number of territories, are on that list. And on that list is their name in long form and short form in some languages. So just to take India as an example, India is on that list. And there is a long and short form name of India on that list but only in English and Hindi. But, nonetheless, it is quite useful for our purposes that in Hindi it is actually on that list. So that's a reference important point people can use to look at in certain circumstances to look at when it is the name of the territory or not. Where the selected string is listed as the long form or short form name on that list, then it is meaningful. If it is not on that list, then the meaningfulness needs to be documented in this process. And additional information may need -- may need to be provided. So you may need to come with linguistic -- independent linguistic experts' report that says, "I conform that this string meets this criteria, is meaningful" because you can't expect the ICANN board to be able to figure out -- unless we suddenly get a wash with multilingual speakers and writers on the ICANN board to figure out what the string is what it says it is. Interestingly enough, I thought the same thing would apply in the gTLD process. You would presumably need to show what you say dot whatever means it actually does mean but that's a gTLD thing so I will leave it to. >> DMITRY BURKOV: Chris, can you clarify what's happened with the discussion about homographic -- >>CHRIS DISSPAIN: That's in the technical bit, and we'll get there. >> ABDOLMAJID RIAZI: Thank you very much. When you talk about the meaningful of this string, it is better to think also about the meaningful of the total address. Then in different languages may they (inaudible) something that will replace -- double as something else or that by something else. When we use mail -- or e-mail address, we like to use other symbol. At, for example, in Persian when we want to have other referred to, write something, for example, Internet in Persian and instead put something else in Iran, the sign, (inaudible) and the name of (inaudible). This completely means that the [inaudible] in Iran. Or when I want to use the e-mail address, I prefer to have my sign -- I mean, Iranian sign. Have you thought about this? >>CHRIS DISSPAIN: No, because we're being asked -- we've been asked to consider -- to consider specifically ccTLD strings, nothing else. And I would be delighted for you to get into a conversation with any of the technical people in this room and ask them whether it's even feasible. I don't know the answer because I am not a technical person. But all this is about -- "all"? This is about IDN ccTLDs, and that is what is to the right of the dot. And, yes, as far as I'm aware it has to be a dot. So you need to talk to some people afterwards about what you've -- your thoughts are on that. Anyone else? Okay, good. So there are obviously some technical requirements as well. There are a number of these, and I'm not going to go through them specifically but, Dmitry, I can tell you that there is an insert to the technical requirements -- it's there, it's there. It's there. It's not there, there will be. There is an insert that answers your particular question about homographs. There is an issue -- Basically, so everybody knows what we are talking about here, there is an issue that certain characters in Cyrillic look exactly the same as an ASCII character, although they are a complete different character. So it would be technically possible for to you have a Cyrillic string that is in Cyrillic but when you look at it, it actually looks like two or three or four ASCII characters. And that would cause confusion. So the classic example, and Russia is used to being used for this is dot RU in Cyrillic is -- looks like PY. And PY is the country code for Paraguay. So there are complications that mean that in the technical requirements there will be certain things that will need to be said, so one thing, for example, would be that at least one character has to be -- has to not be -- not look like an ASCII character so it actually makes it obvious that it's not all ASCII. But I'm making that up as I go along. But the technical requirements are there to make sure that the string and the XN-- and the Unicode codepoints are acceptable and work. So you have to consider the technical requirements. We're still preparing at home. This is still the preparation stage, so you need to meet the technical requirements. Then you obviously need to have some documentation to show that the ccTLD manager who's been selected, that the string is -- the people of the territory are happy with the string, all the stuff you would normally do in an IANA process with the exception of the endorsement of the string because obviously in the IANA process currently with the ASCII two-letter codes, the string itself doesn't need to be endorsed because it has been mandated and it is on the list. In the case of an IDN ccTLD, you would want to see that the string is endorsed. And you need to prepare the language table. Yes? >> ALEXA RAAD: Thank you, Alexa Raad from Dot Org. In this process, is there any kind of validation or question with regards to end user need within that territory? And if so, where does the end user come into play here in terms of terming priority? >>CHRIS DISSPAIN: Thank you. Good question. In the IANA -- in the current IANA process for delegation or redelegation, there is a requirement that you show that the local Internet community is involved and is comfortable. I mean, I'm paraphrasing. I'm paraphrasing, so there is a reference to the local Internet community and their involvement. What we sought to do was effectively include that same reference in respect to the actual string itself. >> ALEXA RAAD: Okay, I guess I am a little confused because there is -- at least in my mind, there is a difference between a ccTLD and perhaps a government asking for the string versus end user demand. So is it -- >>CHRIS DISSPAIN: That's the issue for the territory itself, though. >> ALEXA RAAD: So you are relying on whoever is requesting it? >>CHRIS DISSPAIN: You have to -- >> ALEXA RAAD: They actually have the demand. >>CHRIS DISSPAIN: You have to because it is -- that's an in-territory scenario. The territories -- the governments are very strongly saying, "No, no, our job is in the territory. So we'll show you but it's our job to do it." >> ALEXA RAAD: So if the government says it, then you, basically, take their word? >>CHRIS DISSPAIN: No, there is documentation the same way for the IANA -- I don't take anybody's word because I'm not doing this. >> ALEXA RAAD: Not you personally, but the process. >>CHRIS DISSPAIN: But there is documentation in the same way that there is required documentation in the IANA process to show involvement. The same thing would apply in this. But, fundamentally, yes, you're right. Okay. You need to prepare a language table. Now, the language table may already be prepared because another territory that uses the same language may have prepared it and you may be comfortable using that language table. But, nonetheless, whatever, there needs to be a language table. And, finally, you need to select your ccTLD manager. Now, it goes back to the beginning and talking about readiness and being ready. No one is saying ready in the sense that you must immediately turn on the ccTLD the moment you get it. It is not that. It is about being ready to run the ccTLD. We came up to a hurdle on this yesterday in our discussions with the GAC because there are some governments who would not be able to -- because of the legal processes they need to go through, they would not be able to identify the ccTLD manager until such time as they -- the string obviously hasn't been delegated because it can't be delegated until you've identified the ccTLD manager. But they need to know what the string is. Now, there's no problem with that in the two-letter ASCII codes because the string is what it is what it is. There is a whole series of due diligence processes that need to go through and you don't know you will get the string until such time those due diligence processes have been gone through. So what we agreed yesterday was that either you need to have your ccTLD manager designated or the relevant public authority can act as the driver of this process until such time as the -- until such time as the ccTLD manager has actually been delegated. But, obviously, only up until the end of Stage 2 because Stage 3 starts with request for delegation and there can't be a request for delegation unless you've got the manager. Next? So once you've done all that, you then go to Stage 2 and Stage 2 is the due diligence stage. The first thing you have to do is you have to put your language table if it isn't already into the IANA repository. That's the first thing. Now, having put the language table into the repository, the next stage is that there is a technical review of the string, of the string, of the XN-- string of the Unicode codepoints, et cetera. And, basically, that technical review is there to verify that, one, the string meets the IDNA protocols, et cetera, and, two, there are no technical issues with that particular string. And it's there to ensure the stability and security and interoperability of the Internet. And this technical committee, which the recommendation says should be independent of ICANN but appointed by the ICANN board, has the right to tell you no, you cannot have this string. Because -- this is probably the first thing that this working group reached unanimous consensus on. We cannot have a circumstance where the interoperability of the net is put at risk. And if the technical people say, "This does not work as an IDN because it is outside of the IDNA protocols," then that's it. Even the governments who are, of course, always concerned about sovereignty, et cetera, say, absolutely, if the technical committee says you can't have it, you can't have it. So they, based on the documentation that you send them and maybe after talking to you because they may have questions for clarification and things like that, they will then say, okay, fine, tick, it is okay from a technical point of view. You also need to provide documentation that the string is meaningful. This is a change because up until two days ago, three days ago we actually had in our working group report a linguistic experts panel. And whilst they didn't have a right of veto, they were -- the principal work was on the basis they would evaluate the string effectively. That has simply proved impossible to get consent on -- or consensus on in the working group for a couple of reasons. One reason is because there is a feeling that doing it that way would give the impression at the very least, and possibly factually be that ICANN was moving into linguistic areas instead of technical areas. And, of course, as we all know, ICANN is a technical body and it's not supposed to do anything else. So what we've agreed is that the meaningfulness criteria for the string will be self-assessed but that the territory does need to provide something from an internationally recognized organization and UNESCO is an example. We have other examples, to say the string means what you say it means. Once you've done all of that -- next one. Oh, yes, I'm sorry. Once it has been ticked by the technical committee and so on, it is published, the string is published so people is aware that as of today the Democratic Republic of Chris has applied for dot Democratic Republic of Chris. I'm starting to like the sound of Democratic Republic of Chris actually. [ Laughter ] The string -- I talked earlier on about there being a request for interest phase at the very beginning, where we've recommended the board ask the community -- the CC's to tell them what it is that they want. That recommendation says, "and that information should be published" unless the territory says it doesn't want it published. There may be reasons the territory does not want it published at that very early stage, not this stage but the previous stage. For example, it wouldn't have been checked by the technical committee yet and they might not want to risk the embarrassment by saying, "We will have dot whatever" and then discovering it is a problem and so on. But at this stage, once we get to this stage, clearly it is published and people know. Now, the reason for that is even though it's an IDN ccTLD and, as we all know, the states are sovereign and ccTLDs are sovereign and all that stuff, it is still important that the community at-large knows that Hong Kong has applied for whatever Hong Kong has applied for. So it has to be -- it has to be published. Everyone okay so far? Good. The final point -- the final stage is Stage 3, and that is effectively the request for delegation. So having gone through the preparation phase at home, having had it technically checked, having evidenced its meaningfulness, you are then in a position to actually put in a request for delegation. And that's obviously subject to the IANA rules and procedures, same as currently. And documentation of endorsement clearly is a part of that. So when we said earlier on there may need to be changes to the current system, one of the things that we'll need to change slightly is in respect to the an IDN ccTLD, the documentation that IANA asks for will be -- will have some additions to it than currently. And, finally, in respect to the delegation, this is very, very important, because we recognize that there may be a quite significant gap between the end of Stage 2 and the delegation of the IDN ccTLD itself and because currently the IDNA -- internationalized domain names, the IDNA protocols, the guidelines are continuously evolving, we're recommending that at the point prior to delegation the technical -- the technical validity of the string is reconfirmed because it is not impossible to consider a circumstance. It would be very unpleasant and not easy to deal with but it is not impossible to consider a circumstance where having been -- having said, yes, this is the string you can have, it's a year or 18 months before the delegation is ready and the protocols have changed. So we're suggesting a technical check at the last minute, effectively. So -- >>BART BOSWINKEL: That's it. >>CHRIS DISSPAIN: No, there are alternatives. So in a nutshell that's where we are. In the back. I have a hand at the back. Hilde? >>HILDE THUNEM: Hello. I'm Hilde Thunem from the Norwegian registry. I will save all the statements about fast track and so for later, but I do have some stupid questions, I'm afraid. >>CHRIS DISSPAIN: I can assure you I have some stupid answers so we'll be fine. [ Laughter ] >>HILDE THUNEM: That's good. Thank you. One of the things I want to be absolutely sure I understood, there will be, of course, possibility for those with many official languages to have several ccTLDs. >>CHRIS DISSPAIN: Yes. >>HILDE THUNEM: But only one per language. >>CHRIS DISSPAIN: Yes. >>HILDE THUNEM: Yes. So that, for example, if English had been an official language in Norway and it hadn't been Latin-based, we could not have had dot Nor, dot Norway, not Kingdom of Norway, we would have to pick one. >>CHRIS DISSPAIN: Correct. >>HILDE THUNEM: For the slow track, which will be incredibly slow, I think there might be discussion of it -- >>CHRIS DISSPAIN: That's exactly right. >>HILDE THUNEM: It is very good for the fast track that it's not. Then I have a point from the fast-track document that was sent out. I'll have to refer to it. It is on page 10. Under "required documentation" in the technical required documentation, I think. >>CHRIS DISSPAIN: Yes. >>HILDE THUNEM: It says that you should submit the language table to be used both for the TLD and for delegations under the TLD. >>CHRIS DISSPAIN: Yes. >>HILDE THUNEM: I just wondered, does this mean you commit a language table so that under an IDN ccTLD you will only be able to make registrations in the language of that TLD? So that, for example, Norway with dot NO could make, if we would have wanted to, Chinese IDNs under dot NO but the Chinese would have -- >>CHRIS DISSPAIN: I understand. >>HILDE THUNEM: -- no Norwegian names. >>CHRIS DISSPAIN: Hang on a second. >>HILDE THUNEM: I just want to understand. >>CARY KARP: I almost hate to introduce this into the discussion. I hold the pen on the ICANN IDN guidelines. And the major change between the first version of that and the second -- the current version of that was abandoning the notion of all policy linkage to language. The DNS operates on a number of very dry, technical parameters that are defined by Unicode, at least the IDN stuff defined by Unicode, and the concept of language does not exist there. There is no way for software to know what language is intended by a string. You can recognize script. And for that reason, the IDN guidelines to which adherence is respected -- is expected, talk about script tables. And you need to consider language when deciding what elements of that language -- other language you want to have available in the IDN. But these tables are -- the published version of this is going to have itself be consistent with the guidelines. The jettison is the notion of table languages because it is not possible to automate the process of that in IDN context. Script, however, is somewhat more accessible. >>CHRIS DISSPAIN: It is my understanding -- my understanding, Cary, would be Arabic is an Arabic script. >>CARY KARP: There is also an Arabic language. >>CHRIS DISSPAIN: Exactly, and that's used by the Arab states. It's used for Urdu, Farsi, et cetera, right. Then there is Arabic language and there is Urdu and there is Farsi. There could be an Arabic script table. There can also be a Farsi language table in the sense that -- or is it a subset of the script? >>CARY KARP: What we're ultimately hoping for -- in fact, in the Arabic context, it is in progress, that the language communities that share a script agree among themselves on what the characters are safe for all; that if one of the language communities would be first out of the gate and say, "This is the way we are going to be using our script" and that would make it impossible for another language community to exercise the same freedom, this process is going to cause trouble rather than solve problems. Again, we're talking about the language communities agreeing on a script table. >>HILDE THUNEM: But I'm sorry to say, you're still confusing me because what I can -- language tables and script tables are one thing. What I'm saying in the document is that when you go for an IDN ccTLD, you have to document the language table to be used both for the TLD string and for registrations made under the TLD. And my question is, do you at that stage have to decide which languages you will allow under that IDN ccTLD and document that language table? And you cannot change your mind later and it will be only the language of the string, unlike for the ASCII ccTLD. Just so I understand what this document says. >> EDMON CHUNG: I can't speak for the whole group. In my understanding, I think you should -- what the concept is that before you provide registrations of a particular language under your string, whether it is IDN or ASCII, but right now we're not enforcing it under ASCII but on an IDN ccTLD, it could be multiple -- different languages or different scripts under -- in the second level. But then you would have to have the language table for those languages that you're providing registrations for. But I don't think it is a case where at the moment of the creation of that IDN TLD we're expecting that you to disclose all of the language because that could change over time. >>HILDE THUNEM: That was more important. I just want to understand what the document says. Obviously Norway is not eligible for the fast track anyway because all our languages are all Latin-based or all our official languages are Latin-based. But I read the document and I was confused. >>CARY KARP: You can put that concern to rest because there is no enforcement mechanism for the thing that you fear. So if the document -- >>HILDE THUNEM: I'm not really fearing anything, I just want to know actually. It is just, basically, I want to know. The last point is when the string is publicized that now Norway is -- if we had been eligible because Chinese had been an official language, we are applying for a Chinese dot NO, is this the point where the community of Norway might come and say, "Look, you forged the signature of our government." >>CHRIS DISSPAIN: Sure, absolutely. >>HILDE THUNEM: And we object because this is not really supported within Norway. >>CHRIS DISSPAIN: But I think -- yes, that's correct. And -- but you're going to -- >>HILDE THUNEM: Nobody would, but... >>CHRIS DISSPAIN: Yes. But what you're saying is that documentation would have been provided, but that documentation turns out not to be -- >>HILDE THUNEM: Yes, exactly. >>CHRIS DISSPAIN: Yes. >>HILDE THUNEM: Because I do approve that there should be documentation for support within the territory -- >>CHRIS DISSPAIN: Absolutely. >>HILDE THUNEM: But then the territory has to have the ability to actually say -- >>CHRIS DISSPAIN: "This is a problem." Yeah. >>HILDE THUNEM: -- "Hang on. This is not really support for" -- >>CHRIS DISSPAIN: Correct. >>HILDE THUNEM: "It's only the people in southern Norway that support this, and us in northern Norway hate it and we have to fight it out inside Norway before we get the name." Okay. Thank you. >>CHRIS DISSPAIN: Thanks, Hilde. I think that's right. Hong is behind you. >>HONG XUE: Thanks, Chris, for the briefing. It's very clear. I was not here on Saturday and it seems tremendous changes you made to the document. Especially the linguistic committee, linguistic expert committee is not here. >>CHRIS DISSPAIN: Good. >>HONG XUE: I think this is good. This is very good. I like this alternative approach. We're always suggesting to simplify the procedure. But I still have a question here. If you could kindly go to the slides on due diligence. Okay. Look at Point 3, documentation. That is on meaningfulness. My question is that: Should an applicant provide documentation or evidence proof on official language? For instance -- >>CHRIS DISSPAIN: Yes. >>HONG XUE: What if the -- oh, that would be very interesting then. >>CHRIS DISSPAIN: No. If you look at the -- if you look at what the definition of what an official language is, it clear -- it says it's one of three things: The lowest level of entry being that it is -- that the relevant public authority has provided a letter to say that it is an administrative language. So as part of the documentation in the actual report, as part of the documentation, evidence of officialness is required. It just doesn't say it on that slide. >>BART BOSWINKEL: It says it in the first one. >>HONG XUE: Sure. Okay. I quite understand. What if the Democratic Republic of Chris applied for -- >>CHRIS DISSPAIN: See now other people are using T it's going to take off. [Laughter] >>HONG XUE: Yes, yes, this is a very important state. This state filed an application. The country name, the full name in Chinese. But it seems that this language is not written in your constitution. It is not noted in your currency back notes, so -- >>CHRIS DISSPAIN: Yes. >>HONG XUE: -- is it possible -- but of course you got the evidence of proof. >>CHRIS DISSPAIN: Correct. >>HONG XUE: Support from the local community. >>CHRIS DISSPAIN: Yes. But also you've got -- yes, but also you've got an official letter from the government or the relevant public authority stating that this language is used in official communications in the territory and for administrative purposes. That's the lowest entry-level. There are higher ones. It's in our constitution, et cetera. But the lowest entry-level is that it is used as a language of administration, and that has to be prove -- now, is it possible that the government would lie? No! Never! [Laughter] >>CHRIS DISSPAIN: But you do have to do -- to provide the evidence, okay? Thanks, Hong. Where was I up to? >>BART BOSWINKEL: Alternative views. >>CHRIS DISSPAIN: Yes. Now, there are some alternate views to a number of the things in the working group report. And it's only fair, in the spirit of transparency and openness, that we go through them. They're in the document as well so you'll be able to read them. They're at no. 5 in the document. The first one is an alternate view -- well, there are actually a couple of alternate views on principle E. Now, prepare E as you -- as I said says, "Noncontentious of the proposed string and the manager within the territory." There is an alternate view which I'm going to -- I'm summarizing but the alternate view is that the contentiousness should be -- contention about the string should be open to the community. So what that would mean is that -- to take some examples, what that would mean is that if the Democratic Republic of Chris decided it wanted dot DRC, it went through the whole process, technically sound, et cetera, et cetera, but evidence that it wasn't contentious in the -- at home in the territory, but at some stage another territory or another registry, a gTLD registry, or some group such as ALAC could actually raise an objection, quote-unquote, and that that obviously then makes the string contentious. Now, what was very clear from our discussions, certainly on the government side of things, is that that won't fly with governments at all, because what they say is it's in our territory, it's our territory, and we understand that it needs to be noncontentious in our territory. We don't have a problem with that. But what we won't accept is that another territory could say, "Sorry, you can't have that." So that -- that's in a nutshell the argument or discussion around the noncontentiousness. Edmon, have I missed anything in round -- in the round from that? I know you would love to -- [Laughter] >>CHRIS DISSPAIN: Okay. There's another alternate view in the document about principle E, and that is that it's inappropriate to be using the ISO-3166-1 list as the pool of eligible candidates, if you like, for an IDN ccTLD because not every territory on that list is a sovereign country. And that, therefore, we should -- >>EDMON CHUNG: [Speaker is off microphone] >>CHRIS DISSPAIN: It's right here. >>EDMON CHUNG: I think it's not about the pool. It's about that the noncontentiousness should be within the region or country and not the pool of -- >>CHRIS DISSPAIN: I'm sorry. You are correct. >>EDMON CHUNG: It's very different. >>CHRIS DISSPAIN: You're actually correct. There are two different points. I was talking to another point. You've put me back on track. Thank you. Sorry, that where the proposed delegate or the territory proposing the IDN ccTLD is not a sovereign country, then they should -- then it becomes contentious if the territory -- if another territory that is in charge of that, or whatever, objects. Now, give you an example. The French Polynesian islands come under -- are governed under French law. Yes. Now, what this amended suggestion would mean is that one of those -- an application from one of those territories for an IDN ccTLD that met all of the requirements would be subject to block objection by France. My response to that has always been, "Well, yes, and it is anyway." Because France has laws in place that would enable it to say to the territory that, "You cannot do this." And that seems to be accepted by most people as a sensible argument. And this process is not about facilitating political -- political resolutions. So we spent a lot of time discussing whether or not it was appropriate, and we finally came to the conclusion -- well, most of us finally came to the conclusion that it wasn't, and that it only be within territory. And you can't suddenly start saying, "Oh, but in respect to this particular territory, a different rule applies." Or "in respect to this particular territory, a different rule applies." Nor can you say a territory is subject to objection from another territory, because that actually goes against the GAC principles in respect to sovereignty, and also the WSIS principles on sovereignty. So we talked it through. We've discussed it. There are a couple of people who are not very happy, but we can't see a way that we would be able to do this. It simply has to be noncontentious within the territory. I'm happy to take questions on this issue, if anybody has any. Okay. Good. We spent a lot of time discussing whether there should be an objection process. Now, this kind of fits into the same category as changing principle E, so that it's not contentious, full-stop not contentious as opposed to noncontentious within the territory. And the same response, basically, is that we'll know you can't have a circumstance where the government of Latvia, if you don't mind me using you, is -- decides on a string and puts in a -- you know, delegates a ccTLD manager and puts in an application for an IDN ccTLD and then that is subject to an objection process. Same thing applies as it does with the noncontentiousness. It's a request that's come from the government, provided it meets the technical criteria, provided it meets the meaningfulness criteria. So, you know, if Latvia puts in an application for dot dog in Cyrillic, then it's not going to meet the meaningfulness criteria. Right? So we discussed, again, that at some length and again, agreed -- well, the majority of us, I think, agreed that there should be no objection process. Now, I need to say "however." Yes, that's right. I need to say, however, that in practice, of course, once a string is published, once we know that the Democratic Republic of Chris is going to have DRC, it's open to anyone, any government, any person, any organization, to write letters and to, you know, stand up at ICANN meetings at open microphones and do whatever they want to do. That's perfectly fine. But an actual mandated objection process won't work because these are sovereign states and it's not going to fly with them. And the final alternate view is to do with agreements. We discussed, again, at some length whether we should include a recommendation or even just sort after acknowledgment in this document about the possibility of there needing to be some written communication, agreement, affirmation between ICANN and the ccTLD manager, and in the end the -- it was pretty clear that -- for many that was not acceptable, that it should not be in the document, it should -- it wasn't a matter within -- for us to be discussing. However, there's an alternate view and that alternate view is that -- and actually, this one is worth reading because it's -- it sums it up really well. "While the group believes that the issue of whether any legal arrangement should be established between ICANN and the ccTLD delegate is outside the scope of the charter, an alternate view holds that in consideration of the overarching technical requirements for the deployment of the IDN, then we should -- this report should encourage ICANN to have in place an expressed understanding with the fast-track IDN ccTLDs to ensure continued compliance with the IDN standards and ICANN IDN guidelines. Furthermore, such expressed understanding should ensure a smooth transition of the fast track to the PDP." Now, that is not -- that's not -- didn't reach consensus on that, but I think it's important to note that clearly compliance with the IDNA protocols and ongoing compliance with the IDNA protocols is going to be required, and it's a matter for the board, the ICANN board and the implementation process to decide what methodology they want to use to enforce that compliance, and if, indeed, they want anything else to be complied with. It's a matter for ICANN to say, "This is what we think you will need to sign, tattoo on your forehead, whatever it is, in order for you to get this delegation." But we didn't feel that it was appropriate for us to be making suggestions in this particular report. And you might be surprised to hear that for some governments, at least, the concept of a written agreement with ICANN is challenging. And whether -- whether any of those governments actually want to have an IDN ccTLD, of course, I don't know. Are there any questions on that? Okay. Are there any questions generally? Because if there aren't, then fantastic and we've finished. A bit early. >>VENI MARKOVSKI: Do you issue passports for the Democratic Republic of Chris. >>CHRIS DISSPAIN: I've got -- I can hear the money. It's -- yeah. [Laughter] >>CHRIS DISSPAIN: And you'll have to have a visa and I'm going to follow the American model, which is that I don't -- I won't understand transit so when you visit them, you're going to have to come in before you can go out again. [Laughter] >>NAOMASA MARUYAMA: May I ask about the "F," the section of the IDN ccTLDs experiment. What's the experimental exactly means here? >>CHRIS DISSPAIN: If you go to the actual clause itself, principle itself, which is here somewhere -- here we are -- it says, "The introduction of IDN ccTLDs is experimental in nature, and therefore should not be considered to be precedent-setting." So what that means that just because an IDN ccTLD is being delegated in the fast track doesn't set a precedent that the policy will necessarily follow the same, okay? It then goes on to say, "The experimental nature of the fast track should also be taken -- should also be taken into consideration when delegating names. However, this should not be interpreted to mean that a delegation under the fast track will be temporary." "Will be temporary." Okay? >>NAOMASA MARUYAMA: So does that mean there's the possibility of the -- what was it -- the denial of that ccTLD in the Future? >>CHRIS DISSPAIN: No. >>NAOMASA MARUYAMA: No. It just means that -- >>CHRIS DISSPAIN: It's possible that there will be a number of fast-track IDN ccTLDs that if they -- if they had gone through the process under the formal policy would not have been granted. >>NAOMASA MARUYAMA: Okay. It will be -- >>CHRIS DISSPAIN: That would be grandfathered. >>NAOMASA MARUYAMA: That will be grandfathered. >>CHRIS DISSPAIN: Yes. >>NAOMASA MARUYAMA: Okay. So another question is about the documentation. There's a lot of documentation, and probably there's a lot of documentation that the territories should submit to the ICANN. >>CHRIS DISSPAIN: Yes. >>NAOMASA MARUYAMA: But which of them should be in English? Probably I think the -- these documents should be in the official language in that territory. That is the reasonable thing, I think, but -- >>CHRIS DISSPAIN: That's a -- >>NAOMASA MARUYAMA: But part of that should be translated in English probably. >>CHRIS DISSPAIN: That's a really good question and it's something for implementation. It's for the staff to work out how -- for the ICANN staff to work out how to deal with that. That's an extremely good question. >>NAOMASA MARUYAMA: But it's not decided yet. >>CHRIS DISSPAIN: Sorry? >>NAOMASA MARUYAMA: Not decided yet about that. >>CHRIS DISSPAIN: Well, what sort of documentation should be in English? >>NAOMASA MARUYAMA: Yes. >>CHRIS DISSPAIN: No. It's an implementation issue. >>NAOMASA MARUYAMA: Okay. Thank you. >>CHRIS DISSPAIN: No problem. Anyone else? Okay. So just to wrap this up, so everyone's clear, GAC is meeting on this tomorrow morning. That's a closed meeting. ccNSO is meeting on this on Wednesday morning. That's an open meeting. Anyone can come. Please do. Although actually the room's not that big, so actually, please don't. [Laughter] >>CHRIS DISSPAIN: You'll all be fed up of listening to me by then anyway. There's -- and for the GNSO people who, of course, are welcome to come to the cc thing, there's also a joint ccNSO/GNSO Council meeting on Wednesday and there's a joint meeting with the ALAC today at lunchtime and I'm sure that we'll be discussing this as well. So thank you all very, very much, indeed, for your attention. Thank you for coming. Thank you for your input. And we'll see you soon. >>BART BOSWINKEL: Chris, just say one more thing please. The document might be up-to-date -- >>CHRIS DISSPAIN: Oh, Bart has just asked me to say one more thing, which is do check the Web site because there may be minor tweaks or updates when we notice we have spelled things wrong or there's a small change here or there, so do keep checking. Thank you.