ICANN|ARCHIVES

Internet Corporation for Assigned Names and Numbers

>>TINA DAM: Welcome, everybody. We're just starting the IDN workshop for this time. The main topic is going to be on policy issues.

There are at least three IDN working groups focused on policy issues. The thought was to bring them together and see if we could have discussions about the overlaying issues that each one of the working groups are looking at. We have on the stage representatives from the GNSO, the ccNSO, and the GAC IDN working groups.

And I'm going to give the word to the three moderators, of which we only have two at this point in time because some of the sessions are running late.

But more people will join us up here.

So quick introductions from the moderators.

>>MING-CHENG LIANG: Hi. Good afternoon, everyone.

This is Ming-Cheng Liang from TWNIC. I'm sitting in for Chris to moderate this ccNSO IDN working group.

Before we start our discussion today, I'll give a brief introduction to our ccNSO IDN working group.

Our working group was just formed in Sao Paulo last December. And we have 11 people currently in our working group. And we divide our working group into three different subjects. One is a second-level domain issues. One is the top-level domain issues. And the other one is the crossover issues.

And today we have a representative from each group to attend this meeting. It's -- we have Jonathan Shea to -- working on these second-level issues. And we have Hiro Hotta. He is the group leader on these top-level issues.

And then we also have Minjung Park. She is working on these crossover issues.

So we hope today that we could have a good discussion.

But before we have a discussion, I've got to let you know that in the ccNSO, currently, we don't have conclusions. So -- so I think -- but in our working group, we dove work together to have some sort of consensus. Hopefully, what we say here will make sense.

But just in the purely information exchange basis maybe. And if something needs to have a consensus, we might need to do that later. Thank you.

>>RAM MOHAN: Thank you, Ming-Cheng.

My name is Ram Mohan. I'm the chair of the GNSO IDN working group. We look forward to a spirited discussion today.

The goal that we're looking to get to today is to discuss at least these three agenda items that you will see posted up on the Web site.

And the general idea is that this is the first time, really, that the GAC -- folks from the GAC, from the GNSO, and the ccNSO are getting together to talk about IDNs. That's clearly because there are many issues that have overlapping interests, some issues that are of intense protective behavior, if you will, from one group will result in intense protective behavior from the other group. So this is a pretty good opportunity to expose these issues and to try to get to -- maybe even get to some solutions.

But, really, the idea here is to try and get an inventory of the types of issues that might exist so that those of us who are part of the community can get to think about how we go about resolving or at least think about methods to resolving these issues.

From the GNSO IDN working group, which had about 40 members in all, we have here on the panel three individuals. We have Professor Tan Tin Wee, we have Werner Staub, and we have Edmon Chung, all of whom have long and strong experience in IDNs at the second level and who have been active participants in the working group itself.

And welcome everybody from here on the panel.

And the idea of today's session is the following: We're not going to do a lot of talking up here. We're hoping that we'll have the panel speak just a little bit and then invite you all to come on and provide your points of view and to really try and make it interactive rather than just have you sit and listen to yet another set of nine people talking.

So that's the general idea. We'll get going here shortly. And welcome, everyone.

I'll hand it off to Pankaj.

>>PANKAJ AGRAWALA: Thank you, ram.

I was just trying to structure my initial presentation. And what I thought is that I would start with some of the questions that have been raised in the ccNSO draft issue paper and try to just respond from the Indian angle so that I can at least create an anecdote so that that can be a basis for looking at, in realtime, what are the issues at hand.

So maybe if I take the first issue. And that is, what should be the -- is there a reason to maintain the two-character string restriction for IDN ccTLD strings?

Now, let me take the instance of India. In the constitution, the Hindi translation of India is bharat, B-H-A-R-A-T.

Now, if I try to use two characters, that would be bhar and ta. Now, the word "bhar" means "burden" in Hindi. It would have a different meaning.

I can't use "bhar" and "ta." That is, B-H-A and T. Because that would mean cooked rice in Hindi. So in situations like this, I have to use "bharat."

Now, the issue that comes before me is that when you useful names in the country, full text, then the 63-character limitation might work against the IDNs.

So we have to be -- we have to keep that in mind.

If we talk in terms of what does the word "represent" mean, and there's a very fortunate question that has been answered. Is there an obligation to make IDN ccTLD string meaningful as a representation of the territory? Or is it sufficient for it to be in the character set and to accept the meaning will be learned?

I would -- my reaction to it would be that although some of the languages in the Indian system are meaningful, yet keeping in mind the fact that the character sets are essentially string, and that we eventually might be -- it would be better if we go for the symbolic representation rather than -- and therefore leave it to society to learn.

On another question, that is, are there any rights to a character set, this is a very interesting dimension, that if someone has a large Punjabi-speaking community, like, let's take the case of U.K., and if they want to use a IDN in the Punjabi script for the very large Punjabi community in the U.K., for an IDN equivalent of dot U.K., why should they seek the government of India's position? And I don't see any reason why Punjabi should be seen as a property of the government of India.

>>RAM MOHAN: Just very quickly, I think you bring up something interesting. You're saying the pun -- the IDN equivalent of dot U.K. But perhaps it won't be dot U.K., perhaps it'll be dot United Kingdom, which might be different than just dot U.K; right?

>>PANKAJ AGRAWALA: The words "United Kingdom" written in Gurmukhi, and that would mean "United Kingdom." So we have -- it's not just the United Kingdom that is -- it is the use of the Punjabi language or the Gurmukhi script.

>>RAM MOHAN: I understand. But I guess my question is, would it be U.K., because it's possible that U.K. actually doesn't mean anything, it's just a couple of letters put together, while U.K. does mean something, it's an abbreviation, if you will, in the -- as used in English.

So in this case, would -- you know, would you be looking at it as just U.K., the characters in that language that represent U and K, or would you actually think that it should be the full word expanded out?

>>PANKAJ AGRAWALA: This would be a decision of the community. It's something which they have to associate with it and decide whether they would like the full expanded United Kingdom or the learned U.K. being the approximate to the domain name.

So the idea is that these are some of the issues which I personally feel that we -- there will be some consensus generation from the community.

If I could just go ahead and just use one more example, and then I'll open the floor to discussion. That is that there is a question that is it possible that two or more versions of a character set with only minor differences could be accepted under the IDNA protocol?

Now, I take the meaning of "version" to mean -- in India, we have nine scripts -- one script and nine languages. So if I use the Devanagari script for Marathi, and then the Devanagari script for Hindi, that is two versions on the IDNs, for Marathi and for Hindi.

If that is the case, if that is what the question is relating to, then what I have to say is that there are issues and concerns here, and that is, technologically, we might have to either use language tags or we will have to make a massive variant table, which will be identifying the variants so that the potential spoofing and phishing candidate characters could be put in a variant table. And then you need to have a variant policy in place, a tariff policy.

So all those things would be required to be in place in case there is -- there are versions of a particular language.

I would like to close at this point in time.

>>RAM MOHAN: Thanks, Pankaj.

Perhaps we should just walk through the panel here, see if you have thoughts on this, on this area. Ming-Cheng, you had something?

>>MING-CHENG LIANG: Yeah, since I think Pankaj has just mentioned this issue presented by ccNSO, and, actually, we have gone through this in the last couple of days with GAC, and also with our members. And at the present time, this is just recommendation, and, actually, we just go through it, and it's not -- suppose we are going to provide any conclusion or anything where we -- just the way it is. We just want to present our ideas, hopefully that everyone listens to that, they can give us some comments.

And before we go any further in this discussion, I think that if it is possible, I would like to -- the audience and also the panelists to think about one thing, is that -- of course, I think IDN issue is very complicated. There's no doubt about that. And if we try to solve everything just right at the beginning, it doesn't make sense.

And so if -- can we think about one thing, that if we put it right initially, what can it be? And then if it's possible that it needs something that can be acceptable to IANA, that the database can handle, and something that could fit partially the needs of the local people or something along these lines, could we think about something and concentrate on the issue along this line first.

And I think that we have list of these general -- general issues which can be discussed further. I think that would be great.

But I think that if our discussion could concentrate on something like that, I think it would be -- make more sense.

Thank you.

>>RAM MOHAN: Thanks, Ming-Cheng.

So, I guess, the first topic that we're looking to chat about is what's right there on the screen, should an IDN string be meaningful?

And for the sake of this discussion, I guess we're looking -- I think we should look at not just ccTLD, but, in general, an IDN string.

I'm going to kick it off before I head it off to the panel, I'm going to kick it off with just a question, which is, why is this an IDN issue? Why isn't this just about should a string be meaningful? What does IDN really have to do with it?

>>WERNER STAUB: I would like to add to that question that we asked is should an IDN ccTLD string be meaningful.

I mean, an IDN TLD could be meaningful or not. But specifically the question that was asked was whether a ccTLD string would be meaningful, given the fact that actually the ccTLDs, as such, usually the ones we know, are pretty meaningless, unless we basically have the standard, the ISO standard, that gives them meaning.

And in the case of some people, this meaning is sufficiently easy to understand in a couple of lucky countries such as mine, which use CH. We happen to know that this is the Latin -- in Latin, actually -- the name of our country, because we have four languages. And, you know, the best way to agree was just to put it in Latin so that, you know, it doesn't offend anyone.

