Site Map    |    Site Index    | 

Quick Links: Select A Link Below About ICANN Accountability and Review Accountability and Transparency Address Supporting Organization (ASO) Announcements Annual Report Articles of Incorporation At-Large Advisory Committee (ALAC) Blog Board Meeting Minutes Board of Directors Budget Bylaws Calendar of Events Committees - Other Committees - Advisory Committees - Board Committees - Past Contact Information Contracts Contractual Compliance Newsletter Contractual Compliance Program Corporate Documents Correspondence Country Code TLD Managers - Information for Country-Code Names Supporting Organization (ccNSO) Country-Code Top-Level Domain Agreements Country-Code Top-Level Domain Board Materials Country-Code Top-Level Domain Listings Current Topics Dashboard Documentary Information Disclosure Policy Documents Domain Name Dispute Resolution Policies Employment Opportunities Factsheets Fellowship Office Financial Information First-Time Visitors Former Directors Frequently Asked Questions GNSO Improvements Generic Names Supporting Organization (GNSO) Generic Top-Level Domain (gTLD) Program Generic Top-Level Domain (gTLDs) Life Cycle Generic Top-Level Domain Information (gTLDs) Global Partnerships Glossary Governmental Advisory Committee IANA Agreement IANA ccTLD Reports IANA ICANN Info IDN Glossary IPv6 Policy Independent Reviews of ICANN Structures InterNIC Internal Procedure for Conflicts with Privacy Law Internationalized Domain Names Links Litigation Documents Major Agreements Maps Meetings Mission Monthly Magazine Monthly Registry Reports News Newsletters & News Alerts Newsletters Archive Nominating Committee Ombudsman Operating Plan Organizational Chart PGP Keys Participate in ICANN Partnership Memorandums of Understanding Payments to ICANN Photos Planning Process Policy Area Policy Issue Briefs Policy Update Presentations President and CEO President's Strategy Committee Press Resources Public Comment Public Participation Site Publications RSS Feed Registrants Information Registrar Accreditation Agreement Amendments Registrar Accreditation Overview Registrar Advisories Registrar Agreements Registrar Complaints Registrar Data Escrow Program Registrar Information Registrar Problem - Get Help Registrars - Accredited Registry Agreements Registry Information Registry Listings Registry Monthly Reports Registry Services Evaluation Process Report Inaccurate Whois Information Resources Root Server System Advisory Committee (RSSAC) Security and Stability Advisory Committee (SSAC) Speeches Sponsored Top-Level Domains Staff Strategic Plan Supporting Organizations Technical Liason Group Transfers Translations Transparency Travel Support Universal Acceptance of All Top-Level Domains Video Vint Cerf's Legacy Letter to ICANN Community Website Enhancement Whois Information Whois Search

Search:

Internet Corporation for Assigned Names and Numbers

  |  Subscribe: Newsletters & News Alerts  |  ICANN Blog  |  Public Comment

• Home
• About
• Policy
• Current Topics
• Processes
• Documents
• Video
• Contact

^ Home

> Meetings

>>CHRIS DISSPAIN: Good morning, everybody. There's plenty of seats up at the front here. Don't be scared. We'll start in a couple of minutes' time.

Okay. Good morning, everybody. Welcome to the first day of the ccNSO members' meeting. Just before we start, most of you will have noticed that we have a table at the back of the room with two people sitting there with headphones on and computers and they're actually scribing this meeting. However, it's not going to appear up on the screen. It's being scribed effectively for the record and also so that they can practice, I think, basically right.

What that actually means -- what that actually means is that if when you -- if you say something -- if you stand up to say something, if you could say your name, that would be great. And perhaps if you would, in the break, if you have said something and said your name, you might want to go and check with them that they've actually spelled it properly for the record. Okay.

We're going to start the meeting with our discussion on regions, and Dave Archbold is going to come do that, so if you want to come up and do that.

Basically, the I've asked Dave to have a look at this because he's one of the people who is most affected by the current position. Over to you.

>>DAVID ARCHBOLD: I'm not switched on.

>>CHRIS DISSPAIN: Can we have -- is the projector not on? Okay. First issue of the morning, no projector. How do we turn it on? Let me guess. Use the "on" switch, right? Fantastic. Thank you.

>>DAVID ARCHBOLD: Well, good morning, ladies and gentlemen. I'm Dave Archbold, and before I start, I should perhaps get Chris out from under.

These are my views; they are not views that I've discussed with Chris or with the council in any way. So this is Dave Archbold's presentation.

Before I move on from the title screen, you might like to actually have a look at the map that's there. It is just a bit of clipart, but I've tried to show with the coloring what the actual present ICANN regions roughly are. But it is just roughly.

Perhaps worth noting before we go on, the size of the blue area. And you might also like to note, if you can see, I'm going to be talking about both the Caribbean islands here, and some of the islands down in the Pacific down here, and their relationship with Europe, and just bear in mind in the distances involved.

An introduction is that although you may think that this discussion is not particularly relevant to you, you may find by the end of the presentation that perhaps it is. And even if it's not, those that are affected really need your support. So please bear with me as I go through some of the issues.

The agenda, then, for my brief presentation is: Why are there geographical regions? What are the problems? Why are we looking at them now? How did we get to where we are? What's happened so far? What were the survey of results? And I'll talk about the survey in a moment. And then where do we go from here?

So let's start with the definition of the regions. The definition is in the ICANN bylaws, in the section on international representation. I won't read right through it, but you will notice that they are predefined as five regions: Europe, Asia-Australia-Pacific, Latin America-Caribbean islands, Africa, and North America.

Why do we have regions? Well, they were introduced to achieve geographical diversity of representation on the ICANN board, the At-Large Advisory Committee, and the ccNSO council. And as a result, the ALAC and ccNSO regional organizations are or will be based on the same regions. And in my view, it's a top-down structure, rather than a bottom-up one.

So what are the problems? The majority of the existing ICANN community can probably live with the status quo. But what about the Internet community that is not yet involved in ICANN?

A small number of nations -- let's call them that for the moment -- typically from amongst the dependent or overseas territories, consider that they've been put in the wrong region. And others make a case for increasing the number of regions from five to six or even seven.

So let's talk about some of the overseas territories because that's the one I can really speak for, coming from Cayman.

As far as I'm concerned, I'm located like this: Physically, I'm in the western Caribbean. The U.N. statistics office puts me in Latin America and Caribbean. But even they hedge their bets because there's a note at the bottom of the same table that says that North America comprises North America, Caribbean, and Central America, so maybe I'm in both Americas, but not according to ICANN bylaws. They say I'm in Europe.

But ICANN's Address Supporting Organization for practical reasons puts me under ARIN, together with the U.S. and Canada. And then ICANN itself, in setting up its regional liaison organization, puts me with Canada and the rest of the Caribbean.

So what are the consequences apart from personal confusion?

Well, no one from Cayman Islands can realistically stand for election to the councils of the ccNSO or ALAC, because they're required to be nominated and elected by members of the EU region. Individuals they don't know and have never met.

It would also be impractical for anyone from the Cayman Islands to participate in or benefit from the work of a ccNSO regional organization or RALO, and they're not entitled to participate in the work of any other region.

And it's not just the Cayman Islands. Potentially -- and I do emphasize "potentially" -- this is a list -- I'm not sure how well you can see it -- of various territories that fall into this category.

Turning to the question, are there too few regions, many people suggest that the Asia-Pacific-Australia region is too large and when they say "too large," they tend to mean for regional participation because the distances that you have to travel to get together are so big.

Moreover, the U.N. statistics office designates six regions, so why does ICANN have five?

Some regions with clear cultural and economic ties would like their own region. For example, the 22 countries of the Arab league. And just in case you're not sure where the Arab league is, there's where the Arab league is, and those are the participant countries.

I think you will notice that at the moment, some of those countries are in Asia-Pacific and some are in Africa.

Why is this all a concern now? Well, as the membership of the ccNSO has grown, so has the pressure -- largely from me and a few others -- to sort out the anomalies in the regional structure. It was discussed by the ccNSO council in Marrakech, and the concerns were reported to the ICANN board.

A survey of ccNSO survey has now been completed recently, and the results I'll show you in a moment.

The bylaws require at least a three-yearly review and a review is due this year, and a discussion paper has been issued by ICANN.

So how did we get here? Five regions contained -- the reference to five regions were contained in the original ICANN proposal in response to the RFP from the Commerce Department. There was no explanation on the public record that I have been able to find that says why the number five was selected. And it wasn't just me, because the same question was asked at various times during public discussions in 1999 and 2000, and, again, there's no response on the public record. At the Yokohama meeting in 2000, the board had to assign countries to regions anger it was quite a priority item because they wanted to get the ALAC elections off the ground. GAC was asked to advise and in their communique said simply to use international norms. That was their only comment.

ICANN staff proposed the use of the U.N. stats allocation, and this was accepted. However, as I've mentioned already, the U.N. stats had six regions, because they included Oceania, which were mapped into the five ICANN regions, but as far as I can tell, there was no discussion of that on the public record.

Staff also said persons from areas that are not countries would be grouped together with the country of citizenship for that area. Again, no explanation.

In Montreal in 2003, allocation was reviewed in accordance with the bylaws. The topic paper actually implied treatment of the territories was advised by GAC. Not that I can see.

Allocation was again endorsed with much discussion, but three directors abstained and one voted against.

So what were the procedural errors that I perceive? Well, there was no discussion with the people impacted. They weren't even represented at the discussions. GAC didn't advise. There's reference to a comment which, in some public discussion, it was admitted that this was in a quite separate context.

The wording of the motions in 2000 and 2003 only approved the allocation in accordance with the U.N. stats. It did not authorize compression to five regions or the allocation of the territories.

Supposedly -- the territories were supposedly allocated on the basis of citizenship, but this wasn't applied correctly or consistently.

For example, some territories are not citizens of the mother country, and this was supposedly based on citizenship, and that includes the citizens then of the British overseas territories, also American Samoa, to mention a couple.

Just to recap a little bit on what's happened so far, as I said there was discussion at the last ccNSO meeting in Wellington. Concerns were reported to the ICANN board at the New Zealand meeting, and this resulted in some interesting discussions during the public session. Then there were further discussions of the -- our council which resulted in a recent survey of ccTLDs on the subject, and I can now show you the results of these.

Firstly, I would say it wasn't -- I'm not suggesting it's a scientific survey. It was to try and get a feel for people's views. By my reckoning, and I may be wrong, the total number of ccTLDs at the moment are something like 242, and latest count in the ccNSO, I think, is 51.

The number of responses that we got to the survey was 41. Of those, 21 came from ccNSO members and, by a quick bit of difficult math, I worked out that that left 20 from non-ccNSO members.

These are the questions. I shan't run through them all. You can see them on the screen. And in each case, respondents were asked to make comment if they agreed or if they said yes to the questions. We actually -- they weren't actually asked for comment if they said no.

Okay. The first question, I haven't analyzed because I thought it was simple and straightforward: Which region are you in?

In fact, there were some different responses to that. People weren't -- or didn't appear to be sure whether they were being asked which region were they currently in, or which region did they think they ought to be in, and some actually just gave the name of their country.

Moving on to Question 2, are you in the correct region, not surprising total responses 36 said yes. That's 88%. And 4 said no, 10%. There was one no-response.

The question was, in some circumstances, should the ccTLD manager be allowed to choose which region he's in. Yes said 13% -- said 13 overall. That's 32%. 18 said we don't care. Perhaps it should be we don't mind. There were 9 no's and one no-response. And you'll see the ccNSO responses, there was a slightly higher bias to the yes.

Now, the reason I put -- split that out is, I felt that there was a slightly better chance that the ccNSO members had listened to the previous discussion in Wellington and, therefore, were perhaps a little bit better aware of the circumstances.

Should there be more ICANN regions? You can see the results there. I'm not going to spell them out.

The last question: Do the current regions impede participation? I've got to say that in a number of the questions, looking then at the comments that were made, I think there was some misunderstanding of some of the questions. I think people weren't sure whether, for example, this question they were being asked do the current regions impede your representation -- your participation or whether they thought it was participation overall.

So in summary, some ccTLDs think they're in the wrong region, but one solution doesn't fit all. It depends on the culture and the language, et cetera.

The majority of respondents either support allowing them to change or don't mind if they do. Some ccTLDs think there should be more regions. Comments made include Asia-Pacific is too large, Arab states would like a region, there's some mention of the Middle East. However, the majority of respondents either support or do not object to this view.

Okay. Moving on to my personal conclusions from all this.

I don't think the present ICANN position is sustainable. In my view it runs counter to the ICANN core value of seeking and supporting broad, informed participation, reflecting the functional geographic and cultural diversity of the Internet.

There have been too many procedural errors. At the very least, a similar motion would have to be reworded to authorize the reduction to five and the present treatment of the dependent territories.

In my view, whilst attempting to achieve an expedient politically correct solution, ICANN has confused the issues of sovereignty, nationality, and citizenship which are not the same thing.

Regions should be about maximizing participation and representation, and, therefore, should be built, in my view, from the bottom up, not from the top down.

Looking at the existing bylaws on diversity, I think they would work, without amendment, as far as the ICANN board is concerned if the number of regions were increased. But there would be implications for the structure of the ccNSO council and at-large committee.

However, any proposal to change the number of regions could reopen the debate about regional influence, politics, and the basis for representation. So that's the downside.

Where do we go from here? These are options and/or in each case.

We, the ccNSO, could use Article IX, Section 4, Para 4, to allow a ccNSO member to self-select their region where the correct region is in doubt. And I hope my little bit on where I stand proves that at least I'm in doubt.

This would be a quick fix for territories that wish to change region. The ccNSO could define its own regions for its own purposes, and this would presumably need a task force and/or a PDP and/or we can respond to the ICANN consultation urging ICANN to set up a task force to examine the issue at ICANN level, which would involve at least ALAC, the ccNSO, and the GAC, I would suspect. In mentioning the ALAC, there has been some concern expressed by individual members of ALAC as well about similar issues.

Okay. Just before I end, this is -- this was the original clipart that I doctored for my opening slide. This is as it came from -- I think it's called worldmap.com -- and it's just interesting that this shows the regions -- the world regions as they see them, and you'll notice here we've got North America including Iceland. Iceland apparently isn't in Europe, as ICANN says.

The -- South America. Europe. They've put in a Middle East region there. Oceania down here. So Asia-Pacific is a little bit smaller. And of course Africa. And that's it. Thank you very much, ladies and gentlemen.

[Applause]

>>CHRIS DISSPAIN: Thanks, Dave. Can we -- has anyone got any questions that they want to ask before we look at where we can go from here? Lesley? Just -- thanks.

>>LESLEY COWLEY: Okay. Now I'm on. Lesley Cowley from Nominet U.K. I just wanted to cover off the point about where in doubt, the CC might select an alternative region, and wondered whether you'd considered whether that might be somewhat broader than that.

For example, if there are extraordinary circumstances where, for example, the cc is surrounded by hostile countries and actually participating in that region might be very difficult for them, in those circumstances. But that would have to be perhaps extraordinary circumstances.

>>CHRIS DISSPAIN: It's coming out through the speakers, so if you can't hear, take your headphones off and you'll be able to hear me. Exactly.

The reason why it was in there in the first place, it wasn't intended to cover off --

[Speaker off microphone]

>>CHRIS DISSPAIN: Is that okay? Okay. Good. It was intended to cover a circumstance where the boundaries, the actual boundaries weren't clear, so it certainly wasn't intended to cover something like Cayman, which is in one of those things that is supposedly a dependent territory. It was more intended to cover -- and I can't think of an example but where it wasn't clear, whether -- the country was on the border of a region, so I don't know, Mexico maybe. Don't know. But that's what it was intended to cover.

However, it doesn't say any of that. It just says "in doubt." And as Dave has quite rightly said, really we could interpret it any way, within reason, any way we choose. But you're right. I mean, certainly it would, in my view, cover something like that. But it's -- and I think it's best characterized as you have as a quick fix, and it's probably not actually -- you know, it might work in the short term but it's not really a solution. Anyone else have any questions? Ron? Can I get the microphone to stay down here and we'll pass it -- we'll pass it around amongst ourselves? We're quite good at that. We've had some practice. Ron, put your hand up.

>>RON SHERWOOD: Hello. Ron Sherwood, dot vi. My question is a simple one. Thank you for your presentation, but if you had a choice, where would you put Cayman?

>>DAVID ARCHBOLD: North America.

>>RON SHERWOOD: That's really interesting. And you feel that you would have some influence in the North American region?

>>CHRIS DISSPAIN: You could argue the North American region is the one you can have the most influence over because it's got the smallest number of members.

[Laughter]

>>RON SHERWOOD: The reason I say that is, of course, the United States Virgin Islands is considered part of the North American region, but the likelihood of a Virgin Islands representing North America is, as you said in your presentation, pretty remote.

>>DAVID ARCHBOLD: Sure. I understand, but at least I have a chance equally from a regional perspective, at least there will be an opportunity for my Internet community to get involved in regional functions of any kind at a reasonable cost.

There's no way they're going to fly across the Atlantic to do it.

>>RON SHERWOOD: May I just follow up, please? I understand that. But I do have another question, and that is: You didn't mention anywhere language, and it seems to me that I've been working with the ALAC as the liaison from the ccNSO, and the language difficulty is one that we're encountering right now, and in the Caribbean, for example, where you have, I think, three different language bases, you didn't mention that perhaps that choice might be made on the ability to communicate well.

>>DAVID ARCHBOLD: Actually, I did. I think in -- I said, you know, there wasn't -- one solution doesn't fit all and it depends upon culture, language, et cetera, et cetera, so I did include that.

>>RON SHERWOOD: And you cover that by choice, self-choice. Thank you.

>>CHRIS DISSPAIN: Possibly, yes. There's a, can -- okay. You go -- you don't mind if Hilda goes first? Hilda.

>>HILDE THUNEM: Hilde Thunem from Norwegian registry. As a comment to the bottom-up process, I would just like to point out that the regional organizations, like APTLD, LACTLD, et cetera, doesn't have to care about the ICANN regions. And I see no reason why we should tie our membership to the ICANN regions. I mean, I know that CENTR for a fact doesn't. Anyone can join if they feel that they can benefit from that. And so while I definitely think that we should discussing the ICANN regions in relation to what they do to the ICANN organization's life, the ccNSO council, for example, or the ALAC or other things, let's not tie that to the regional organizations where you may participate or not, depending on what you want, I think, and not depending on which region ICANN put you in.

>>CHRIS DISSPAIN: Okay. Hilde, thank you. There's a couple of things, if I can just respond to -- now Patricio. Can you hold on for a second? Sorry.

Just a couple of things, Hilde.

You're right. I mean, APTLD and I think LACTLD choose to -- to map the ICANN region for membership. Is that -- is that right?

[Speaker is off microphone]

>>CHRIS DISSPAIN: But the other thing is -- the other thing is that whilst what you say is correct, CENTR can have members from wherever. Technically so can APTLD. The current rules only allow a regional -- a liaison region -- to liaise with us -- with us, so CENTR is the European liaison with us and that's only with respect to the ICANN defined European region, so there are clashes, if you like, but I acknowledge completely what you're saying. The gentleman behind Patricio and then Patricio.

>>STEPHANE BORTZMEYER:

Stephane Bortzmeyer from the French registry. You mentioned the possibility for a ccTLD to choose its region, but what about the opinion of the ccTLD while already in the region on who may disagree with the new arrival? I mean, do you think it would be a good idea to give some sort of veto right for the people who are already in the region, because North America, for instance, could change from three or four ccTLDs to a dozen or two dozens.

>>CHRIS DISSPAIN: It could. I don't actually think that's very likely but it's possible. I -- I'm not sure that we would, as -- that as an organization, the ccNSO would be keen on getting into giving countries the ability to say to another country, "We don't want you in our region." I think we're quite happy for people to leave a region, but I don't think we would want to say, "No, I'm terribly sorry, you're not coming into our region," I don't think. But it's -- I mean, it's a valid point. Could you pass the microphone to Patricio?

>>PATRICIO POBLETE: In the LAT TLD meeting we just had, we realized language can be a very important issue. All business is conducted in the meeting and on the mainland is conducted in Spanish or Portuguese or a mixture of both. An even though non-Spanish or Portuguese-speaking countries are welcome, they somehow feel their participation becomes a lot harder under those conditions. So I would feel they might reasonably be -- feel that they should be entitled to choose. And, perhaps, we should be speaking about defining regions that are overlapping. Like, for instance, there is LAC, Latin-American-Caribbean. There could also be NAC, North American-Caribbean. Those countries that happen to be to be in both in intersection, the can choose which region they are more comfortable to be in here.

>>CHRIS DISSPAIN: Absolutely. Excuse me. Here, thank you.

>>PAULOS NYIRENDA: Thanks, Chris. I just want to follow up on the opinion of the other members of the region. I think it may be important to take this into consideration. For example -- maybe pick Africa, for example. It may be worthwhile to consider whether Africa want to be repartitioned into Arab-Africa and the rest of Africa. It may be a significant point.

>>CHRIS DISSPAIN: I understand the point you are making, and it is especially relevant to Africa because it is the same land mass. But, surely, if -- I am not saying this is the case. But if there are countries in Africa -- in the African continent that would prefer to be in -- say, in an Arab Nation region, that's not actually partitioning Africa. That's just giving them a choice to have -- to be in a different region for the purposes of whatever -- for the ccNSO or ICANN or whatever.

And I don't think you can fairly say that -- because the majority of countries -- the African region exists because the majority of the countries in the region say that it should remain as it currently is, then it should remain as it currently is. That's actually almost colonialism in the sense that what you are doing -- you are saying unless all of us agree, you can't go. And that doesn't make sense in the context of what we are talking about, I don't think.

But I think you have got an absolutely valid point about talking amongst yourselves as a region about what should happen. Hilde?

>>HILDE THUNEM: I will play devil's advocate on that point. That is, when we are talking about moving from one region to another, we are talking about, in ICANN sense at least, a shift of power because how many members are in the region does effect how large a chance of success for being chosen to the ccNSO council.

>>CHRIS DISSPAIN: Absolutely.

>>HILDE THUNEM: In Europe, you would have to run against 72 other ccTLDs. In North America, you would have to run against seven or eight others, I think. We are talking about something that will affect power.

And when you are then talking about splitting up into new regions, that does raise some problems and should they then have as a region new seats on the ccNSO council because then we might want a Scandinavian region, for example. We are a little part and somebody might be able to join us in the Scandinavian region.

>>CHRIS DISSPAIN: Okay. [laughter]

Anyone can have a new region except for Scandinavia, that's the rule, okay?

[Laughter]