So -- But in -- we used it in other cases, it's pretty easy to understand. Sometimes China was confused with Switzerland, because many people were confused from the outside. Swiss happened to know it.

But, still, why should it be meaningful? I think that depends on the users. The users may need a meaningful string or may not need a meaningful string. And the meaningful string could actually be harmful in some case with revised meanings that are not intended, that one would rather not have in the word.

The only people who would possibly be able to know what is the right kind of string is the local community, as Pankaj very importantly pointed out. This is not a context where we can impose this from the outside.

In this context, we should not forget that the existing ISO list was never intended originally to be something visible to the users. This was a code, you know, for all kinds of lists, supposed to be hidden from the user. And it just proved sufficiently graceful for many of us, but not -- others not, such as not for many, but typically the westerners, proved to be just okay to use that and actually have a TLD that shows on that basis.

But, of course, for Chinese, for Arabic, it is not at all practical to have that as the official TLD.

So the fact that we use this code as a code is a, so to speak, western phenomenon, and happens to be okay in that context. And it is half meaningful in our context. It's just about okay. But in other contexts, only the local community can figure out.

>>RAM MOHAN: Other comments?

>>MANAL ISMAIL: I just want to comment on -- in Arabic, we have the same issues almost as the Indian case, because the two-letter abbreviation won't work for the Arabic language, as we have short words up to two letters. So whenever we abbreviate, we will end up with a word with another meaning. And we have very, very rare cases where we have abbreviations. But then we have to put a dot between the letters. Otherwise, the letters join, and you end up with a third meaning.

So, basically, this will not work for the Arabic.

Whether it should be meaningful or not, probably, from my very personal opinion, I think it should be meaningful for people to recall it. Otherwise, -- because otherwise, they won't recall it, and we don't have this option in Arabic, because, we are talking about abbreviations, again, which is not working in Arabic.

>>RAM MOHAN: Thank you.

>>JONATHAN SHEA: Jonathan, from dot HK.

My understanding is that ISO 3166 is workable solution and a neat solution to enable, you know, the generic space and the country code space to operate concurrently, without too much overlap, without, actually, any overlap. But, essentially, is just a workable solution.

But that doesn't mean that is a preferred solution.

I believe, if possible, if the TLD can convey the meaning, whether it's generic or whether it's a geographic-based, I think it's actually a more preferred solution by the community. Now that we have the opportunity to do it right, well, maybe we should spend more time to get it right.

But, again, I emphasize that 3166, ISO 3166 is a workable solution, is working occur, but may not be, actually, the most preferred by the communities.

>>HIRO HOTTA: Thanks. This is Hiro, from dot JP.

Actually, the -- the meaning of the string, IDN string, depends on the local community who uses the language of a script, of course.

But the -- I think we need to consider that the big motivation of IDN introduction is because IDN could be more meaningful than only the consecutive ASCII letters for the community who use the language or script.

Thanks.

>>PANKAJ AGRAWALA: Just to support HIRO-San, this is -- sorry?

>>MING-CHENG LIANG: You can read what our --

>>PANKAJ AGRAWALA: That's right.

I was saying that the linguistic iconsi, as I've used this word in my presentation, that the community has to recognize that IDN ccTLD. So there is a linguistic iconsi. And, of course, there has to be a cultural attachment to that same thing.

So, therefore, it has to be acceptable to the user community, and it has to be recognizable. These are the two basic aspects to -- and therefore it has to be meaningful.

>>MANAL ISMAIL: I think we more or less agree that it should be meaningful. Maybe the question is meaningful to who? Because the example we used here -- for example, dot Australia, which is dot AU, and it is meaningful to the outside world but maybe the local community prefer it and other abbreviation like dot AUS or OZ.

>>TAN TIN WEE: That's why we agree because for a long time we have been advocating we have to go back to the language community to ask them what does this string mean to you.

So in that sense it has to be meaningful to the community that it has to help and to assist and to facilitate and reduce the digital divide for which the IDN was the original -- that was the original reason why we invented it; right?

>>MING-CHENG LIANG: I think I would urge people to take a look at the view graph we put together. And I think that as long as the technical part can handle, it might be recommended that we should just take whatever is meaningful for the people, maybe.

>>RAM MOHAN: There is a comment online that I'm going to ask Olof to read. And before we go there, I think I had one further thought.

We're talking about it should be meaningful, that the ccTLD string should be meaningful. But let's take what Pankaj is saying, the case of a minority community in the United Kingdom. Should they get the chance to say what is meaningful for them, United Kingdom in the Gurmukhi script, or is it somebody who is not from that language community inside of the United Kingdom saying, this is the United Kingdom. This is what it should be.

Or should it be somebody back in India who is helping decide what the correct meaningful name is? Who gets to participate and who gets to make the call?

>>OLOF NORDLING: Well, just briefly, a comment from Shahram Soboutipour and actually relating to a comment made by Manal Ismail just a while ago, saying: We have the same problem in Persian, too, like Arabic and Indian. There is a connection string between letters, so abbreviations must be separated by space or dot to keep their shape. End of comment.

>>RAM MOHAN: Other thoughts?

>>WERNER STAUB: Just to be sure I understand what you mean, you are talking about the United Kingdom basically in Britain, basically, that there should be a choice as to the submitting community, that there could be an additional ccTLD for the United Kingdom because there is a certain population of a given origin.

So if we apply this to Switzerland, we can say there is an immigrant community, for instance Tamils, and there would be a certain number of Tamils in Switzerland, so shouldn't it be possible to actually express Switzerland in Tamil as a ccTLD.

In my view, this is certainly something worth considering, but not now. It is something worth considering as a step to. And then we would be able to have additional intelligence.

But for the time being, we should look at the obvious urgent things.

>>RAM MOHAN: Thank you.

Other comments from the panel before we go to the audience?

>>TAN TIN WEE: I find it interesting we should be focusing on theoretical situations when we have on hand many existing solutions and examples of already-thought-out solutions which many language groups have already worked out.

For example, the CDC, Chinese -- CDNC, Chinese domain name consortium has already sat around the table and discussed this and come up with solutions. Where it overlaps and conflicts with somebody with the same meaning or different meaning in the characters that they have chosen, they have opted to talk and communicate and consult in dialogue with the other communities that maybe impacted by their choice.

And in that, you can see that in the past, I think what -- five, sick years ago, CDNC have worked together with Japanese people and Korean people to figure out how to avoid conflict in terms of the meaning of their ccTLDs or any gTLDs.

So that is a clear-cut example of real-life situation where people have sat together and solved the problem. Maybe the CDNC people and the Japanese and the Koreans would like to say something about this.

At the same time we have seen the 22 Arabic nations have also sat around in the Arab league, and maybe those seated in the audience and the panel would like to comment on that because they have also sat around and figured out what they wanted for the ccTLDs.

So these are real live situations where people have decided what they wanted, and they have consulted with those people.

Those other language communities where they might have negative impact by their choice. And then sat down to figure out how they could iron out their differences.

So I think we should focus more on those places where there have been some progress rather than invent some theoretical situation to throw us off guard.

Look at those things that we have already achieved something and move up from there.

>>MING-CHENG LIANG: Yeah, I just want to comment that I think CDNC is a good example of cooperation.

But in the test doc as I just mentioned before, I think maybe let's concentrate more on the initial phase. So this theoretical part, possibly we could put it in a later phase.

So try to see if we can get ahead somehow.

Thank you.

>>RAM MOHAN: Martin?

>>MARTIN BOYLE: Thank you. My apologies for being so very, very late, but I was held up in an earlier meeting.

And, therefore, not having heard what anybody has said up to now, please forgive me if either I go off the subject or repeat, or perhaps even contradict without explaining why I'm contradicting something that somebody has already said.

But coming into the end of that bit of discussion, I think one of the points that is concerning me is the risk of ending up with confusion if you don't end up by ensuring completeness.

And I think the one thing that the ISO 3166 code list taught us was that it gave a good basis and a readily agreed basis for all subsequent actions.

And the second thing it taught us was it was independent, and so nobody could come back to ICANN later and say, "Why did you make that really dumb decision?" And bearing in mind that everybody loves going to ICANN to say "why did you really make that really dumb decision," that's probably quite a good thing to have.

So I would actually quite encourage the development of some lists that were reasonably well standardized and accepted as being the basis for any introduction of codes.

New, I recognize that always risk getting to be frustrating for those people who are ready to go, but I think there are perhaps a couple of reasons why I would be there.

The first is that if you have a list of codes that is incomplete and that is only just directed onto those countries that have agreed and taken part in those codes, is that you leave an opportunity, and a very real opportunity, for people to come along and put forward cases for codes that could subsequently be passed off to others as being a code for a country that hasn't got an agreed code in the list.

So, in fact, going back to the ISO 3166 list, one of the big advantages of having that code is that nobody can come along and pretend that GE should stand for Germany because it is already written down that DE stands for Germany.

So I think that's quite important.

I think the second reason why one would consider as being quite important to have the list is that just because your country does not use a specific language does not necessarily mean that you haven't got minority and substantial minority populations in that country who would benefit, particularly in things like the delivery of government services.