>>HILDE THUNEM: Just to raise the point if we're starting to -- I can see your concern in splitting up from Africa, not just -- not to keep them in sort of a colonial part. But when you are talking about making new regions, you have to be very careful. Why should you make and what should be there to have a new region.

>>CHRIS DISSPAIN: I agree. Dotty, while you are getting the microphone. Hilde, you are absolutely right, but two things. One, in reality, for all practical purposes, when we talk about changing the numbers of regions or increasing the number of regions, we all know there is really only one region that would be a stand-alone region and that's the Arab Nations. And there is a push from them to have a region. And in respect to the Caribbean, there are issues that need to be solved. It doesn't necessarily mean they need a new region. Patricio has a suggestion about having crossover with North America is actually a very good suggestion. Of course, are we opening the flood gates to a Scandinavian region? Is the Netherlands suddenly going to expand upon our wildest dreams? Dotty.

>>DOTTY SPARKS DE BLANC: This is just an observation. It would take two countries out of North America. It would take out America Samoa and Guam.

>>CHRIS DISSPAIN: Isn't that what the U.S. wants? It wants to be on its own in its own region. Right? That's the whole point, surely. Exactly.

Speaking on behalf of Australia, I don't think -- there is not a push on from Australia or from New Zealand, I don't think, for Oceania to be carved out as a region. I think we are quite comfortable at least for the moment being in the Asia-Pacific region. But I think as part of the Asia-Pacific region, we recognize that it is a major challenge for the Arab Nations.

It also makes it a major challenge for the Asia-Pacific region because it is so huge. If we have an apTLD meeting -- we choose the apTLD to follow the ICANN regions. We have an apTLD meeting, we have it on the Arab side ,nobody from the Pacific side can come. It is too expensive and too far. It just makes it impossible. So if there were.

But what we need to do right now is just to agree, I think, so the council can take a resolution forward. Can we agree on the fact that we should at least attempt to prepare a submission to the ICANN regional discussion? And if we can get a consensus paper from the ccNSO that that would be a good thing. Can we also agree that where -- you can look at this on a couple of levels.

You can look at this as a regional thing and say this is what we think ICANN should do in respect to regions across ICANN and/or you can say if that's too hard, then that's not a problem, we just want to do this for the ccNSO.

No one says that the ccNSO structure regions has to be the same as the ALAC or as the ICANN regions. And, in fact, the RIRs up until very recently had a very different regional structure because they had four regions and now they have five. Sorry?

Dotty first and then Roland.

>>DOTTY SPARKS DE BLANC: Can the Arab representatives identify themselves here and speak to the question.

>>CHRIS DISSPAIN: I am not sure -- thank you, Olivier. Dave and I have spent some time on e-mail with Charles Shaban who is not with us, and also with Mohammed Al Shabir who is not with us. Do we have anybody that would consider themselves to be an Arab Nation?

I don't think we do in the room, Dotty. I can tell you -- we have a joint -- the ccNSO-GAC liaison working group had a meeting yesterday afternoon where we talked about the sorts of issues that might be coming up where there is input from both of us.

One of the GAC representatives is from the government of Egypt and it was pretty clear that they think that that actually might be quite a nice idea, to have an Arabic region.

>>DOTTY SPARKS DE BLANC: I just think it is kind of strange for this body to propose there will be an Arab region when there is nobody --

>>CHRIS DISSPAIN: We are not proposing that.

>>DOTTY SPARKS DE BLANC: We're not? That's what it sounded like.

>>CHRIS DISSPAIN: No. I am proposing we agree -- I am proposing we agree we should prepare a consensus paper. In order to do that we need to form a small working group which I am going to suggest Dave leads which will draft some documentation to go to the members for discussion on our e-mail list, et cetera, and see if we can reach consensus. We may not be able to reach consensus. If we can, then we should try to.

>>BART VASTENBURG: Just for clarification purposes, and your proposal would be to have the focus of this working group would include both levels you just discussed? As well as advising ICANN as well as advising ccNSO on internal matters?

>>CHRIS DISSPAIN: We could just put in a paper that says with respect to the ccNSO, we think there should be crossover as Patricio suggested, for example, crossover regions and so on. We can also put in a paper that actually says we think the structure would work at the ICANN level as well. It is important to remember that the actual ICANN board and the GNSO do not have anything like the same amount of regional restrictions, if you like, that we do. The board does not have to have two board members from one reason and two board members from another.

The way their regional thing works you must not have more than five from one region and they must strive for geographical diversity. They don't have the same structures we have. So you are coming from a different base with respect to that. Is everyone happy -- did you want to say something, Ron?

>>ROELOF MEIJER: So, I take it you want to stop the discussion on the content of the document now (row 1 seat 3 right). You don't want to continue the discussion?

>>CHRIS DISSPAIN: I am happy if anybody has anything else to say.

>>ROELOF MEIJER: May I?

>>CHRIS DISSPAIN: Yes, of course.

>>ROELOF MEIJER: I got the impression that part of the confusion that David showed in his presentation -- the beginning of his presentation is caused by the fact that different organizations or different bodies don't use the same standard.

>>CHRIS DISSPAIN: That's right.

>> ROELOF MEIJER: So I would be very careful with forwarding any recommendation other than follow an internationally recognized standard. Although I sympathize with David's situation, I think it would be very unwise to say ICANN has its own system and we as ccNSO come up with another one. It will only add to the confusion.

>>CHRIS DISSPAIN: Sure. I accept that. However, it wouldn't surprise me to discover that if we look hard enough, we will be able to find an international standard of that of some sort.

>> ROELOF MEIJER: You won't find one that solves all problems.

>>CHRIS DISSPAIN: No, of course not. Of course not. Does anyone else have anything to add at the moment? Okay.

So what I'm going to ask then is that -- the way we normally do this is that we will send a note out to the members' list and the wwTLD discuss list to ask for volunteers to sit on a working group to come up with a paper on the regions.

And those of you who are interested, those of you who are concerned about it, can volunteer. That would be great. Donna, we don't currently have a time constraint but there will presumably be a time constraint at some point?

>> OLIVIER GUILLARD: (inaudible).

>>CHRIS DISSPAIN: Let's wait and see who volunteers, first, shall we, Olivier? You never know. Scandinavia is definitely going to volunteer because they want their own region now. We have started something.

So, Donna, is it likely to be a closed date for comment before Lisbon, at Lisbon? Before Lisbon? Okay.

>>DONNA AUSTIN: (inaudible).

>>CHRIS DISSPAIN: Given the Christmas holiday break, et cetera, sometime the end of February type of thing or beginning of March maybe.

>> DONNA AUSTIN: I would suspect earlier.

>>CHRIS DISSPAIN: Okay, whatever. If we send out a note to the lists today or tomorrow, it would be good to have maybe five or six people on this working group. That usually is the best number that seems to be able to get the most efficient amount of work done in the time required and the goal is to -- the goal is not necessarily to come up with a series of suggestions as to how the regions should be structured or how we should deal with dependent territories.

The goal could be to simply push ICANN to form a formal review, like a task force, to formally review the regions rather than just putting out a paper that says "what do you think."

My sense of this is that it is so complicated and so politically difficult that it may actually be simply better for us to say we think it needs to be looked at properly, we think it needs to be looked at across ICANN and we think it needs to be looked at with everyone involved, so please set up a task force, et cetera, et cetera.

But that's the working group will work on that. Okay, David, thank you very, very much. We are moving on to the next session now.

I can see various ICANN board members making their way slowly to the front. Good morning, Dr. Cerf. How are you? Are you feeling any better?

>>VINT CERF: No.

>>CHRIS DISSPAIN: We do have room around the room. I am sorry it is a bit crowded in here. Please feel free.

>>VINT CERF: (inaudible).

>>CHRIS DISSPAIN: Donna, can you see if we can get Michael or someone to maybe get another row in here or something, some more chairs. Yes, please. Donna? It is okay. We are going to get some more chairs, everybody. So if you hang on for just a second, we will get some more chairs in the room. And you can sit at the very front and stare at us.

We will just wait until the chairs come in and people can be comfortable.

>>VINT CERF: I can't help but observe this is an extremely clever way of getting the board to meet the ccNSO members by making them sit in seats that are scattered all around in the room. It is a beautiful, fabulous idea. You should keep doing it.

If you wait long enough, eventually.

>> CHRIS DISSPAIN: Good morning, how are you?

>>PAUL TWOMEY: I'm lost.

>>VINT CERF: There is that problem.

>>CHRIS DISSPAIN: But now you are found.

Ladies and gentlemen, this is the next session which is something that has become a bit of a tradition for us which is to get an update from the ICANN CEO and chair. So, welcome, Vint and Paul and also to the other ICANN board members liberally spread around the room, welcome. There are some more chairs coming. But I am just going to pass over to you now and you can do your thing.

>>VINT CERF: (Making arm movements.)

I really don't have much voice left.

>>PAUL TWOMEY: He is doing that whenever he wants to lead off but we will see how long he remains silent for.

(Chuckles).

Thank you very much, Chris. Pleased to be here. I will work a little bit on the assumption that people -- at least some people in this room got to see the opening public forum yesterday because I think part of the idea of reforming the way the week works was to have a situation where people like myself give a presentation once and most people see it as opposed to people like myself giving the same presentation ten times.

So there is probably already three topics that I would like to raise. One is in the presentation, I talked about ICANN's contingency planning process. And I wanted to reiterate -- because I know many of you, at least some of you, potentially have the same issues emerging in your own operations or potentially your interactions with your government, which is this issue of what happens in the contingency of the failure of the particular organization. In our case it is the failure of ICANN. Now, we have thought of this -- the board has thought about this a lot and we have had a lot of work this in 2003/2004. And the key thing that we really thought through was one is the usual stuff, what do you do in case of emergency fires, bombs; if you are based in Los Angeles, earthquakes. And that's sort of standard stuff.

But the second stuff is what do you do if you look like you have got business failure coming up.

I suppose probably the key thing in our analysis was to put an extra layer of corporate governance thinking inside ICANN, particularly upon the chairman's responsibilities and also, for that matter, on staff supporting the chairman of early warning of the risk and then a process for the community to be reconvened to look after -- A, to ensure the functions keep operating and, B, potentially a new entity is created to look after the functions if the existing entity looks like it is going to go into business failure. In other words, the way to try to save the core functions and have them reorganized and how they are represented, rethought through. In some respects, for those people who were involved in the discussions in '96, '97, '98 on the originally formed ICANN, in our perspective we have a committee which is basically representatives of all those communities again brought together to talk about what the -- what should we do in terms of a new entity.

A couple of points I would like to make about that because it is worth making. You will see in all the contingency planning which the United States government requested under the Memorandum of Understanding No. 6 in which they accepted and said fine, you will notice the United States government does not have a special role. It is the community that is convened.

There is the expectation, I have to say, that there would be an eminent person brought in to chair these things and I would suspect some sort of eminent person is, some sort of eminent person who was a person of authority and recognized authority would probably be useful in that process. But I just wanted to reinforce that for you because part of our thinking at the time was influenced by the KPNQwest bankruptcy, the problem some of you may have known many cc's had secondaries sitting on servers inside KPNQwest and the issue of what to do with the secondaries and can you move them and were they property or not and who owned them and did the administrator have them. I don't know what the Dutch word is, but at least in my jurisdiction we used the word administrator.

What's the Dutch word -- Dutch position of the person that comes in if you are in bankruptcy?

>> (inaudible).