But secondly, there are a lot of countries that trade extensively with countries that have IDNs that the -- I am going to get very tied up on this -- that the exporting country does not use. And, therefore, actually having a possibility where the trade is important for those companies in that country that you are exporting to be able to register an IDN for the country area that they are going to is, in fact, I think, quite important, and is something, if it's not allowed, that you will find that it could end up being a trade barrier. And that again is something that, from a governmental perspective, I would be quite concerned about.

I realize I've obviously gone on much longer than anybody wanted at this stage because people are obviously ready to ask questions. But I think there's the sort of underlying thing that I would like to see is to encourage the relevant standards making bodies with expertise in this area to look how they can develop a methodology to draw on the very experiences that are already being cited, and to get those into a framework that could then be usable and rapidly usable with full consensus by the whole community.

So thank you very much.

>>WERNER STAUB: I would like to put into perspective, into this perspective, the fact that we actually have more than one process. We have a ccTLD process that we're talking about, and we have a gTLD process.

And one of the consensus items of the gTLD process, old already by now, is the fact that we want the central initiative to come from the community. The community will propose what it deems to be important for itself, those suppose it's very important, regional communities can go and get ccTLDs such as dot Asia. That's one of the examples. Basically, there's a perceived need to do something. Dot Asia is one of those solutions and addresses actually that the need that emerges is actually not something that we can determine from the top but actually the initiatives people feel the need will actually come forward.

With respect to the ccTLD process, we probably have to be careful about the use of the word "code." It is a mere coincidence that the ccTLDs right now are codes. This is mere coincidence.

I don't think we're looking for codes. We're looking for socially compatible identifiers from the perspective of the local native community in that country. And we have a couple of urgent cases where the current system badly serves those communities. And that's the ones that I think we have to address with utmost urgency and not wait upon, you know, some experts that we don't have identified yet and have no idea how effective they possibly can be and if you will ever have agreement to find a uniform and all-encompassing standard.

>>RAM MOHAN: Thank you. Any questions from the audience?

Come on up. We're going to keep polling, coming back until it's time to go to the next topic.

Chuck.

>>CHUCK GOMES: Thanks, RAM. I am Chuck Gomes, I am chair of the GNSO reserved names working group, and I was very interested in your discussion in terms of two-character names.

And in fact, you have said some things that are very helpful for our reserved names working group.

What I would like to know is what the most effective way for the reserved names working group to get some definitive answers with regard to single-character and two-character names at both the top and second level for IDN names in scripts.

Now, you obviously, several of you addressed some issues there, and I am not asking for additional discussion on this right now because it would take too long. We'd probably monopolize the rest of the time and I don't want to do that.

But it's likely that the reserved names working group will reconvene in a couple weeks, and those are issues that we would like to get a firm handle on.

So if I could get some points of contact that the group could interact with in this regard, I would very much appreciate it.

>>RAM MOHAN: Thank you, Chuck.

Before you walk away, I just want to make sure I understood your question correctly.

What you're saying is today in non-IDN TLDs, the quote-unquote ASCII TLDs that are there, there is a contractual requirement that one-character and two-character names be blocked, reserved.

>>CHUCK GOMES: At the second level. That's correct.

>>RAM MOHAN: At the second level.

>>CHUCK GOMES: Right.

>>RAM MOHAN: And what you're asking is, when it comes to an IDN TLD or IDNs at the second level, what --

>>CHUCK GOMES: And the first, and the top.

>>RAM MOHAN: So IDNs at the top level or IDNs at the second level --

>>CHUCK GOMES: At the second level. Does it make sense or would it be bad to impose a reservation requirement for two-character or one character IDN names.

>>RAM MOHAN: And what I want to ask is something broader, which is are there an actual number of characters that will fulfill, or is one or two characters sufficient?

>>CHUCK GOMES: I don't know the answer to that, and maybe the group, not right now, maybe they can help me with that as well.

Obviously the reason why we are looking at one and two character is because of ASCII. And just to set the stage, and maybe I should have done this first, you know, right now we are, at least at the outset, going to recommend that one- and two-character ASCII names be reserved at the top level; okay?

Some more study may be done on that and that could change.

At the second level, there may be some changes in the existing requirements for ASCII one- and two-character names, but we also need to answer the question what about IDN one- and two-character names. And like you said, RAM, if whether or not maybe should we be concerned about three character? I don't know the answer to that.

And again, I'm not asking for answers to that now because I think it's too involved. But I would very much, in the next week or so, like to have points of contact of people who can help our working group in getting a handle on those situations.

Now, Edmon is on the working group so he certainly can help us there, but any additional help we could get would be very much appreciated.

Is that okay?

>>RAM MOHAN: Thank you.

>>MIKE RODENBAUGH: Could I just follow-on with that? Thanks.

I'm actually the chair of the subgroup of the working group that Chuck was talking about dealing with one- and two-character names.

>>RAM MOHAN: Mike Rodenbaugh.

>>MIKE RODENBAUGH: Yes, sorry. Also on the GNSO council.

I ask also further to those comments from Chuck, personally I believe names should be released at the first and second level, one- and two-character names if they are not existing country codes and they are not confusingly similar to existing country codes. Although Werner put the thought into my head that how does something get more confusingly similar than dot CH and dot CN which have existed just fine for a long time with no confusion as far as I can tell.

I'd ask you also to consider that the current practice today -- I don't believe this is a rule, it's not in an RFC anywhere that our working group has been able to identify, whether this practice of releasing two-letter top-level domains only as country code TLDs really makes sense, both in ASCII, or if that practice should apply to IDNs as well. It seems certainly not. It seems obvious to may that in Chinese or in Korea you could probably identify those countries in their own language in one character. I could be wrong, definitely, not speaking those languages.

So I think we definitely need to address that question as well.

Thanks.

>>RAM MOHAN: Thank you.

>>MILTON MUELLER: Milton Mueller, Syracuse University. I wanted to take issue with this recommendation about the length of IDN ccTLDs, and also to quibble a bit with Werner about the concept of codes. Because as a communication professor it seems very odd to me for you to be saying these are not codes.

A symbol, a Chinese character or a letter in Roman alphabet, has no real relationship to what it stands for. I mean, this is just the way semantics works; right?

The character is both arbitrary and its correspondence to anything in the real world is always learned. That is true of all forms of symbolic communication.

One reason I like the idea of considering these to be codes and considering them to have a very simple rule, one or two characters, is one that I like. It sort of relates to the reasons that Martin was talking about. It has to do with clearly demarcating the background degrees between these reserved names and what everybody else can do. Which also sometimes turns into a boundary between a monopolized market and an open market.

So if you are going to say, here countries, we are going to come up with some translations or coding of your country symbols into one or two letters at the top, you get those as an extension of your current monopoly, and now everybody else knows exactly what they can't do and what they can do, I think that's a good thing.

But if you start talking about meaning in more general terms, you will always have a debate about what is confusingly similar and what is not.

Now, I am concerned -- and the languages that I know I think a one- or two-character limitation is not a big deal but I'm sure there are languages I don't know anything about where it is a problem. But even in those cases, you can learn. One of the most popular telephone brands now in Europe is 3. What does that mean? 3.

Well, you learn that it means a 3G mobile telephone provider, Hutchison Communication. It's learned. The symbol becomes the reality for people once they learn it and that's certainly what happened with ISO 3166 and I think it could happen with IDNs.

But again, the point of that is to have the simplest possible rule separating the two worlds.

>>RAM MOHAN: Thank you.

>>AVRI DORIA: Avri Doria, and I was a member of -- or am a member of some of the GNSO working groups.

I guess I have a question that's similar but slightly reversed. And admittedly, the reason why we have the two character is an artifact of a list. The reason we talk about reserving two characters is a historical artifact.

But if we don't find some sort of simple rule like that, then how would you suggest one does allocate a set of ccTLDs in IDN?

What would be a mechanism that would work?

And because sort of accepting, okay, it may be reasonable it look at something else, but then it's very confusing to me, how do you come up with that something else? How do you designate it? How do you reserve it?

And so that would become my question as sort of a corollary of the don't restrict it. Okay, but then how?

>>KIRA LITVINIA: My name is Kira Litvinia, and I'm representing Russian registry.

And I'm one of those who's ready to go. And -- but, I mean, we do know what this string should be and everything. And I mean, we -- this may also help us to avoid several difficulties that we may have now if we try to implement IDNs under dot RU in (inaudible).

But I'm supportive of what Martin said about the lists that we should have. But I think that we should have the straight way of which list we should have.

And for us, it's -- well, for me, for example, I can -- if I understood this correctly from Elizabeth Porteneuve yesterday, for example, if ICANN was applying ISO, like, two years ago, probably by now there would be a list of IDN strings.

So we just need maybe to choose the way, which list we are going to use and maybe to apply to ISO or any other organization.

But, I mean, we should just proceed with this. Because we are ready to go. And, believe me, we have this solution, like, two, three years ago. And we're not proceeding any -- not in step; right?

And the community is waiting for us, including governmental structures, including users, end users' community, and registrars.

>>OLOF NORDLING: And we've got another comment from the public participation, chat room on this from Shahram Soboutipour. Apologies for my Persian.

I think the issue one and two characters in IDN TLDs is more meaningful for -- in ASCII names -- now what happened with this? I lost it.

So, in some IDNs, IDN environments, I think, like Persian, and as I may know, in Arabic, this question is actually meaningless. So I think this must be decided in a localized area of each language.

And as I said in my previous comment, language abbreviations are not common in Persian, and one- to two-character words are mostly abbreviations.

I think I gave him justice in that. But end of comment. Thank you.

>>VINT CERF: I think, actually, that was one of the points I wanted to make, and to say a terrible Americanism, especially given that the only languages that I have any slight command over would be English, French, and German, and the latter two not very well. But those are all expressible in ASCII character sets, not counting accents.

So the problem is that if you think only in terms of languages expressible in Roman characters and languages expressible in alphabetic, phonetic alphabets, the notion of abbreviation is quite that you recall. But I've just learned from this discussion that in other languages, the notion of abbreviation is not so natural.

That means that anyone who had the hope of saying that, well, if length of string is of any use at all in IDNs to segregate, for example, the internationalized ccTLDs from everything else, that hope sounds like it may have been dashed by this discussion.

So that's a bit of a letdown for anyone looking for simple rules.

So it sounds to me as if we are going to be faced not only with choosing strings on the basis of character set, but also on the basis of language, which is another disappointment, since I was hoping we could ignore any language indicators anywhere.

I wanted to suggest to you that the repeated use of the term "local community" may create models in our heads which are not really accurate, because there are going to be speakers of language and users of script who are not in a particular local community. If we pick Chinese, we have a very large diaspora of users of those scripts and speakers of those languages.

So we should remember that this stuff needs to work globally and not just in a local region. At least I submit that's an important characteristic of the Internet that we wish to preserve.

The last thing I wanted to mention is to reinforce Martin Boyle's point. Given that we can't rely on simple things like any three-symbol string is reserved for internationalized ccTLDs, and everything else is open, if we cannot make such simple rules, then if we fail to protect all of the internationalized ccTLD choices up-front, we may have a collision if we try to allow gTLD creation of IDNs at the same time that we're also trying to create ccTLD IDNs.

Everyone who is ready to go will hate to hear me say that, because they will say, "Well, I can't wait for the next ten years until country X decides what it's going to do for its internationalized ccTLD symbols."

But I do believe Martin has a point, that we need to find a way to protect the ccTLD community which has not yet decided so that an accidental gTLD selection doesn't actually create a conflict.

I don't know how to solve that problem. But I suggest to you that it is a problem and that we need to look for ways to protect the ccTLD community.

>>GEORGE SADOWSKY: I'm George Sadowsky, and I speak with some trepidation on this subject, because I am not an expert, and I have not followed closely what you have all been doing.

I am, however, relatively expert in developing countries, having worked in some of them and having understood some of their aspirations in the Internet.

I'd like to very strongly support Tan Tin Wee's suggestion and the suggestion of the woman from Russia that being ready to go should allow you to go.

The -- this is a very nice discussion. It's a comfortable discussion.

What I sense is a lack of urgency in it. And this discussion has been going on for years. You know that as well as I do.

But there doesn't seem to be a way to come to closure in such a way that there's a framework for allowing the people who are ready to proceed and the people who aren't ready to work on their own particular problems, and when they're solved, join the group.

And I think that unless we want to see more alienation of certain language communities from the Internet and the possibility of more alternate roots, the possibility of more divergent and perhaps incompatible roots, it is urgent to reach a solution that will allow those communities that are ready to proceed to proceed, without waiting for a solution to the more general problem of how we should let language community A living in country B to express itself in some string which has not yet been defined and which may take years to define.

So I guess it's -- my intervention here is a plea. Let's get started. Let's find a way to allow those who are ready to start and do it urgently and then worry about the other problems. We're not going to solve this problem or this whole set of problems simultaneously. That will fail.

>>CARY KARP: Cary Karp. I need to preface this with two remarks. The one is that I also regard the enfranchisement of marginalized people as the purpose of this exercise. Everything else is just detail.

And I'm also conflicted. I represent a national government, and I also operate a gTLD.

And what I'm about to say I say with the same kind of, "gee, I wish this didn't need to be said," that Vint I think was referring to when language had to be brought into this. And that is that ccTLD designates a very specific creature that I don't think we're actually talking about in this. These are TLDs that derive their labels from the ISO 3166 two-character column abbreviations, which are enormously appropriate in a very specific context. And we're now talking about leaving that context. And this notion of somehow extending, extrapolating from the familiar into the utterly unfamiliar I think is one of the major impediments. That's one of the things that's making it necessary for George to come up and say what George is saying.

And the thing that I really don't want to call attention to, but I suppose I've gotten halfway there already, is that, in fact, our categories of TLDs need expansion. I mean, Edmon is nodding energetically.

Asia designates some supranational but very much culturally and linguistically bonded community that does map into a TLD. We see it already. We see specific language TLDs, transborder with dot cat.

So we're looking at gTLDs in a sense where there's a community identity that is utterly divorced from language attributes. We're looking at country, national TLDs, where both 3166 abbreviation and other sovereign attributes, linguistic included, are extremely important. And then there's this third elusive thing which I have a sneaking suspicion that nobody really wants to get into but we're ultimately going to end up focusing almost all of our attention on.

>>YOAV KEREN: Hi. I just wanted to say that, in continuation to what Vint mentioned regarding the local communities, I totally agree with that view. And I would like to offer that it will start talking about language communities, which will probably be something that will be more a better representation of what we're looking at. And if we will try to get -- we were talking about it a lot in the IDN working group of the GNSO. And if you would like to get some input from the language community, so the language community should take into consideration people that speak that language from different geographical areas. So take the case of China. Not only from Chinese -- Chinese, sorry, not only from China, probably from other countries or people that are in the diaspora and speaking the language. That's one thing.

And the other thing that I would like to say more specific, it was brought here, whether the length is okay in other languages. In the case of my language, in Hebrew, I can tell you that I'm trying for a long time to find a good -- good two-letter -- something that will represent Israel in two letters in Hebrew, in the Hebrew script, and I cannot come with anything that really makes sense. The shortest thing would be five letters.

So it seems like it's a problem in almost any other language, and that we should really take into consideration.

And the last thing I want to say is, I'm getting a feeling that this thing is not going to be solved so soon. And this is not simple.

And I would like -- since I was involved in the IDN working group of the GNSO, I would really be hoping that the way that ICANN will go forward would be that gTLDs, IDN gTLDs, can go forward, even though we don't solve the ccTLD problems.

And my opinion, my personal -- this is totally my personal opinion -- is that in some cases, gTLD, IDN gTLDs will be sufficient for the language communities. And I'm speaking about, again, language communities. It may be enough to have some gTLDs in a language, and maybe later on, the -- I don't know, the ccTLDs that are relevant with the countries that are speaking that language will not really care to have another IDN TLD which represents the country that speaks that language.

So I would really like to see ICANN after, I think, eight or nine years that this thing has been going on to move forward with gTLDs, even though we don't solve the ccTLD problems. Thank you.

>> HONG XUE: I want to follow what was said by the chair of NomCom. I really agree with that. We now have two options. One is generalized option, and another is localized option. Of course, we prefer the first one. That's the nature of the Internet, to be connected and solute all the problems through one solution. That is perfect.

The problem here is that there's no such available solution right now for some scripts or characters that are so mature. There's many solutions that are being sought out. As my learned friend Cheng-Ming mentioned, in the Chinese language community, there's a quite mature technical solution for the problems.

But for the other scripts or characters, there's no such solution right now.

So why don't we think about the sense of localized solution, whatever imperfect they are.

I remember many years ago a very learned Internet father, Vinton Cerf, mentioned that those localized initiative, whatever imperfect, should be encouraged in this IDN development process.

Another point I want to present is about the two perspectives. One perspective is an expert's perspective. We learn a lot from the IDN experts -- I'm sorry if I misquote you, your presentation.

Of course, we rely on the experts' expertise in the policy-making and technical solution. And, of course, we are heavily relying on them in the future implementation. Totally agree with that.

However, not all the IDN issues can be resolved through those purely theoretical, hypothetical study.

We have to go to the ordinary people to do some empirical study.

And where can we learn from the ordinary people? Where is the channel? And there is a channel that's right now very available to the ICANN community that is a large community, especially there are going to be four regional Internet user organizations.

ICANN provided precious resources to make these organizations to be organized. And they are based in certain geographical regions. And they are the organization of the local people.

So why don't we use that channel to learn from the people what they really want, especially those problems that you cannot imagine in this room, such as why would they -- those minority community would have a minority scripts IDN. Along with the majority script set, yes. That is the issue you have to talk with the people in that minority group.

And, for example, we have a regional group in our large community that is a Maori Internet user organization based in New Zealand. So this is just an example. If you say, "Well, we don't know the people from At-Large, especially from RALO," I give you an example.

The newly elected secretariat for the Asia-Pacific RALO is right there, Mr. Edmon Chung. I'm sure he can provide you precious information on this. Thank you.

>> YOUNG EUM LEE: Yes, Young Eum Lee from KNR. I'm also a ccNSO Council member.

I would first like to make a distinction between a regular gTLD and an IDN gTLD.

The reason being that the regular gTLD, the ASCII gTLD, is intended to be used by, I guess, almost anyone in the world, whereas an IDN gTLD is intended to be used mainly by the language community or script-sharing community.