>>PAUL TWOMEY: It was the actual KPNQwest experience that drove us to think about we need to have a step before. So before we are formally in the bankruptcy courts in California, we have actually dealt with this particular issue. We also very much take the view and defend in the courts regularly -- we are actually doing it at the moment -- that the registries, the IANA functions, the allocation of ccTLDs is not property and we spend a lot of time and effort making that position and defending their position that these things are not property.

So I just thought I would give you a little bit more background behind that contingency planning and then make the plea that we are looking for nominees for the key positions so that we have got those names in a drawer. So if on a Thursday afternoon -- I have to ring Vinton on a Thursday morning he says we have to convene, then on Monday we have a list of names and we can work that quickly.

>>CHRIS DISSPAIN: That's representatives from each of the SOs?

>>PAUL TWOMEY: For this particular SOs it is one representative for each region.

>>CHRIS DISSPAIN: We always had a regional discussion and we are up to ten regions now. [laughter]

Scandinavia has its own region, it has decided. So you want one nominee, okay.

>>VINT CERF: I just want to make one tiny observation about this process. It will be really valuable after any party is nominated to such a position to have a fairly regular mechanism to make sure we actually know how to reach that person because if it is anything like every other list I can think of, as time goes on, the information -- the coordinate information gets stale and the one thing you don't want to have happen in a crisis like this is not being able to gain a quorum of people in order to carry out the recovery process.

So whatever mechanism we use probably has to have a background pinging thing that's sending an e-mail out every month to make sure it is still live.

It sounds like a trivial thing; but in a crisis you really, really need to know that you can find those people.

>>CHRIS DISSPAIN: Paul, if you can send -- we can probably get you names from our council meeting tomorrow, if you can send me a note formally asking me to do it. Then I will see if the council can resolve tomorrow to give you a name from each region.

>>PAUL TWOMEY: We suspect we should formally ask the constituency and the supporting organizations each year on an annual basis. There will be an opportunity for rotation if that's appropriate.

The secondary, I thought, were being raised was -- in that president's report yesterday was on consultation processes for the strategic plan. I just wanted to remind people here that there are consultations taking place in four languages this week and I know you have got your own meetings, but we really do appreciate people participating in the consultation process. And our experience has been -- particularly for people's whose native tongue is not English, these consultation processes have probably been the richest.

Our experience to be truthful, the English language consultation process during the meetings is probably the least valuable in terms of the input we get. It is the input we get in other languages which is richest. We really would exhort people's whose native tongue is being included in a consultation to attend if you can.

The third item was on transparency and accountability which I know is a major topic for many of you. And I would direct you to, again, the set of consultations we are doing on management operating principles.

The board passed a key resolution on September 29 outlining what it thinks some of its key responsibilities, one of which is to ensure the development of these principles. And in those principles, we have a series of consultations underway now. I mentioned there was a special agency we are engaging to help us work through materials, and we will have a greater presentation back in Lisbon.

But any input that you have or thoughts that you have or very importantly undoubtedly you will have the same requirements, the same concerns, the same voice inside your own communities. If there are any lessons you have learned, any tricks you've got, any things you do that you think work really well, we would love to hear about them.

I would just exhort, again, members of this supporting organization to be involved in the process because I know many of you did have concerns. Also, if you have got examples of things you'd do, we would like to hear about them.

>>CHRIS DISSPAIN: We are having a session this afternoon and Paul Levins is -- and Patrick are coming to that to talk to start the ball rolling with us talking about it. I am fairly sure there will be some input.

>>PAUL TWOMEY: Similarly, for input, the President's Strategy Committee posted its draft -- its first draft on the recommendations on the set of questions it considered earlier this year. I went through those again yesterday. I won't go through them again now. I would think many of the topics in that would be directly relevant to this supporting organization and to its members and we are having more consultations including a town hall meeting in February-- and online town hall meeting in February. And, again, I would exhort you to have a look at that report, particularly as it deals with some international aspects of ICANN's identity. You may have thoughts you may want to contribute. You may want to listen to the input.

So, again, I think I am just reinforcing that message. I think there are items in that set of recommendations that I think country codes organization may find of interest.

The final point I will put on my list of sort of reminders, I suppose, is IDNs, Internationalized Domain Names. In our last meetings, particularly in Marrakech, there was quite some discussions amongst constituencies and in the hallways about the idea of the concept of an internationalized country code TLD if we can use that phrase, an iccTLD. In other words, a TLD in the character set of a particular geographic region.

And there's been quite some discussion about, you know, if there's a need for that. And I could tell you, frankly, in what I get told in my travels and discussions, that in certain parts of the world, they're very keen to have such a thing. Particularly eastern Europe, Russia, east Asia, south Asia, and the Arab-speaking world, the Middle East. In those regions, I get very strong feedback on that particular topic.

The -- and there was talk about potentially how do we go forward with that, how would we -- how would we potentially have a parallel table, perhaps, to the ISO 3166 Part 1 table, so I know there's been discussion. There's nothing formal has yet emerged.

I just wanted to share that I think at the moment, the sense of some in the board and in the technical community, both in the IETF and the President's Strategy Committee, particularly in some of the IETF work that's underway at the moment, is that before we progress with that idea, it's probably useful to know what parameters would need to be set for any request.

And there is still quite a lot of work, actually intense work, going on inside the IETF dealing with some very difficult problems, and this is something that Vint can talk in detail and with passion about.

And as a consequence, I think the present judgment is that it might not yet be ripe to come formally out with such a request, until we actually know what parameters or limitations may have to be put upon the request.

>>CHRIS DISSPAIN: Just talking about technical --

>>PAUL TWOMEY: Technical limitations, that's right.

>>CHRIS DISSPAIN: Yes, right.

>>PAUL TWOMEY: I don't know whether you want to talk more to this.

>>VINT CERF: I actually do, but --

>>CHRIS DISSPAIN: I just wanted to say, the idea of an internationalized country code top-level domain has been discussed. You know, in the hallways people have talked about it as potentially a thing that might emerge out of the IDN environment, one. Two, in those discussions -- and I've heard this clearly -- a major role for the cc managers, you know, in any discussion. (c), there's clearly also governments have shown a lot of interest in such a thing, in those parts of the world that I mentioned.

But, four, it's not yet a ripe idea because we don't -- there's still a lot of technical uncertainties that need to be worked through, so I just wanted to give some sort of feedback on that.

>>CHRIS DISSPAIN: Can I just -- before you say anything, can I just respond?

As you know, because you'll have seen the agenda, we're doing a session this morning, after this and after our break, on IDNs at the cc level. Not technical, but the politics and the policy, which you'll be amazed to hear there's a fair bit of. And it's -- I think those of us who have been discussing it, and hopefully by the time we finish this morning everyone else in this room will realize just how incredibly complicated it is, not least of which is that there is currently no definition anywhere of what a ccTLD is. It simply says, both in RFC-1591 and ICP-1, it simply says they're built around those two-letter thingies on the ISO list, but there's nothing else anywhere to describe what they are.

And of course if you say they're built around the two-letter codes on the ISO list, then that's all they are, and therefore there is no way you can have a dot idn ccTLD unless you change the definition or you have a new list.

So we're going to get into that in some depth this morning, acknowledging that there's a whole heap of technical stuff to be done and I would accept that. However, I would say there is also so much of the other stuff to be done that we should probably start doing that as well, on the assumption that the technical stuff will eventually be sorted out.

>>PAUL TWOMEY: Can I just make an observation on your observation? From the little that I have read and talked to people about the origin of it, and the discussions that it originated potentially the introduction of the two-letter codes, it may not be an accident that there is no definition.

>>CHRIS DISSPAIN: Yes. Sure.

>>PAUL TWOMEY: And that potentially, one of the safest ways to progress was simply have no definition and just have the list.

>>CHRIS DISSPAIN: Yes, exactly.

>>CHRIS DISSPAIN: Yes, Steve.

>>STEVE CROCKER: Thank you. Steve Crocker. I like -- to follow up on your comment, if you're going to take this up within this forum, one of the things that I would find particularly interesting is: What questions would you want answered in the -- in creating a definition of a -- what a ccTLD is? So even if you don't have an answer to what it is, what questions are driving that? So if I knew what a ccTLD is, I'd know the answer to the following kinds of questions.

>>CHRIS DISSPAIN: Okay. I'm not actually -- I'm not saying we necessarily do need to know what a ccTLD is. I'm using that as an illustration of the fact that it's fairly complicated. But the sorts of questions are: What -- do you -- are you transliterating two ASCII characters into something in a different script? Are you translating it? Are you simply coming up with a representation of a country name? How many -- how many symbols? Two? Three? Four? Who can choose? Who manages? Is it a CCT -- what happens to the -- at the next level down, what happens to the ccNSO where, for example, there are five dot idn ccTLDs in one country run by possibly five different registries? Does that mean they have five members? For example -- I mean that's -- you know, that's the next level of policy and politics but something that we need to talk about at some point.

What I suppose my answer to your question, Steve, would be that if -- if -- and, again, I agree with Paul, it may not necessarily be a good idea, but if there was a definition, then at least you'd be able to say -- you might be able to say that within the confines of that definition, some of the subsidiary questions have been answered. Because if you say, for example, that a ccTLD is the sponsoring organization -- is the two-letter country code managed by the sponsoring organization listed in the IANA database, then you could -- you could possibly argue that in that case, that is the only organization that can apply for a dot idn ccTLD and manage it, just as an example. But we also -- again, I don't want to get too ahead of the debate because we'll be discussing this later on, but we also have -- there may also be some security and stability questions that need to be answered by the -- by your committee about whether, for example, it does have any security implications to!

have two -- two cc's or the same cc in different scripts run by two different registries.

>>STEVE CROCKER: [Speaker is off microphone]

>>CHRIS DISSPAIN: No, I understand, yeah, yeah.

>>PAUL TWOMEY: Okay. Well, seeing I won't be here for your discussion, can I throw two more things that you may want to consider.

>>CHRIS DISSPAIN: Sure.

>>PAUL TWOMEY: And, again, I'm going to reflect things that get asked of me by particularly governments.

One is, you may want to ask the question, I know some -- it's been raised by me -- raised with me by some European governments that they potentially, under their competition laws, think it would be useful for them to have another national TLD that competes with their ccTLD --

>>CHRIS DISSPAIN: Yeah, sure.

>>PAUL TWOMEY:- And how would that interplay with an IDN thing.

>>CHRIS DISSPAIN: Yeah.

>>PAUL TWOMEY: And in -- certainly in -- in a Cyrillic-based country, it was pointed out to me that they've already decided not only what the string will be, but what glyph it has to appear in. And, you know, this came from on high.

>>CHRIS DISSPAIN: Yeah.

>>PAUL TWOMEY: So a degree. So that's another -- you may want to add to your list has in your community anybody discussed what -- what this should be already?

>>CHRIS DISSPAIN: Yeah.

>>PAUL TWOMEY: I think you'll find we understand in China that conversations are already taking place, too, for instance.

>>CHRIS DISSPAIN: Yeah. Vint?

>>VINT CERF: I don't know if I'm audible or not. Is it working okay?

>>CHRIS DISSPAIN: Yep.

>>VINT CERF: Just a comment about this dilemma about who can apply for one of these internationalized ccTLDs. It occurs to me that we don't necessarily have to adopt the view that every entry in the 3166-1 table should necessarily have an internationalized variant. And so we could choose -- this is a matter of decision and policy. We could choose that there are only certain classes of entities that are permitted to apply for and to produce these things.

I'm not advocating anything here. Only to say that we shouldn't be bound solely by the ccTLD table in 3166-1, although I would suggest to you that it would be probably smart to be no more than a subset of that table, because as soon as you depart from 3166-1, you start getting into some very complex territory about, for example, what's a country, who is the representative of the country.

A comment on IDNs in general. First of all, there are a series of very, very difficult steps to decide which characters of the Unicode tables will be included in the characters that are permitted to be used in IDNs. We've gone away from the original plan, which was to say, let's make a list of excluded characters and say everything else is okay. We discovered everything else wasn't okay. And so the original designs for IDNs are now being adapted by going through the Unicode tables and discarding -- excluding characters -- making a list of only those ones that should be included in IDNs. The job is not done, and there's a very complex process in the IETF.

There are some very useful documents coming out of the IETF -- John Klensin in particular -- and I'm going to suggest that we get those documents available to ICANN participants. And Paul, I'm sure we can arrange that. John Klensin gave a very helpful tutorial to the board earlier this week, which I think should be shared.

So that's just useful input for you.

The second issue with regard to IDNs is that even in the context of the IDN ccTLD, even after you get past the technical decision about which characters are allowed, after anything is selected, there are bound to be potential issues to countries using the same scripts end up for some reason wanting the same sequence, or maybe there is a sequence which could be construed to compete with an existing gTLD, by some peculiar happenstance.

Words in one language mean -- you know, representations of words in one language can be interpreted as something else in a different language.

The third problem, not every country has only one language. India has 22. So when you -- you can't refer to a country as a Cyrillic country, necessarily. You can only refer to a country as a country whose languages are the following, using the following scripts.

So I think that there are a whole bunch of issues whose resolution process we will want to decide ahead of time before we actually start proposing strings to be used, so that if there are issues, we already know how we will address disagreements, disputes, and problems. Whether they range from trademark or -- or competitive issues or other things.

So I would just argue that -- that in the process of trying to introduce these IDNs, we'd better have processes in place to cope with disagreements. So let me give you one last example, coming from our experience with the existing ASCII-based domain names.

You all know that there is this uniform dispute resolution process which is not necessarily used everywhere in the world. It's certainly used with the gTLDs.

One of the problems that IDNs are now going to introduce is that the Punycode representation of an IDN -- that's an ASCII string that starts out with xn-- and then more lowercase ASCII, and numeric characters -- those Punycode strings are not going to be hidden. They're going to wind up being visible.

We've already seen examples of user software, browsers and the like, that expose the Punycode representations of the IDN strings.

The problem with that exposure is that there are valid words in ASCII which will show up as the results of mapping the IDN down into the Punycode, so just to give you a few examples, xn--VeriSign, xn Cerf, xn-- I don't remember. There are a whole bunch of examples of strings that look perfectly normal except that they were derived from a particular IDN that might have started out as a Thai character sequence or a Chinese character sequence. We don't necessarily know right now what to do about unhappiness that those Punycode strings are made visible.

You can imagine some of them could be offensive. Some of them could be even illegal. In some countries, it's improper to make reference to the king, for example, in some inappropriate way.

You can imagine people deliberately registering an IDN for the purpose of getting the Punycode string that that person wants, and then having it be visible.

So this is complicated territory, and I would that your particular body that will be most likely affected by this, because you are the group that's most likely going to be using these kinds of IDNs, whether it's at the top level or elsewhere, so I only bring that up just to give you another headache.

>>CHRIS DISSPAIN: Thank you very much. Young Eum, do you have a question?

>>YOUNG EUM LEE: Actually, it's more more a comment rather than a question. I would like to add one more problem to your list of issues related to IDNs in terms of -- not just in terms of technical problems but in terms of who gets to register, which is that IDNs were first brought up by a specific language community, and although --

>>VINT CERF: I'm sorry, I actually can't hear you very well and you're hiding behind the microphone and you're also go hiding behind the person in front of you. So if you don't mind standing up, it would be a huge help.

>>YOUNG EUM LEE: Yes. Let me stand up. My name is Young Eum Lee. I'm from dot kr. I'd also like to point out that IDNs were initially brought up --

>>VINT CERF: Now your microphone is hiding your mouth and for a guy like me, lipreading helps, even at this distance, so I apologize for all the problems.

>>YOUNG EUM LEE: Okay. I would like to emphasize that IDNs were first brought up by a specific language community, and although in the process of technical difficulties, it all came down to script, I would still like to emphasize that there is a specific language script-sharing community that needs to be considered, and that needs to be able to have a major voice in who gets to register the IDNs. I would just like to point that out.

>>VINT CERF: Absolutely agree.

>>CHRIS DISSPAIN: Anyone else got any -- Nigel?

>>NIGEL ROBERTS: Thank you. Nigel Roberts, dot gg. Can you hear me okay? I'm trying to --

>>CHRIS DISSPAIN: Shout. That's it.

>>NIGEL ROBERTS: I think Young Eum makes a good point, and I think everyone who comes from a non-different script environment is making the same mistake whenever they talk about IDNs, and I hear it amongst just about everybody I hear speaking on IDN. IDNs are not about languages. They are not in any way about languages. They are about scripts.

When you start talking about languages, you start talking about national identity and nations. No nation owns a script. Many nations share the script that we all use, and in other countries you can't say that this is the script for this language because in some countries, you have one language, two scripts. In former Yugoslavia, for example, they had one language. It's split into different languages now, but they had one language and two scripts. So please, let's all talk about scripts, and then you defuse a lot of these problems.

>>VINT CERF: So, first of all, I -- I do agree that this is a script issue, but I do want to point out that in the -- just as in the existing UDRP mechanism, when someone has an objection about a particular registration, the reasons for that objection could be quite varied. One of those reasons might be that that particular registration or domain name is troublesome for a variety of reasons in country A, B or C because of the term, the interpretation of the term.

So I'm agreeing with you that this is a script issue, but I think it's also fair to say that when there are issues about registrations, they could be about quite a variety of things, including the meaning of that particular registration in this language. Is that -- is that compatible with what you're thinking?

>>NIGEL ROBERTS: I think it is but I wouldn't overemphasize that because I can suggest to you that in a western country, a -- an IDN which happens to look like a particular not-very-nice picture might be a problem.

[Laughter]

>>CHRIS DISSPAIN: Anyone else? Paul, did you have anything else you wanted to cover? Vint? Did you?

>>VINT CERF: No. Unless there are questions or issues.

>>CHRIS DISSPAIN: Okay. So we're going to get into this IDN thing in even more detail in about 20 minutes time, so that's -- thank you very much for loading some more stuff onto the cart for us.

Okay. Anyone else? Does anybody want to ask Paul or Vint anything about anything else?

>>PAUL TWOMEY: Or other members of the board.

>>CHRIS DISSPAIN: Or other members of the board. I'm sorry. Yes. Of course. Why should they get off?

>>VINT CERF: I'm sorry, I made a bad mistake and didn't introduce one of the newest members of the board, Goldstein. Steve, will you just stand up for a second?

Steve is joining the board officially at the end of the meeting this week. Some of you, I hope, know of his history. Steve was very, very involved at the U.S. National Science Foundation in running the international connections program, and for many years, the reasons that a large portion of the international academic community was part of the Internet was thanks to Steve's work, making those connections happen, funding them in particular. So I want to welcome him specifically to the board.

I don't know -- our other member, Ramaraj, is not here. He had to go off to his son's wedding. And the third member of the board is -- has been with us for a while but is joining now as a voting member, and that's Roberto Gaetano, who is standing over here. Roberto is a really interesting character in our board because he's been the liaison for the ALAC for as long as I can remember, and now becomes a formal voting director. We are going to be very benefitted by his joining the board in that forum, so the rest of the board members are as they have been, and I welcome your opportunities to ask them questions or the rest of us here.

>>CHRIS DISSPAIN: Thank you, Vint. Can I just -- it occurs to me that I should perhaps take this opportunity to give you a heads-up, if you like. As I said earlier on, we spent some bit of time this morning talking about regions, and you have a regional discussion document, whatever, out for comment.

>>VINT CERF: Yeah.

>>CHRIS DISSPAIN: I don't want to preempt anything that we decide, but I suspect that at the very least, we will be coming back to you and saying, "This is far too complicated an issue to deal with in this way," and we would like a -- some sort of formal task force across ICANN to actually deal with this -- this regional issue, which matters to us perhaps a lot more than some others, but we've -- what we've established this morning without too much doubt is it's actually pretty -- pretty complicated.

>>PAUL TWOMEY: Talking personally, I have scars on my psyche and body, probably, about this discussion since 1997. I just wanted to point out something.

We have a newsletter and news alert function now for the ICANN Web sites, which are -- which are also themselves going to undergo a lot of extensive change in the next six months, but I would recommend that you also register for getting those news alerts so that you can -- and electronic newsletters, so that you can, you know, see what we're doing or respond quickly or send an e-mail and say, "You jerks, what are you doing!"

The -- one particular newsletter which -- for those of you who have been registered for the newsletter, there was a newsletter which went out with a summation of some stuff on country -- on regions just recently. You will notice that the newsletter that went out, and what is now posted -- I don't know if they're the same thing -- the newsletter showed an updating of the 2003 agreed set of tables. What is now posted leaves it much more open for feedback which could include feedback on regions as a whole, not just on particular -- particular assignments. So there was some quick -- the -- we will continue to do this. We will continue to err on the side of speed of communications. Occasionally that will mean we'll have to do some corrections but I just wanted to point that out.

>>CHRIS DISSPAIN: Yes. Well, I was delighted to read it because it, in fact, indicated that there would be a sixth region, albeit Antarctica, but nonetheless, it's... Alex? Do we have the microphone, please?

>>ALEJANDRO PISANTY: I have a microphone.

>>CHRIS DISSPAIN: You have a microphone.

>>ALEJANDRO PISANTY: Thank you. Thanks, Chris, for arranging for us to not only be welcome in this room but even have enough seats. Your careful preparation to make it look improvised was really a masterly act.

[Laughter]

>>ALEJANDRO PISANTY: I hate one aspect of these meetings. I'm really -- I have heard the words "sick and fed up" used for some things and I am sick and fed up of one aspect of our meetings, particularly like the one we're having right now, which is that even the physical framing makes it confrontational, makes it only concentrate in requests going either way, complaints going either way, and very little reporting of common success, so I would like to build on the outreach theme for something that I think has been successful, has been a merry and happy occasion, at least in our region, in Latin America, and we think that can be built upon in many other ones.

I think that there is, indeed, a situation in which ICANN staff and ICANN board are separate and in many ways opposite to ccTLD managers, to gTLD constituencies, to the ASO, and so forth.

But there's a huge environment out there in which we have a common cause, which you may or may not want to call "ICANN" as a common cause, but certainly it's the promotion and sometimes the defense of the Internet environment as a creative, flat communications environment that helps people actually grow.

We have had a very successful meeting in Latin America a couple of months ago which was held by-- in our case, it's facilitated by a couple of factors. It was held by interactive videoconference between 11 cities at the same time, plus Webcasts and IM participation and so forth, which was a common effort of ICANN board, ICANN staff, ccTLD managers, GAC representatives, a couple of people of the gTLD community, and the addressing community, to mention the main actors only.

And we would like to encourage this kind of activity to be better known, to build upon models that have also been successful in other regions. We're very aware, for example, that in Australia and England and a few other places, there have been successful ccTLD plus government presentations, and that we can further share and build upon this. The factor that has helped the Latin American region in particular is the commonality of languages between the continent -- at least among the continent and a few of the island countries in the Caribbean, and the narrowness of the time zones, so that we can really put in people from all countries speaking together at the same time for a full day.