And so it is a very different monster. It is not the same as an ASCII gTLD. And that's something I would like to make very clear.

Secondly, in terms of the importance of localization in terms of IDNs, I think many people in this room, especially from non-ASCII-speaking communities, completely agree.

But I do want to emphasize that there is a difference between technical globality, globalness, and -- I don't know -- language or localized language, which is that the Internet has to be interoperable globally. I think that's why we're all here.

But just because it has to be globally interoperable, it doesn't mean that the script or the character of any given language needs to be globally accepted. If that specific language-speaking community can agree, as has been said numerous times today, then it is that -- that community's I don't want to say right, and I don't think that's right, either.

But it -- we should respect the opinions and the everyday uses of that language community which is intended to use that IDN TLD.

>>VINT CERF: Okay. Let me suggest that it might be helpful to start with one or two principles.

One of the principles which I think is pretty important to preserve is that a domain name, when resolved, resolves the same way throughout the Internet, no matter where you happen to be.

If we go away from that, then someone who might be using a particular IDN domain name and wants to use it someplace other than home might find that it doesn't work anymore.

And so I think resolution really is important on a global scale. That's point number one.

The second point is that a different way of thinking about dealing with the introduction of IDNs is to not make a distinction between gTLDs that use IDNs and ccTLDs that use IDNs. And so for a moment, I'd like to ask you to suspend your disbelief at this notion. Let's imagine for a moment that we only have TLDs and that we don't make any distinction between them. Let's imagine that someone wants to have a new TLD. And let's imagine that it doesn't matter whether the motivation for that new TLD is that it's intended for use as a country code or it's intended for use as a more generic top-level domain. Set aside that distinction for a moment and imagine what process we might want to introduce that would allow the proposal to be dealt with.

A proposal for a particular string, whether it is an IDN or not, may create or may result in opposition, whether it's represented in ASCII or represented in some character set doesn't matter. The proposal in this combined context could generate some opposition. In fact, I'm sure we have some examples that you can think of that have had that characteristic.

So we might ask ourselves, how could we assure that a proposal for a new TLD, regardless of whether it's intended for ccTLD purposes or not, regardless of whether it is represented in ASCII or represented in some other character set, how could we deal with a disagreement or opposition?

If we had a resolution process that allowed an opposition to a particular proposal to be resolved, if we had one, then, Martin, it might deal with the question of protecting the ccTLD community from accidental or deliberate depredations

by the gTLD community, because they would be the same community from the standpoint of resolving opposition to a particular proposal.

So I almost suggest that if we back away from the distinctions that we've been making and say, let's figure out if there is a process that will allow any proposal to be exposed to opposition and find a way to resolve it, then we could actually proceed right away, because any of the proposed ICC TLDs could be proposed in this combined context. And if there were issues from any of the ccTLD or gTLD community, those issues would have to be raised and resolved.

Now, I've invented a nonexistent process. I haven't said anything about how it would work. And I don't exactly know how it would work. But it could be that that common dispute resolution process might be sufficient to allow us to move ahead on all fronts as long as parties who are concerned about any particular proposal have a way to raise those issues and have them resolved.

>>HOWARD LI: Howard Li from dot CN.

First I would like to make a comment first.

I made a comment back in Vancouver meeting, and unfortunately, the IDN, it's not international, actually.

I don't know how they come up with the idea of Internationalized Domain Names. Actually it, probably should be called the multilingual domain name, or MLDN or whatever.

It came up to address the local needs somehow; right? It somehow should be called internationalized probably from the user group that's not using other scripts.

And then the second, I would like to make my point, suppose I stand at the street side and try to cross the street. Do I worry about that when I don't say the street, I will get hit by a car or by a motorcycle? Or it's just a stone fall from the sky and hit on May head? Or should I just think how should I go across the street?

I think the positive way to go across the street is the way that we should pursue.

And I think from the discussion from the panel and the floor and today, I have seen the tendency that we are trying to move that way. We are trying to go across the street.

I know there is so many people out there worry about the stability to preserve the stability and the safety of the Internet. And I know that's important.

But if we don't do anything, then it's even more dangerous; right? I mean, when Mr. Cerf invented that TCP/IP, I suppose he didn't mean to resolve all the problems; right?

[ Laughter ]

>>HOWARD LI: Yeah.

The problems come up.

>>VINT CERF: I just wanted to make it work.

>>HOWARD LI: That's right, we just want to make it work. And with them I said, why don't we probably learn from the IETF or other bodies that we have a proposal which is kind of like the industry best practice out there. We get the examples and say, okay, we are not forcing you to do this, but here is the examples. Here are the successful examples that we propose that you can use to resolve some disputes among the user group that might share a script or language somehow.

And actually, I really don't think how to resolve that dispute should be ICANN's problem, actually. I think ICANN should make the policy that directs how to move ahead and how to preserve some rights. But not just, you know, getting everything together. ICANN is not the government; right? That's my point.

>>RAM MOHAN: Thank you.

While I see more people here, I wanted to find out if there are more folks here who should get at to the queue here.

I see Ming-Cheng.

>>MING-CHENG LIANG: Could I make a comment on Vint's point? Because from our standpoint of view, a new IDN gTLD -- an IDN TLD should go through the same process. That's my opinion.

I think it could go through the same process as in the gTLD process.

But there's a problem about the current new gTLD processes that I think ccNSO and GAC is not (inaudible) started. I suggest if we can modify something around that, maybe we will feel more comfortable and then the conflict could be reduced.

Secondly, I would think is this possible or feasible that because a lot of ccTLD is the one that currently running their registrations and using the English, and a lot of them, they already have IDN in their second level domain.

Is it feasible, possible, for each ccTLD at initial phase to choose a limited number, maybe one, maybe two, I don't know is the number, but a limited number of areas in? I mean "areas" in the loosens that it's equivalent to whatever they have in the country code at the present time.

And as long as it can be agreed, then we can get launch initially without confronting each other.

And then after that, all the other things might go through this new process. As long as the GAC and ccNSO are also consulted in this process, I would think it will be acceptable.

>>RAM MOHAN: Thanks, Ming-Cheng.

I'm proposing that I'm going to switch you, Olof and then someone back to the panel.

>>TAN TIN WEE: Olof is going to comment on what Roelof Meijer is going to speak about, which is something else, but I would like to address this point which Howard is mentioning, if it's possible.

I think ICANN has come to a point where it's almost a watershed. In a fledgling organization you have to build your own internal resources in order to maintain the kind of stability that defines you as an organization.

But ICANN has been around for long enough, and you can see for yourself the way how this organization has progressed through the years justly looking around you how well oiled the machine is already.

In terms of finances, you have no problems.

Therefore, it's about time for ICANN to start thinking about how it can work with other organizations.

Why? Why can't ICANN become the monolithic organization that encompasses everything and anything related to the Global information infrastructure?

Well, in a world that does not move at the breakneck pace which the Internet has allowed us to do so, well, you might consider a monolithic organization that will encompass everything and anything.

But faced against itself, it's hard to consider one single organization working on it's own will be able to solve everything that we encounter, especially when the Internet is the driver of innovation.

Then it's critical for us to come and ask ourselves this question. How can ICANN work with other organizations in order to answer questions in realms which it has no understanding of, in realms in which it has no expertise in? How can we work with other organizations which already have that expertise?

So I think this is a fundamental problem which ICANN has to grapple with. How can ICANN interface with other organizations and accept that they have some expertise which ICANN internally itself does not have?

And once you get over this problem, then you can see that many solutions that we have been encountering here, all these microscopic, minuscule members that are bugging us like gnats hitting against the wind screen will automatically be solved, because you will have that interface that allows you to interact and interface with other organizations that you respect and you mutually work with, and benefit from in synergy.

So we have in the case of the IDN process, the IDN invention which derived from many efforts that date back to, according to this flier, back to the '70s, this critical point that it is meant to serve the people, to be an enabling tool that will help people, and because of the original attempts that locked us into the ASCII character set, we have now because of the globalization of the Internet reached a stage where we realize we cannot actually reach the people who critically need this and it has in its way created this so-called digital divide.

So it's critical for us now to approach this problem and quickly find the solutions that will bridge that digital divide.

And it is for that reason that the so-called multilingual domain names emerged in the late '90s in the form of a workable implementation.

And I have been involved closely with that and have seen it grow and I am grateful that people have actually pitched in to work on this.

But we have reached a stage where we realize now that we need the help of other people and to work with them in order to deliver a solution that would bridge that digital divide.

We can try to solve the grand unified theory if we want to find the all-encompassing list or lists, list of lists, in order to protect this or protect that. These are all theoretical solutions that we can, in parallel, solve them. I am not objecting to that.

But I think the urgent problems of many developing countries need to be addressed immediately, not just in terms of delivering a solution to them, because while that was the aspiration ten years ago, now aspirations and expectations have risen far higher. Not only do these communities want to have these solutions, these end-user communities, they also want to have the chance to run these solutions. And these solution providers also have aspirations, not just in terms of end-user aspirations but also in terms of vendor aspirations.

And we have to address that. And GAC has very clearly stated that we need that global representation in terms of the people who supply the solutions.