Maybe this is not equally applicable in the Asia-Pacific region, stretching from -- as Paul reminds us from Cyprus to close to Hawaii, and some other models have to be applied, but I think that looking at more cooperative efforts of this kind, starting with the outreach, but they go deep into the deep thinking and the day-to-day operations would be very useful and we -- I'd like to concentrate for once on positive news instead of just, you know, firing at each other.

>>CHRIS DISSPAIN: Thanks, Alex.

I thought we'd actually been very positive all the way through.

[Laughter]

>>PAUL TWOMEY: I didn't come loaded for bear but, you know...

>>CHRIS DISSPAIN: Okay. Anyone else? Anything -- anyone have anything they need to say before we wrap this up? Steve?

>>STEVE GOLDSTEIN: Thanks. I would just like to point out that in homage to our Brazilian hosts, the first attempt that I know of to get the Latin American countries to cooperate with each other in Internet was held in 1991 in Rio. And at that point, Brazil was connected to the rest of the Internet by two lines of 9.6 kilobits --

>>VINT CERF: Unbelievable.

>>STEVE GOLDSTEIN: And the meeting that we held was at the institute for pure and applied mathematics, INPA, in the hills of Rio and INPA was connected to the -- wherever the Internet node was by 1200 baud.

>>VINT CERF: Oh.

>>STEVE GOLDSTEIN: So that was 1991, Latin America got together first in Rio.

>>VINT CERF: That's incredible.

>>CHRIS DISSPAIN: Thank you. And we've come a long way since then, it would seem.

Okay. We're going to wrap it up. Thanks very much, indeed. We have a break now and we reconvene at 11:00 sharp for bucketloads of IDN.

[Break]

>>CHRIS DISSPAIN: Ladies and gentlemen, if you could take your seats please, we will be starting very soon.

Okay. Welcome back, everybody, we will get started. This session is all about dot IDN which is IDN ccTLDs and we had already an interesting discussion about that with Vint and Paul.

I have asked Tina Dam to start by giving us a very brief presentation on where ICANN is up to with IDN. Demi is going to talk briefly, from the board's side of things as one of our representatives on the board. Kim is really here just to provide technical overview so when somebody suggests something that simply won't work, he will tell us simply it won't work. And I am here to provide a completely naive view of everything because I doubt Australia would be interested in having a dot IDN in any other character set than ASCII. So I figure if I can understand the complex issues involved, then anyone can understand the complex issues involved.

This session is -- once we have gone through the presentation -- Also, Young Eum Lee will also give us a very brief presentation from the dot kr view of things.

Once we have done that, then I want to have a debate about what the issues are and how complicated and complex it all is and what sort of possible ways we can deal with it to move forward.

So can we start with you, Tina, if that's okay?

>>TINA DAM: Sure, great. So is this -- Can you actually hear me?

>>CHRIS DISSPAIN: I think so.

>>TINA DAM: I thought I would just give you a quick briefing on a couple of things that are going on related to IDNs that I think are important for you to keep in mind as you move forward into policy discussions.

One is a project with ICANN and technical test. The other one is the protocol revision that lies within the IETF. And then I have a slide with a couple of examples with some policy-related things to try to move things in that direction for the ccNSO.

From the technical test overview, we have the testing plans divided into two phases. One is a laboratory setting where we are testing root server software and the resolver and testing out stability in that when you insert Punycode strings.

The second half is -- the second phase is predeployment testing for -- that expands out to application and user interface testing. It is really split up that way purposely so that we can see how the DNS core functionality is working first and if that is a positive result, then move outwards in different layers in the DNS.

I will make these slides available for you. I put some more information in that I really want to spend time in, but the laboratory testing are basically NS records of Punycode strings that are inserted into a closed replication of the way that the root zone is functioning today.

The status quo of it is that the design of how to test is going to proceed -- was developed by Autonomica, a Swedish company we hired to facilitate these testings. It was submitted to the RSSAC for comments. And my slide says to be posted online for comments, and it was actually posted this morning so it is available there and you can go check it out. And there is a common form if you are interested.

Autonomica did a feasibility test and it was successful, so they are just waiting for comments and potentially changes to the design before the test will be finalized. There was one instance of testing this all the way out to the end user level just because we kind of couldn't wait, we are pretty excited to see how this was working. We hook the computer up to the set up and tried it out in two different browsers and the result was in museum dot and then a 63 character-long top-level domain string. The result was successful in one browser and not so successful in the other one. We thought it had to do with how the protocol was implemented in the other browser. It turned out that was not the case. It was a bug they already had found and it was being corrected. So there were successful results there.

As I said, as this is being finalized and if it continues proving to be successful as it is finalized and all the different software is tested and we move onwards with the application testing, it is important that the IDN protocol lays at the application level that it also is working for application software.

This doesn't mean that ICANN is going to come and tell all application developers that you have to implement IDNs or the IDN protocol. But at least we can make some test and make some more detailed information available. The plans for that are being discussed right now and it will be published just like the laboratory test design is being published.

Second thing, within the IETF, the protocol is being revised. And the reason why the protocol for IDNs is being revised is that it was built on Unicode 3.2. And we are now up to Unicode 5.0, which holds a lot more characters and all characters that were inserted in Unicode between the version 3.2 and 5.0 are right now not available to be used within Internationalized Domain Names, so that was the first reason for upgrading the protocol.

As that work was being discussed and is currently underway with some different suggestions for how to solve different areas, we also took a look at how the specific functionality has been working and that is based on experience and implementation for both registries and application providers.

The main issues related to IDNs have been discussed in the RFC 4690 and then in addition or in correspondence with that, there has been three Internet drafts published recently that proposes some different suggestion for solutions to some of those issues.

There is going to be a status report on Wednesday, I guess that's tomorrow, at the IDN workshop. John Klensin will give a status report on how this protocol revision is moving forward.

But I think it is really important for ccNSO policy and also GNSO policy, for that matter, standpoint, it has a lot to do with which characters are actually going to be available and in an inclusion-based model. And if the characters that you are using to write down your language is not in there, how do we work towards making sure that they can get inserted in there in a secure manner.

And with that, my last slide is just a couple of things to throw out there on the table hopefully for discussion. Implementation practices, and think about this, as internationalized top level labels and for ccNSO and for ccTLDs. RC standards, guidelines, how do we make shorter things work pretty much the same way to avoid end-user confusion. Should everybody be required to make sure that if you do a to ASCII and then to a Unicode conversion on the original string that what you get back is the original string because the protocol doesn't work that way with everything. I think most IDN TLD registries have that requirement in there and are following it, but how do we make sure that works forward. Dispute resolution policies, issues around language and script confusions, problems around how same script can be used by different languages and how is the confusability around that solved, how same language can be used by multiple scripts, written in multiple scripts and in so!

me cases mixed scripts; visual confusables the Latin A looks a lot like the Cyrillic A; how does that affect top-level decisions. ccTLD, gTLD joint work, what is an internationalized ccTLD? How do we educate the users? For example, Punycode is going to be visible to them. How are we going to make sure that doesn't damage the way that IDNs is working for them. And what do we do to move forward in terms of application implementation practices.

So that's just a bunch of questions.

>>CHRIS DISSPAIN: Thanks, Tina.

>>TINA DAM: In IDS.

>>CHRIS DISSPAIN: Obviously, some of those issues are issues for IDN and some of those issues are issues for dot IDN and some of those issues for idn.idn. The specifics we need to start looking at over the next few months are in respect to the dot IDN, ccIDNs.

Demi, can you do your presentation and then Young Eum, can you come up and do yours when Demi is finished?

Demi is going to present his personal view. We underline this, Demi's personal view of some of the aspects of IDNs, dot IDN for ccTLDs.

>>DEMI GETSCHKO: Okay. My presentation will be from the side of the one that has implemented in some way in the second level here in Brazil, IDNs. And some thoughts about how we can go ahead with this at the root level. As Chris said very clearly, this is my opinions, not the common understanding of these things.

Anyway, just to put some observations from the user implementation point of view, normally you have some confusion about natural language and domain names. You have to be aware all the time that we are not talking about expressing things in matter of language, but we have also to deal with syntactic considerations and other kinds of protocols. You have e-mail, Telnet, FTPR all aware of this.

The goal to have all the URL expressed in a string of natural languages, of course, not a real expectation. It is not feasible because we have dots and we have slashes and we have colons and all the other parts of the composition of URL. And we have parts that are sensitive to the operational system, the file system we are using that is in the right side of the left slash. We are dealing with names inside the file system of the specific computer. And this is another kind of complication.

I understand that the IDN needs -- varies very much from country to country and the expectations are quite different and just to have a reality check, we know the Internet is growing at a very fast rate. Even we don't have dot IDN in non-Occidental countries. We have to weigh this against the problems we introduce into the system.

Today mainly implementations are at second level. For example, in Brazil, we have a note when you try to raise a dot IDN (inaudible) it will not be working in any browser, will not be working in any e-mail. It will not work if you don't have the keyboard mapping all right. Then we were in some way advising the user to be very careful in the expectations they have when they are trying to register an IDN. This is part of the known big success of IDN. In Brazil, all the time telling the customers to be cautious about.

We choose a very strict script, the accents -- the vowels with accents in Brazil. We also do another kind of restriction that we map all the strings to the ASCII -- the pure ASCII string. And then if you have name without the accent, it can be the only same name with accent. We cannot allow another user to get the same name with accent if there is already a name without accent. This is a way to prevent dispute considerations and also maybe kind of fraud or something like this.

But this works for Brazil but maybe not work for other scripts or other countries.

In our experience, we saw the implementation is quite less problem than the original expectation. I am not sure if this common rule, but in Brazil it is quite true.

Talking a little bit about at the root level. Implementation, of course, depends on extensive technical testing. Tina told us about this. You can check with them.

I understand, I suppose IDN is related to cultural and language and because of that is related to countries. The next lines I use countries between codes because it is a kind of country in the ISO 1633 understanding, not the ISO -- not another country at large.

I suppose we -- ICANN cannot decide what is the appropriate character set for each country. We cannot decide what is the correct way to express the name of that country, only choose character set. We are not in this business. And we cannot also decide if there is or is not a consensus on the name chosen by a given country. There will be some problems in this area, and I expect we are not inside this kind of debate.

And I think also there must be a fair and uniform rule for all countries to define the way for introducing new IDNs, things at the root.

Finally, as a simple proposal to be discussed to see if there is flaws or not, I think -- ICANN has an advisory committee, the GAC, that seems to be adequate forum for this kind of discussions. I cannot state the technical rules that are to be strictly observed the string formations for IDN. And then GAC could discuss this and come -- with a tentative table, say one string per country to be fair and to be neutral. And this table has to be consensed beforehand to avoid any political incorrectness.

In my point of view, there is a community, ccTLDs natural candidate to operate this new TLD coordination with the local government and the understanding of the way it was chosen. As I said, it is to throw on the table for discussion. It is not really discussed inside of the board. It is just my opinion.