Therefore, it's absolutely critical for us now, at this watershed, at the time when the ICANN has weathered a lot of fledgling problems that any international organization will face, that we now quickly address this. Can we create an interface that ICANN can work with other organizations? Can we say develop a mechanism whereby ICANN can outsource, franchise, charter the CDNC to work with the Japanese JDNA and the Korean KRNIC people and come up with a solution by X date and resolve all your different problems and then work out an agenda plan in order to deliver IDNs to the communities?

Can the ICANN develop a group that charters the Arab league to come up with a list of all the possible, whatever they want, ccTLDs or not? It's up to them.

Can we charter the international forum for IT and Tamil, which has also a diaspora as well as the Tamil Nadu community, to come up with a solution that will satisfy their requirements?

And then to adhere to the standards of IETF and whatever standards that we have and follow the UDRP and so on and so forth. Give them the job. Can we come up with that kind of interface? And that is what I hope that we can come away from this meeting in Lisbon. Thank you.

>>RAM MOHAN: Thank you, tin we.

I am going to go to Olof and then to Werner and then to the gentleman behind Olof and then to Edmon, and then I have Manal.

>>OLOF NORDLING: Okay, more input from the chat room, and a sequence of comments from Shahram Soboutipour. I think I'll get it by the end of the evening.

And I agree on protecting ccTLD IDNs, so my suggestion is to let each ccTLD registry determine it's preferred TLDs to be reserved.

Even more than one TLD, if needed.

Oh, it pops again.

But global decision is not useful since one rule does not fit all languages.

So I suggest to ask each ccTLD registry to define its alternate IDN strings for its ccTLD since they are more familiar with their own language.

Also, language community is also good suggestion. It can prevent any conflict between ccTLD IDN registries and gTLD IDN applicants.

And another comment has been added to this from the signature Augusti. And he or she introduces herself. My name is Maniam, chairman of the working group and executive member of the International Forum for Tamil in I.T.

Tamil Nadu is not a country code, but certainly the Tamil community might want one.

How would you propose ICANN to give you the power to decide and to charter you to come up with a list? And you will go back to the entire Tamil Nadu community and the entire diaspora and come up with your list of Tamil TLDs, be they gTLD or ccTLD or geographical TLD.

And it's signed www.infitt.org.

End of comment.

>>RAM MOHAN: Thank you. I am going to go to Werner.

>>WERNER STAUB: The idea of trying to introduce dispute resolution is actually something that already came up in the GNSO as inevitable.

So this is something we have to build up anyway, and Vint very clearly pointed to the fact that in this respect, you know, we just talk about TLDs.

We may actually have a situation with the fact that we do have some differentiation of ccTLDs and gTLDs that comes to our rescue. As opposed to being a problem, it is actually an advantage and can speed up the process in the context of this kind of determination. And we can even go to the suggestion that was actually I wanted to mention came from the comment over the chat list. If the IDN -- sorry, the CCT managers are encouraged to send lists of the strings that they wish to be reserved, it is helpful for everyone and it actually creates greater visibility. And I'm sure it will probably reassure people that the number of conflicts are not that high.

Finally, with respect to the other communities that don't have a ccTLD, I think that it is great that we have the GNSO process and the gTLD concept to our rescue, so to speak, and be lucky to have one example. We have dot cat which is a culturally linguistic TLD that is actually based on the concept of a gTLD, even though it is about culture and language. And I think in the case of Tamil, this is probably very good in the solution. So we might have a list of reserved strings with the idea that it might represent a territory country that is in the list, exactly matching meaning -- intended to match that meaning, whereas what is not intended to match exactly would come forward in the gTLD process.

>>RAM MOHAN: Thank you.

>>ROELOF MEIJER: Roelof Meijer from dot NL.

I probably shouldn't be talking here because I come from the Netherlands, a country with only one major official language and we have only one script.

But I want to make a few observations, and I'm not going to phrase them too politely because I'm Dutch

[ Laughter ]

>>ROELOF MEIJER: I have been working in this sector now for just over two years, and if I compare the pace at which the Internet has developed over those two years with the pace at which this issue has moved forward, I'm terrified. And I also wonder how we ever got the Internet in the first place.

I think the solution would be -- and then I want to make an exception for Werner and for George Sadowsky -- I think the solution would be that we westerners from countries with single languages and single scripts shut up for a while and let the work be done and the solutions be phrased by the people who have a pressing need.

Because I hear them say -- I hear them mentioning a lot of solutions, and I hear us coming up with a lot of problems.

Thank you.

>>RAM MOHAN: Thank you.

[ Applause ]

>>RAM MOHAN: Edmon.

>>EDMON CHUNG: With the applause, I better come up with a solution here.

Really, I was sitting here listening to the discussion. Ram, you started this discussion about whether this is really an IDN problem in terms of having some other identifiers for ccTLDs. And really going down that path and sort of welding together what Vint has said and Cary, when saying that, I emphatically nodded my head, it seems like we're talking about language communities, people who are ready to go. We are really talking about maybe a process that we need to create whereby another set of experimental TLDs come about.

We did the new rounds of gTLDs in 2000. Are we right now looking at a potential process whereby a new type of TLDs? Because if we look at ccTLDs, I think Martin made a very good point. It was a particular list that ICANN, or this particular community looked to create.

Now we're looking at something that comes from the language community. And I'm really -- I know when I make this particular comment I am going way past, way, way ahead of myself, but what about the contract issues? Like if we create such a -- such types of TLDs or IDN ccTLDs, or whatever it is, does it have a contract with ICANN? Is it managed by -- Who does manage it?

So perhaps if there are really communities that are ready to go, which we have heard, we need to create a process by which they come -- you know, become a basket, again, using the word, of experimental TLDs that is a slightly different category.

>>RAM MOHAN: Thank you.

>>MILTON MUELLER: Yes, I just wanted to follow up on this idea of simple rules not being viable that was argued by Vint and by George.

And I think simple rules are viable and I haven't heard anything in the interim that convinces me of that.

And let me just stress again, the ISO 3166 list worked because nobody worried about anything except coming up with a mutually exclusive simple set of codes that corresponded to everything that the U.N. recognized as a country.

And when you say this can't be done with IDNs, you are vastly underestimating the nature of human symbolic communication.

You can come up with simple codes that represent countries. You can let each language community choose which codes they want. I think that's fine.

But the point is, let's not make this into a more complicated a problem than it is. If the only problem you are trying to deal with is get the country code problem out of the way, let's start from the observation that the correspondence between symbols and countries is going to be arbitrary. Because all symbolic communication is based on arbitrary symbols.

So the meaning is going to be imputed to those symbols some step along the way.

Now, let me contrast that with the procedure that Vint provided.

Vint said don't go with the simple rule, go with a process. And what is the nature of this process?

Well, somebody at any indeterminate time proposes something, and then all the countries have to object to it.

And so what we have is basically the equivalent of 30 or 40 triple X determinations going on at the same time. It may be full employment act for ICANN. In fact, half of the world may be proposing TLDs and the other half may be evaluating them by the time we get to that.

But if you say to a country go and assert rights against somebody else who is trying to create a TLD, what will they do?

Well, the natural tendency, as we have learned in the trademark interest, is to assert as broad a rights as possible. Why not?

So I don't like open-ended process solutions. I do like very simple rule-based, code-based solutions. I think that's the way you have to go if you are going to solve this quickly enough to let people start implementing.

>>RAM MOHAN: Thank you.

Manal.

>>MANAL ISMAIL: Obviously, we have so many, many issues. And just to -- maybe to get things working more quickly, maybe we can categorize issues that are crucial and should be resolved before the introduction of the IDNs, and issues that could be -- that we could continue investigating as we go, especially if they already exist with the ASCII domain names.

>>RAM MOHAN: Thank you.

Back to the floor.

>>YASSIM MSHANA: Thank you. My name is Yassim. I'm from Africa.

And talking about multiplication of everything we are talking about here is, I came to count the number of "Ps" that have been mentioned here. Now, I wonder, is it the "P" for promotion of business, or promotion of what is causing IDN issue to become as big as it is now?

Or is it protection? Is there protection of some kind of an entity or what?

Another "P" is that is there political pressure behind this discussion which is now going to take so long and create so many problems, more than solutions that have been provided so far?

And another one, another "P" and what type of protocol should we use in order to come to an agreeable point that we can move forward?

Another "P" is the probability of success in whatever people want to achieve.

Are we going to be successful? The probability of success is another issue here.

And the chairman said, "Will it work?" That's another probability.

Another one is, a positive one, now, is another "P," a proposal. What's the proposal now, what do we propose to do in order to move forward. Otherwise, there's going to be a problem. All I have to say here is this: I thought that ICANN was a process. That's what I understood. Now it's been personalized, as if ICANN is somebody who's doing something. I think ICANN is everybody who is a stakeholder.

Another "P" is pointing fingers.

[ Laughter ]

>>YASSIM MSHANA: Endless series of "Ps." Thank you.

>>RAM MOHAN: Thank you.

I have Martin.

>>MARTIN BOYLE: Thank you very much. I'm not going to list Ps. That was certainly an entertaining and imaginative way of presenting quite a series of ideas.

I -- picking up on a point that Vint made, I'm certainly not a fan of sitting down, writing lists, because whenever you sit down and you write a list, always some smarty is going to come along and find something you've missed.

But I think one of the advantages of having a list that is bounded and because we can start off with the ISO 3166 list, we know what ones have already been identified, and therefore we can do the list on there, why that is an advantage is that we don't end up with every country in the world scrutinizing with great care exactly what proposals everybody's made, and as I think it was Milton just referred, then challenging everything because they want to try and snatch or guard as much as they can.

But I would actually recognize, and I'm acutely aware, like Roelof, I come from a country which does only use a very, very plain form of the Latin alphabet, that this is very urgent and a very important issue.

My earlier intervention was, though, that I don't want to swap short-term expediency for long-term agony. And I think that does mean that we've got to at least give a certain thought to how to respond to those things that are almost certainly going to happen if we don't think it through correctly.

And I was hoping that somebody from the standards community might actually be here today who could then sort of pick up on how long it might take to work through a standards solution.

But the messages I heard yesterday in the session was that you could start producing lists of countries in particular scripts very, very quickly, using a community-based system, and have something that would be recognized and recognizable as an international standard. And we were talking about sort of -- and my short-term memory is terrible, so somebody correct me if I've got it wrong -- something in the order of six, nine, 12 months for fast track, although in the worst case, if you had to go through the slow, grinding process of an international standards process, it might take you up to five years.

So certainly one would want to try to look for how might you be able to get a methodology and then -- and I pick up this point very, very clearly from those people who said, "well, we're ready to go," from those communities, those languages groups where they are ready to go, because in those cases, it should be very, very quick and very easy to populate lists.

And you don't have to get every country in every script ready at the same time. You've just got to get every script ready. Because while I'm pretty darned sure that there will be people who will, in scripts that the average Brit will not understand, who will be able to show that they have got rights to "United Kingdom." And that, I think, does start leading to serious problems.

And now I'll pass the floor to somebody who I know is an expert.

>>RAM MOHAN: Khaled.

>>KHALED FATTAL: Thank you, Martin.

I've been standing in line, and as I'm trying to put together my thoughts, as I'm listening to more, I start adding more and taking out more.

But here I'm going to speak on behalf of many hats.

As MINC chairman, as an Arab, but I'm also going to request the Dutch to allow me to be adopted for two minutes, because I'm not going to be impolite or rude, but I'm going to be blunt.

I think we're asking the wrong questions, ladies and gentlemen.

The question is not about how long the string should be, because -- and the question should not be about whether it's the ccTLD first or the -- or -- to be implementing IDNs, or whether it's the gTLD to be implementing IDNs. I think the question we have to ourselves is, are we trying to assist the international community and the local language communities to become enabled sooner than later to have Internet in their own language? Is this our objective? Or are we asking ourselves the question of how do we make this process deliver this objective?

Because the truth of the matter is, if somebody's thirsty, if the rain provides them water to drink, they will drink it. If they have to dig into the ground, they will pull it out and drink it.

Without a doubt, I actually recognize the enormous challenges this process is faced with in making sure that it's done correctly and right. That I -- I pay tribute to.

But in that process, there is a huge need that is just being delayed. And where I'm actually seeing a serious concern is that if -- for example, if I'm a professor and I have to give a grade on my students' learning ability from what's been put forward, this process will barely get a "D," maybe a "C," because there are a lot of things that we have informed and called on, and yet we're still talking about it.

I won't go into detailed examples. If anybody wants them, I will give them.

But the truth of the matter here is, until this process learns of everything that needs to be learned by itself, or become good students to learning from this, you know, it could take another five, ten, 20 years. And in the meanwhile, people are still thirsty, and they want water.

So I call back another fundamental issue here is that I think we need to recognize that the objective is to deliver the ability for the local -- the non-ASCII world -- let me define it that way -- the non-ASCII world to become enabled so that those who don't speak English or a European language are able to participate on the Internet. It's part of the empowerment. And that process, ladies and gentlemen, cannot take place until we learn from their experiences, we go back and find out what they've done and how they've done it well, and then move forward.

So I really think the challenge is, we need to figure out this question.

And one other last point. And this is a challenge, in my opinion, to ICANN.

The challenge is, ICANN would have a far greater opportunity to lead in that field if it's not seen as an authorizer, but more of a facilitator. Once -- and I've actually gone on record on this on the IDN president's advisory committee, and I've said this in public.

Even when we solve many of these technical issues, which are vital -- they have to be solved -- we may find that many local communities might feel very, very challenged to feel as if they have to step up to an organization and ask them, "Please authorize me."

There's an element of maybe showing them a bit more respect that will make them feel as if they can participate.

So perhaps from that sense, ICANN, or whoever is going to be this enabler -- and I hope ICANN can step up to the plate and do that -- would actually be able to become the facilitator rather than the authorizer, because many cultures might find themselves very, very challenged to come in and submit an application, if I may say so Dutchily.

My last comment. Thank you very much.

>>RAM MOHAN: Thank you. I have Jonathan.

>>JONATHAN SHEA: Isn't that very clear?

I think one of the fundamental issues on the whole IDN TLD initiative is the two camps to start with. One camp believes that a general all-embracing solution is necessary to avoid long-term pain, long-term problems from coming up. Another camp is that, you know, we should be more adventurous, we should, you know, have the spirit of innovation, go and do a little bit of experiment, go do it bit by bit, and then we solve the problems along the way.

But from the forum today, it is quite clear that the second view seems to be enough to satisfy the needs of the community, as mentioned by the gentleman, the last one, yeah.

The real way to solve the needs, to address the needs of the non-ASCII, non-English-speaking community is really to have a solution coming up sooner rather than later.

Also, we talk about the process. And it is quite clear that the key elements of the process are being discussed. Probably, you know, people come together to propose their labels, to start with, in a controlled manner, in baskets, in bursts.

And we have a resolution process whereby conflict, a potential conflict, which we do not expect there will be many to be resolved. Then we can get things going quicker than it is now.

>>RAM MOHAN: Thank you.

>>S. SUBBIAH: Subbiah, IDNS.net.

My point here is not so much particularly the ccTLD issue, Vint suggested the notion that perhaps ccTLDs and gTLDs can go together. But my point is in general. Because there were some comments earlier about the fear perhaps that if a language community, undefined community, participates in the process, that it may take some time, and it's a new process that's being invented, you know, and so it may be a challenge to ICANN.

I think there's a happy halfway home, which is, workable, I think. And that could address the "P" that I would want to bring up, which is partnership, which is that we have a process now, I think, in the gTLD cases, at least, in ASCII, where we do have a committee of enough people who are selected who, like usual processes in ICANN, who then decide on a particular gTLD string that is going to be awarded, whether that's the gTLD string and so on, using also guidelines and things going forward.

In the case of a multilingual situation, where it may not necessarily be ccTLDs if you go through a list, but, you know, certainly gTLDs, but, in general, the philosophy being that the same sort of committee that one may have that is composed of technical people and so on and so forth, where we may have had for an ASCII gTLD in the past, could be complemented with people who would be taken from the language community, you know, a language community perhaps like in the case of Chinese or something, or CDNC that works out some of the issues. But then when it comes time to actually discuss the string in terms of TLD application and going forward, at that point in time when things get pretty critical, then if a committee that is ICANN -- an ICANN committee that includes people from that region or regions, or the people -- a global thing where, you know, if a language is mainly spoken in one place, then more representation from there, but the community outside of that country c!

an also be represented by additions of people from that community, to a committee that then decides, you know, basically, going forward, you know, how that language community figures out, you know, the award process or the, you know, selection process and so on and so forth, making sure of things. That could be a healthy partnership. There's no reason why that's kind of an adversarial thing.

And it would not be too difficult. If the issue is, look, it's going to add more complexity to -- you know, because for each TLD string or a language, you may have to bring some extra people on board from the community, well, then, you know, in a way, that's life. This is complex. And people have gone, spent a long time, you know, cultures have gone for a long time, a thousand years with their languages, it's a complex thing that they've created. And to have some input at the time of the decision-making would also, I think, there's a little bit more cost and time, then I don't think it's a big deal. And the fact also the last point I want to make regarding that is, it solves a big problem that I think has been sort of a little bit in the background in the discussion so far, which is the issue of legitimacy. If you allow people in the community to be part of that decision-making process for that particular language group and so on, you buy legitimacy, you really do, if!

you include a few people in that process.

And I think -- and if they're not ready to be able to do that, well, then skip that, they're not ready as a group. And you go on to the next one, you have a legitimate reason to move on to the next one. That's the point I would like to make, I would just like to say "P," partnership that would make a good way going forward.

>>RAM MOHAN: Thank you, Subbiah.

In the interests of time, we are just about at the end of our -- of this workshop, what I would like to do is ask our panelists to kind of make closing comments, if you will.

I had earlier suggested going -- you know, my -- right to left. But I'm actually going to change the order and say let's go left to right and start with Martin and go back, so that it kind of just wraps here.

And also, given the interests of time, if you could just take it down to about 30 seconds or so, not a very long comment. Because we're just about at the end of our thing.

So you are kind of reduced to just a few sound bites.

>>MARTIN BOYLE: Thank you. Being a civil servant, I always leave the sound bites to the minister.