But I see two or three good points on this. First of all, is that if you look at the WSIS/WGIG ending that phrase of an enhanced cooporation. What is an enhanced coorporation? It is to give the governance more a piece of saying in this process. I suppose for us the best is to have the true GAC existing forum inside ICANN structure and since the beginning we have some fighting with GAC, in the cc community inside of GAC. But I suppose the things are much better. We have to pursue a best understanding between the GAC and the cc community and maybe there will be a wise way to go forward to try to put this enhanced coorporation inside the ICANN structure, in the GAC forum, and put this in the GAC hands. They will have things to do, things to discuss. This is exactly what kind of thing I think they have to discuss and this can lead to a better corporation between cc's and their government and I suppose it gives other cc's as natural candidate as operator in the country n!

ew leverage. Thank you.

>>CHRIS DISSPAIN: Thanks, Demi. Okay. So Young Eum is going to do a brief presentation on the Korean dot kr views and then we will get into some discussion about the issues there are to be dealt with.

>>YOUNG EUM LEE: While this is setting up -- turning on, let me just tell you where I am coming from. Dot kr is now currently -- basically run by the government. And the Korean language itself which has been mentioned a couple of times is a language that has a couple -- has one or -- actually three scripts that are currently being used so it is a multiple script language.

But most of the scripts -- I mean, the language is being used currently by the Korean-speaking community which is about 80 million currently. About 50 million of which is -- which currently has the South Korean nationality, but 25 million has North Korean nationality and the rest of the people are Koreans living overseas. So dot kr is faced with a very unique situation in IDNs, you can say.

That's where this position is coming from. And I don't want to say that this is a position that we expect all the cc's to share. I don't expect to have the agreement of all the cc's, but I would like to point out that when it comes to IDNs that dot kr has specific issues and I would like to present those issues to you.

Well, the importance -- the first couple of statements are very matter of fact. It is very commonsensical. The importance and need for introduction of fully localized domain names has been consistently brought up and there have been ongoing discussions on IDNs that -- IDN TLDs within the GNSO, ccNSO and the GAC. And taking into account the distinct characteristics of IDN TLD issues, there are several issues that need to be considered.

First of all, IDN TLDs should be created and regarded as a separate name space from the existing gTLD space or ccTLD space. This does not mean that we do not agree that the existing ccTLDs should be considered primarily for -- as the entity to be responsible for running the new IDN TLD or IDN ccTLD.

This just refers to the generic IDN TLDs that may result from the current discussions. So in any occasion, IDN TLDs should not be understood to replace the existing TLDs in a different character set or to extend the present TLDs' scope into different language scripts. And that IDN TLDs does have its own community of interest. And this is what we would, again, like to emphasize and this is what I try to emphasize before in our discussions with Paul Twomey and Vint Cerf which is that that language or more precisely a language script sharing community exists and that this property is quite different from cc's and that this community of interest should be considered. Second, IDN registry is to be designated by language script sharing community and has a duty to serve that community.

So what label string of IDN TLD should be selected and which -- or who would operate the registry should be supported by the community, and this is what we would like to mostly emphasize. IDN TLD governance should be open to all the legitimate language script-sharing parties, and this is another thing that I think has to do with a specific language script-sharing community.

Third, governments could also play a catalyst role in introducing IDN TLDs, especially in cases like Korea where the government is responsible for most of the matters dealing with the Internet, and so the introduction of IDN TLDs should be -- should consider their sociocultural and linguistic context.

But in any occasion, any other stakeholders' participation should not be excluded and rather, be encouraged from the language script-sharing community, as long as they belong to it.

Those principles of multistakeholder participation, bottom-up consensus, openness and transparency should be coherently taken in creating IDN TLDs.

In principle, to avoid confusing similarity -- this, again, addresses some of the technical difficulties -- it would rather be better that IDN TLD label strings is to be decoupled with the existing TLDs in terms of graphics, semantics and sound. Particularly when at least two criteria are applied to the proposed IDN TLD label stream.

For the security and stability of the Internet, the possible homographic danger particularly in TLD strings should be cautiously avoided in introducing IDN TLD strings. And this is another technical issue that has been addressed.

At the moment, guidelines for the implementation of Internationalized Domain Names Version 2.0, which was endorsed by the ICANN board on November 8th, 2005, could be primarily taken into account and observed by the IDN TLD registry. But then as technology evolves, more optimal solutions could and should be explored.

IDN TLDs could be steadily introduced whenever the demand of the language script-sharing community and its readiness which is to be confirmed on the IDN language table list registered in IANA are to be identified. At the first round of IDN TLD -- so this encourages not a fast but a slow and steady introduction of IDN TLDs. So at the first round of IDN TLD, only one TLD per registered language script could be allocated.

And the last one has to do with DRP, which says that it also should be developed primarily by each language script-sharing community. Thank you.

>>CHRIS DISSPAIN: Young Eum, is it fair to say that the majority of those comments were at least originally intended to deal with IDNs in the gTLD space?

>>YOUNG EUM LEE: Basically -- well, IDNs in the gTLD space. I don't know if you want to even discuss IDNs in the gTLD space. IDNs are separate. I don't I think that we would like to consider IDNs in the gTLD space.

>>CHRIS DISSPAIN: So your -- so the -- so the Korean -- Korean position would be that it should not be --

>>YOUNG EUM LEE: Your microphone is not working.

>>CHRIS DISSPAIN: No, it's not going to work, is it.

>>YOUNG EUM LEE: It's not going to work.

>>CHRIS DISSPAIN: Well, it's sort of a waste of time having it, really. So the Korean position would be that --

>>SABINE DOLDERER: Chris, just one question?

>>CHRIS DISSPAIN: Yeah. One sec.

The Korean position would be that you wouldn't want, for example, an existing registry to have a Korean language -- Korean script-based version of their gTLD.

>>YOUNG EUM LEE: Well, as long as that existing registry is a part of the language script-sharing community, that's --

>>CHRIS DISSPAIN: Right. So -- I mean, okay. So VeriSign, which I'm assuming isn't a part of the language script-sharing community, therefore, the Korean position would be that VeriSign should not be allowed to register dot-com in a Korean script.

>>TINA DAM:.

>>YOUNG EUM LEE: Unless they have the support of the language script-sharing community.

>>CHRIS DISSPAIN: All right. I just wanted to be clear on that.

Sabine, did you have a question?

>>SABINE DOLDERER: Yes, just a question of clarification. Did I get it right to say that at the first round of IDN TLD, only one TLD per registered language script should be allocated? Does it mean registered language script in that country or does it mean registered language script as a whole?

Just as an example, you have, let's say, the Korean language script shared by two countries, as I see it at the moment. Do you think that means one language -- one IDN TLD per country and registered language script, or language script as a whole as shared by South Korea and North Korea, just to take the example? Because I don't get the argument quite right.

>>CHRIS DISSPAIN: Yeah.

>>YOUNG EUM LEE: Right. I -- I completely understand where you're coming from. And I guess this basically has to do with the Korean language. I don't intend to --

>>CHRIS DISSPAIN: Draw a distinction between the North Korean and the south Korean -- right.

>>YOUNG EUM LEE: Or have this apply -- this principle be applied to the Chinese-speaking community, for example. I don't think that's very fair of us to be the -- addressing that.

>>CHRIS DISSPAIN: Okay. Yeah. Demi first and then Tina.

>>DEMI GETSCHKO: Just a comment on this. I agree totally with the approach about the scripts and the language, but in a practical way, I suppose we have to confine these two countries because otherwise it will be an unsolvable problem. We can find differences in between scripts in countries or maybe political differences that can prevent us to have some kind of practical implementation. And I totally agree with the approach, but I will try to -- to map this in existing countries to have a way to go forward.

>>CHRIS DISSPAIN: Okay.

>>DEMI GETSCHKO: This is my opinion.

>>CHRIS DISSPAIN: Tina?

>>TINA DAM: So just sort of like a follow-up I think on what Sabine was heading at, I don't think -- I don't think it's a good idea to limit things within one country because languages are spoken across the world and sometimes one language is spoken in different regions of the world.

And there's also a lot of languages spoken across different countries that use the same script, and you have to keep in mind that computers do not really know what language it is that you have in mind when you type something into it. If you type in a domain name, all that the browser will figure out is what script is this in and what codepoint is associated with it.

>>CHRIS DISSPAIN: Yeah.

>>TINA DAM: So the question is, you know: How -- if we're going towards this language script-based community, how do we define that?

>>CHRIS DISSPAIN: Sure.

>>TINA DAM: How is that defined.

>>CHRIS DISSPAIN: Yeah. And I mean that's a really good question. There's a -- yep. Do you have the mic? Yes.

>>MING-CHEN LIANG: Yeah. This is Ming Chen from TWNIC. I think the IDN itself is a complicated problem because it have localized characteristics, so that the people using the script will tend to think that maybe you should have something related to that. But I would suggest that maybe in this discussion, we should have a separate discussion about the gTLD and the ccTLD because --

>>CHRIS DISSPAIN: Yeah, this is not about gTLD. That's exactly --

>>MING-CHENG LIANG: Yeah. Because I think the presentation by KRNIC will have implication. If it's gTLD, I think that implication will be bigger because then I would think that maybe dot com in Chinese, even in traditional Chinese, or simplified Chinese may be owned by different people, so there may be some business implication on that. But for ccTLD, that might be different and it might be just a script that's shared by a common -- a set of people that maybe commonly use that. And I agree with Tina about it, because in the case that the Internet itself is globalized, but the IDN itself might be localized by a certain type of people. So we need to have a balance between how to make it still be usable by global community --

>>CHRIS DISSPAIN: Yes.

>>MING-CHENG LIANG: -- but still be able to identifiable by localized people. Thank you.

>>CHRIS DISSPAIN: Yes. I agree. I agree, and I think what I was going to say before you asked your question was I think we need to make sure that part of the problem with IDNs is it's so complicated. There are so many different issues that not -- that things tend not to happen because everyone thinks this will be too difficult. So what I'd really like to do is to concentrate on the -- on the ccTLD aspects of.idn specifically, because that is quite clearly that this community needs to get really clear about, and a knowledge that's going to take quite some considerable time. Now, I've got a whole -- I've got a number of questions that I wanted to ask and deal with, but wall of you wanted to say something first. Could we have the microphone down here, please? Hello? Could we have the microphone, please? Thank you.

>>OLOF NORDLING: I still would like to elaborate a little on the necessity for a single TLD for a particular script. What I think would be necessary would be to have one authoritative language script label, and that's --

>>CHRIS DISSPAIN: Sure.

>>OLOF NORDLING: -- a particular problem. But once we have that and everybody agreed to that is the one to be used, what would be the complications with having multiple TLDs in the particular script or --

>>CHRIS DISSPAIN: My understanding is that it's -- and I -- let me into if I've got this right, because if I can understand it, then hopefully everyone can. I think it's to do with a belief that the language is owned, that the script is owned by the community, and that it shouldn't be used by just any -- by just anybody.

Now, I'd actually -- I don't agree with that, but I understand the point. So it's -- it's an ownership thing of the -- of the -- of the script, if you like. And I think that's the reasoning behind the Korean position.

>>YOUNG EUM LEE: Uh-huh.

>>CHRIS DISSPAIN: Okay. Hilde.

>>TINA DAM: Who answers scripts.

>>CHRIS DISSPAIN: Well, yeah, exactly. The language-sharing community owns the script.

>>TINA DAM: There's nobody that owns a language except for the user.

>>CHRIS DISSPAIN: Okay. Please. Okay. But I really -- for right now, this is a sidetrack for us so I'll let it go for one more question or possibly two, because if I do let Eberhard speak, he'll kill me.

>>DR. EBERHARD LISSE: [Speaker is off microphone]

>>CHRIS DISSPAIN: You'll send me a rude e-mail. Yes, exactly. Two questions and then we've got to deal with the cc stuff. Yes, Hilde.