I think that one thing working for governments always teaches you is that if something can screw up, it really will screw up. And that, I think, does have to underpin any sort of general thinking about how do you move forwards.

The second point I think I'd like to make is that why has the DNS been so successful? Why have domain names been so helpful? They've helped people negotiate the Internet. It started off with -- and I speak as a nonexpert, coming to this quite late on in life. But it started off with some sort of basic structure, even quite a simple structure, that helped people understand where they were in something that was actually quite a diverse and difficult environment to navigate and negotiate. And I think that is something that people have got to -- have come to expect and something that I think we do need to consider for the future, which is why the more I think of it, about it, the more I think it is important that just for the country side, we need to be able to maintain some sort of structure that people will represent, even if only to protect themselves from the people who wish to do bad things to them by pretending that they're something that they're not.

Thank you.

>>EDMON CHUNG: We've talked a lot about the item itself. But, I guess, in closing, I would like to say that this format is quite useful in a certain sense, I think. We started the discussion with -- focused on ccTLDs, but we've quickly found that it's inevitable that we would be talking about gTLDs and other items.

And I think there -- we covered a good portion -- you know, a good amount of information today. But I think we should have -- there are still a lot of items, especially for gTLDs, which we touch -- we keep touching on, but we never really start a discussion.

The GNSO IDN working group was actually focused on the gTLD -- new gTLD issues. And we -- which, unfortunately, we really weren't able to cover.

So I think, you know, I don't know what the plans are in terms of going forward, how we can talk about this. But from the GNSO discussion, I guess from the other discussion as well, we found that it's inevitable that we will start moving into other people's area. And that comes back to one of my ideas today -- I brought up today, which is, seemingly, the conundrum that we're in right now, or, actually, I shouldn't say -- the situation -- let's put it that way -- that we're in today, some of the ccTLDs or ccTLD managers believe or feel that they are -- have a lot of urgency and that they are ready to go, maybe coming back to my idea, maybe there could be a different basket for different type of experiment that is neither ccTLD nor gTLD, and coming back to Martin's point about ccTLDs and being able to point to a list, I -- personally, I feel that's quite important. And that's probably the only way that we can have something that will stand on its own feet.

>>RAM MOHAN: Thank you.

>>HIRO HOTTA: Given that some of us are ready to go, as several of us said, let's go with (inaudible).

First phase should be very simple, a small number of ccTLD and maybe small number of gTLDs, with review, challenged, objection, process, then more sets of investigation would be made to make more phases. Thanks.

>>RAM MOHAN: Thank you.

>>JONATHAN SHEA: Echoing Edmon's and Hiro-San's comments I think a key feature coming out from this discussion is that the process itself inevitably involved both the GNSO and the ccNSO constituencies. It seems that this is quite obvious now. And this, of course, is another undertaking, may introduce a bit of complexity in the overall process. But I think it is important to realize this up-front. And we both have to really get it going, you know, to resolve this.

Secondly, I believe u talking about the process, in order to make the problem, we have to break down this problem into several simpler ones.

One way is to consider a script-by-script, you know, introduction to make the whole thing more manageable.

The last point I want to echo is, yes, there are existing language communities out there, and they have done a lot of work, like the Chinese domain consortium on the Chinese language. And it is -- there is no reason why not we go out and get their expertise.

>>RAM MOHAN: Thank you.

>>MINJUNG PARK: This is Minjung park from dot KR. I would like to make a brief comment on IDN TLDs. Whenever dealing with IDN TLDs, I think we should always consider the demonstration of support from the local language community, even during the -- as a requirement for the application for a new TLD, as it is -- it would be very inappropriate to think the IDN TLDs are separated from the local language community. Thank you.

>>RAM MOHAN: Thank you.

>> KELLY KANG; Hi. I'm Kelly Kang, member of Korea.

I appreciate the contribution of ICANN and all relevant entities, including GNSO, ccNSO, and GAC, regarding ongoing discussion on the inclusion of IDN at the top level for the proliferation of multilingualism of the Internet.

The introduction of IDN TLDs is expected to be a turning point in the history of the Internet.

As much as it is important to assure the stability of the Internet, it is important that a harmonized IDN policy be developed.

In line with ICANN's mission and core values, the introduction of IDN TLDs should be seen as practical and beneficial, in the public interest, and supporting the function of geographical and cultural diversity of the Internet.

Such a full discussion of delicate issues, including political and cultural aspects, should be done with the collaboration and cooperation of all the Internet community, expressly, the local language community, prior to the actual implementation of the -- of IDN TLDs.

Taking in account the distinct characteristics of IDN TLD, which is to serve the language community, governments' endorsements, and the support of the language community should be considered as an application requirement for an IDN TLD.

Thank you.

>>RAM MOHAN: Thank you.

>>MANAL ISMAIL: Actually, I have nothing to add. Just to maybe I reiterate my previous comment that to get things moving faster, maybe we should identify all the issues and then categorize issues of crucial urgency that needs to be tackled before the introduction of the IDNs and other issues that we can go on investigating.

Thank you.

>>RAM MOHAN: Thank you.

>>WERNER STAUB: Again, the important thing is to be able to move fast. And probably one of the ways to do so, if you take the metaphor of a tunnel, is to drill it from both sides rather than from just one side.

And there is married to the idea that there should be lists in the sense that some communities that have some coherence between each other, they come up with this and they actually have done, in most cases, their homework.

In other cases, when they are not groups such as Greek or Korean, they have a pretty good idea and they are easy to consult. It is not a difficult thing. We don't have to mandate anybody else. We can basically receive their input.

We then have in the case of the ccTLDs that certainly need to be protected against the possibility that the gTLD would be introducing that, we have already a level of protection by the fact that country names by the GAC principles are not necessarily available.

We have a couple of cases where it is the ideal string would not necessarily be like that. It could be different. One could imagine, for instance, that for the word China, the word China, which is middle in country, that for some reason just middle, which one symbol, would actually be very nice. And there should be an ability right now, actually as we go home, so to speak, for the CN NIC to say basically we would like to reserved, irrespective of whether we want to use it, someone else should not come and say we want dot Chinese idiograph or middle as a gTLD. That is fairly straightforward. It doesn't take a huge committee to do that. It's just about publishing the list.

Then at the same time, we should keep in mind that this is not the last word. That this is not a call and if you don't come forward now it's going to be done forever, something line that. But let it be a consensus point that if gTLDs come up that actually cause a problem to ccTLDs that this can go in front of a panel that will actually come up with a solution.

>>TAN TIN WEE: I think there are many wonderful solutions that are put forward, and I think we should pay heed to these and I would just like to contribute one -- a few possibilities that perhaps maybe in the next ICANN meeting that you might like to invite specific language community groups to come forward and have a dialogue. Or at least to get to know each other and establish a level of trust so that we can move forward.

And I think that's easy enough to engineer.

And perhaps we would even like to consider creating an international relations office that will champion, create Ambassadors, ICANN Ambassadors that will go to communities as a matter of outreach in order to facilitate their groups forming so that they can come back with good proposals that we could use.

So I think in the building of this global information infrastructure, maybe it might be useful for us to remember one interesting Chinese saying.

(speaking Chinese). Roads are actually walked into existence by people.

There's no road there, but people walk along those roads, the path, and it becomes a road.

So building the global information infrastructures where we have the superhighways and so on, we should not be telling people don't walk. Let them walk and maybe somehow or other they will walk a road into existence. Maybe somehow a standard will be used into existence, and perhaps maybe symbolic codes will be used into recognition.

>>RAM MOHAN: Thank you.

Ming-Cheng.

[ Applause ]

>>MING-CHENG LIANG: I think it's a very good comment. I think I want to comment, is that IDN itself, of course, is very complicated issues and I think like the ISO process, this type of ICANN, it will go on. But more, I think we should more concentrate on the initial phase. What should we do in the initial phase?

If we want to be able to implement IDN to the needs of the people at the present, at a shorter time, I think that we've got to be able to start lightweight and simple and with an amendable process.

And I think there's something we should concentrate on, at least at the present time, and make the IDN fly.

Thank you.

>>PANKAJ AGRAWALA: After the wonderful concluding statement made by Tan Tin Wee, I can only say if the Internet is all about being intuitive, then the local language has to be empowered and the meaningfulness of a language, the character set that supports that language and the community that speaks that language has to be established.

Thank you.

>>RAM MOHAN: Thank you.

[ Applause ]

>>RAM MOHAN: Clearly, IDN at the top level is an idea whose time has come. It seems to me that perhaps there's distinction between ccNSO, GNSO that seems somehow relevant in the ASCII area, perhaps isn't as relevant when we're talking about the development of basic policy for IDNs.

Perhaps more overlap is needed.

So let us list common problems first, then let us find common solutions.

Let us then delegate specific problems and specific requests for solutions to the groups that can do it.

So I'm strongly in support of many of the comments that have been made here, and perhaps what we really need to do is to ask ICANN to help find a way to facilitate so that this distinction goes away. It doesn't seem to work well in the IDN space, so let's -- we made this up. Let's make something new that actually will work.

I thank everybody for being here. I thank the audience for having stayed through, and look forward to a continued vigorous debate and to actually getting solutions in place very soon.

Thank you.

[ Applause ]

(7:45 p.m.)