>>HILDE THUNEM: Well, I think I just want to mention on your question list for things to deal with afterwards --

>>CHRIS DISSPAIN: Yeah.

>>HILDE THUNEM: -- the point that Young Eum raises is relevant, and that is what is local in the community of a dot idn because the local community of a ccTLD, we tend to think of it in geographical terms, local Internet community of dot no is Norway. It's a geographic area.

>>CHRIS DISSPAIN: Yes.

>>HILDE THUNEM: Is that the same for a dot idn or is it a language local Internet community like Spanish, which is -- I mean, Norwegian hasn't spread very far so this won't affect us very much anyway, because we've failed in our invasion of Europe.

>>CHRIS DISSPAIN: But you're now trying to do that by getting a region in the ccTLD.

>>HILDE THUNEM: Yes, exactly, that's my secret plan. But what is the local input community? Is it larger? Is it smaller? We do have some people in Norway we're actually supporting -- we have IDNs under dot no and we're supporting five different languages but should we then start thinking that there should be a dot idn TLD that would just embrace a small part of the people living in Norway because they speak one language.

>>CHRIS DISSPAIN: Yeah. And that is one of the questions that we need to consider. Eberhard?

>>DR. EBERHARD LISSE: Eberhard Lisse from dot na. I'm a fervent supporter of RFC-1591, as you know, which says that IANA is not in the business of deciding what a country is.

>>DR. EBERHARD LISSE: I don't think we should start deciding what a language is and what a script is, and whether South Korea may have to decide what Korea can use, in this particular example. We should leave this to people who can take the heat.

>>CHRIS DISSPAIN: I -- absolutely. I agree. The only question is who they might be.

Okay. Can I start then by-- can I -- is this about -- what's this about?

>>JOSHUA LEE: Yeah. Can you allow me to talk about something for one minute, please? This is my first --

>>CHRIS DISSPAIN: Sure. Go ahead. Can you stand up?

>>JOSHUA LEE: Thank you very much. Actually, I agree with -- partially with this gentleman, and Tina, but I want to see this matter in a different view. I mean we're talking about IDN as a TLD, but what I believe is, IDN is somehow responsible for not only TLD but also second-level domain. That's why the language community is important. I mean, the current IDN was introduced by VeriSign in 2001. I still remember that was big tales. I mean not many problem is being created since 2001 because it's not being used. I mean everybody registered on it, but nobody really use it because it's so inconvenient, but still a lot of problem. Let me give -- let me give an example.

Like one Korean guy registered Hitachii.com, which is a well-known electric company of Japan. But it's not phonetically very similar to Hitachi. I can't write down in Hitachi about 10 different forms in Korean. Also, dot-net, I can't write down that Korean script about three or four different types of scripts. That's how -- where IDN should be supported by like common language sharing community.

>>CHRIS DISSPAIN: I understand. But -- I understand completely the point, and it's a relevant discussion overall for IDNs. What we -- but it's not -- it's not specific discussion for this community to have in respect to what is effectively -- what we're talking about is a script IDN for a ccTLD. What happens behind the dot is a matter for -- for the country concerned. The question -- well, perhaps if we start at the very beginning, it might -- we might get -- we might start getting somewhere. The first question, as somebody who has -- comes from a country, speaks a language that doesn't need an IDN, comes from a country of birth and a country that I'm living in that basically wouldn't have any reason for an IDN, I have some questions that I think are relevant to this community, and what I would like to suggest is that if we go through these, if I throw something -- if I say something that's relevant at some -- that people have comments on, and people want to discuss, !

then we -- then we do that, because I think otherwise we're just going to go round and round in circles.

The first question is: Is the principle of an IDN ccTLD, is such a thing -- should they be there?

Now, I think everyone probably accepts the answer to that is yes, on the basis that, you know, no doubt Korea would like a dot something to represent Korea in the Korean script and Japan would like a dot something to represent Japan in the Japanese script and so on.

So if we assume that that's the case, and if we assume that there is a desire for there to be a dot IDN ccTLD, then we have to start working on a whole heap of -- a whole heap of things that arise. And the first one was one I talked about with Vint and Paul, which is: Well, what is a ccTLD?

Now, RFC-1591 and ICP-1 don't define it. They simply make reference to the two-letter country code on the ISO -- on the ISO list, so what they say is that a ccTLD is a TLD that uses the two-letter country code on the ISO list. That's what they say. That doesn't actually define what a ccTLD is. It just says that if you've got -- if you're -- if you're someone who is using -- managing a two-letter code on the Internet, then you are a ccTLD. I don't know that we actually do need to define what a ccTLD is. I don't know. May -- I have some sympathy with Paul's view that probably it's the last thing that we want to be doing, but nonetheless it's a question that we need to think about. Then you got to move down to the next level -- anything like this he will, did you want to say something on that.

>>NIGEL ROBERTS: Yeah. It's very easy. ccTLD --

>>CHRIS DISSPAIN: A ccTLD is something in the Anne database. Observation. So that means that dot com is also a ccTLD then.

>>NIGEL ROBERTS:. [Speaker is off microphone]

>>CHRIS DISSPAIN: Okay. So a ccTLD is a two-letter code in the IANA database, so that means a ccTLD can't be anything other than two letters.

[Speaker is off microphone]

>>CHRIS DISSPAIN: And what about -- yeah. Anyway, look, and I acknowledge there's all sorts of ways you could define it. So if you -- I asked Hiro if he would give me a slide of what the IDN would be for Japan. Now, this is to start looking at some of the issues that arise.

The first point is, it's -- you can't just take dot jp and translate dot jp into the Japanese script because there is no Japanese equivalent of j or p, and it -- because it's a pictographic script, it doesn't work that way.

You could take dot gr -- I think Greece is dot gr. You could take dot gr and transliterate that into dot gr using the Greek alphabet, probably, because there is an equivalent letter g and an equivalent letter r. So the first thing we can see is that not all countries are the same in the way that they can deal with it.

Second thing is, from a Japanese point of view, is that if even if you could translate dot jp into Japanese script, that doesn't mean anything in Japan because the Japanese don't call themselves Japan. We call them Japan, but in Japan it's Nippon. Is that right, Hiro?

>>HIRO HOTTA: Yeah.

>>CHRIS DISSPAIN: Nippon.

So how do you decide what you're going to use for your IDN dot -- your IDN ccTLD is not an easy question to answer because there isn't always an easy solution. Yes, Eberhard.

>>DR. EBERHARD LISSE: I have a question. Do you speak a language that your and anything like this he's speak and what do they call Australia in their language?

>>CHRIS DISSPAIN: There are at least a hundred languages spoken by the different tribes of the aboriginal populations in Australia, and I have absolutely no idea what they call Australia. I can, however, tell you -- I can, however, tell you that the kangaroo is called the kangaroo because when captain cook arrived in botany bay in 18-whenever it was -- he and his crew saw kangaroos bouncing past in the distance, and asked one of the aboriginals what that was, and the and ridgy replied "kangaroo," which means in his tongue, "I have no idea what you're talking about."

[Laughter]

>>CHRIS DISSPAIN: So --

>> [Speaker is off microphone]

>>CHRIS DISSPAIN: Yeah, exactly. Demi, did you want to say something.

>>DEMI GETSCHKO: Just to follow on on what Eberhard says. I suppose this shows clearly that we are in a position to decide anything about the strings that will be chosen by the specific country or culture, and another problematic thing is that if you deal with the Spanish culture, for example, we cannot decide who belongs or not to this kind of culture. Then the best way is to leave these decisions to the countries.

>>CHRIS DISSPAIN: Well, that's fine, and that's certainly one view. But there are other -- there are other topics that need -- I mean there are other things you need to think about before you make a simple -- you know, a simple statement like that. Because there is -- there is a -- there's a duty to the community as a whole. Even if you can't -- even if you do say, "Okay, government of Japan, you decide what the -- what the symbol is going to be for dot jp," well, that's fine, but then what happens if there's a clash with another -- with another symbol in the same script or what happens if you use -- perhaps not quite the same with pictographic languages, but let's say that am I -- is Australia -- does Australia have the right to prevent dot au being registered in any other language script, any other script around -- around the world? Now, I can't imagine anybody would want to, but they might in the gTLD space, for example, want to register. So the example that I -- I!

've used to describe this which probably helps the most is that the largest Greek population outside of Athens lives in Australia. In Melbourne, actually.

If the Greek population of Melbourne got together and put in an application for a gTLD for dot ua in the Greek script, is that -- is that acceptable from the ccTLD point of view? So do we have to now have a series of reserved -- so every country code is reserved. But the problem is, how do you reserve the Japanese pictographic ccTLD IDN in a -- there is no other -- there's no equivalent of it in any other language. So is it -- is it the way it's said? Or is it just jp. It's very hard to work those sorts of things out. Do you want -- oh, you're just nodding, okay. So I mean those -- those questions, at some point, are going to need to be -- are going to need to be answered. I don't know by whom, but...

>>TINA DAM: Can I add on to that.

>>CHRIS DISSPAIN: Yeah. Can Roelof into the microphone please? Yes, Tina.

>>ROELOF MEIJER: Okay. My name is Roelof Meijer from SIDN. I'm afraid about by opposing all those questions, we risk overcomplicating the issue because there will be so many questions to answer that in 10 years, we'll still be trying to answer them.

>>CHRIS DISSPAIN: Sure.

>>ROELOF MEIJER: And -- well, just your example, I don't see any problem with the Chinese international ccTLD extension if you translate it meaning the same as au in our character set. Because there's no Australian company probably that -- in competition with --

>>CHRIS DISSPAIN: Sure.

>>ROELOF MEIJER: -- auDA will register under that extension. So I think we should all try to keep it as simple as possible, and if I -- if I may make a comparison, for instance, with fully numeric domain names, you can also make that into a very complicated issue by asking yourself, should we allow numeric domain names that resemble telephone numbers or Social Security numbers or car license plate numbers or whatever.

>>CHRIS DISSPAIN: Uh-huh.

>>ROELOF MEIJER: And if you go along that line, you'll be -- you will be arriving at 100 questions to answer and you'll be discussing again for 10 years.

>>CHRIS DISSPAIN: Uh-huh.

>>ROELOF MEIJER: And I think you should consider that it might be very answer and it is yes, we will allow it. We see no problem.

>>CHRIS DISSPAIN: Sure.

>>ROELOF MEIJER: I'm not trying to oversimplify the issue.

>>CHRIS DISSPAIN: No, no, I understand.

>>ROELOF MEIJER: But you should not be trying to over-applicant it either.

>>CHRIS DISSPAIN: I accept that. I agree that some of the questions get so deep that it becomes almost impossible to work out what the -- what the solution is, and it may be so unlikely to occur that it simply doesn't -- doesn't matter.

>>ROELOF MEIJER: You might consider, along your position, you might consider asking every country that is interested in an IDN extension --

>>CHRIS DISSPAIN: Yes.

>>ROELOF MEIJER: -- to come up with a proposal and then you check it for technical problems.

>>CHRIS DISSPAIN: Okay.

>>ROELOF MEIJER: And if there are none, then they'll get it.

>>CHRIS DISSPAIN: So can I ask a question -- yes, okay. You could do that but --

>>ROELOF MEIJER: The problem will be: What is a country?

>>CHRIS DISSPAIN: Well, assuming that it is defined as anything that has an existing -- you could define it as something that has an existing CCT -- existing code.

>>RO